What do you guys think of go? Started playing around with it. Neat little language. It's like a modern day C. Doing .NET for so many years the simplicity of it feels great.
Not sure Go is really modern day C, that crown goes to Rust. Go's big offering to the world, and why I think it's important and you should definitely learn it, is relatively simple ways to solve complex concurrency and vertical scaling issues, while keeping the language itself simple and easy to learn.
If they would just fix a couple of the edge case deadlocking issues and maybe bit some ownership/borrowing mechanisms from Rust, just for cross-go-func data, it'd be nearly perfect as a language to write complex concurrent code in.
What do you guys think of go? Started playing around with it. Neat little language. It's like a modern day C. Doing .NET for so many years the simplicity of it feels great.
I'm a huge fanboy of Go. I do all my personal stuff in it. It's the benchmark I compare other languages with. Once you get used to a few syntactic quirks, it is one of the most terse-but-readable languages out there.
No generics / type parameterize is a flaw (though an understandable one given that Go really needs a custom syntax for it to feel idiomatic. Nobody wants to recreate the angle bracket hell you get in Java).
Error handling is a bit obtuse, though far better IMHO than exceptions. Both issues are being actively worked on for Go 2, which is still years away.
No inheritance is kinda weird, but you get used to it, and isn't really needed in the same way generics are.
Maybe you guys can help me with some questions I have. I've been put on a Go project doing automated testing (not my wheelhouse, but it pays) and I'm having some growing pains. All the tests are part of a package we'll call app_tests for the sake of discussion. Having spent more years than I can count working in C# and Java, I'm used to classes and inheritance. What I am struggling with is that every step of the test case (there's one func for each step) are all global to the package. So if I have some variables that I want to use in multiple steps, they get created outside those functions, making them global to the package as well. This just feels wrong to me and makes me think I am missing some huge feature of Go that would make this easier.
I really, really want to like Go, but I can't help but feel I've been sucked into an alternate 1976 where someone added garbage collection to C and made pointers slightly easier.
1 hour time limits are bad, I knew I was fucked when it took me 10 minutes to find+translate the common denominator algorithm from wikipedia to code.
I had that happen once, it was horrible. I majored in Art in college and just happened to learn to write code on the side, so I never took any CS classes where I would have learned to code algorithms and such. Those types of code tests scare the piss out of me. Want me to build an application based on some specs? I'll do that all day and kill it. Want me to write a sort algorithm straight off the top of my head? Uhhhhhh....
Ear3nd1l on
+2
Options
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited April 2019
There really isn't much point in exporting (i.e. capitalizing) anything in a *_test.go file because it won't be available outside a test context anyway.
There really isn't much point in exporting (i.e. capitalizing) anything in a *_test.go file because it won't be available outside a test context anyway.
A bit late, but I'll chime in with that I really like Go. Python is my main language and pays the bills, but my current main side project is Go and I'm on the lookout for a good place to start using it at work. It has a few weird quirks, but overall it's pretty cool. I love the way the interfaces and embedded structs work to solve similar problems to what inheritance does. The biggest things missing for me is named parameters and optional params/default values. I get the reasoning for leaving them out, but I don't have to like it.
i have found a race condition bug in my main application that only occurs if the following two things are true:
1) The app is running against the production server
2) The app is NOT plugged into the debugger
are you ..... are you joking me? What the hell is this? I know roughly what the issue is but debugging this thing has been a total nightmare, as I've had to make a new logging system that can run and save what I need, and then look at it when I replug it back into the tool chain
I'm visiting my dad for a few days, and he's playing a lot with home automation and IoT stuff.
He showed me Node Red, and ten minutes later I made a Telegram chatbot that returns the temperature from his weather station when you send it a message.
In C#, you can access an outer class' private members from the inner class. Is it possible to do the same from subclasses that inherit from the inner class? What if the subclass is defined in a different file from the outer class?
In C#, you can access an outer class' private members from the inner class. Is it possible to do the same from subclasses that inherit from the inner class? What if the subclass is defined in a different file from the outer class?
So the scenario is something like this?
using System;
namespace nesting
{
class Program
{
static void Main(string[] args)
{
var example = new InheritedNestedClass();
}
}
public class BaseClass
{
private static string state = "someState";
public class NestedClass{
public NestedClass(){
Console.WriteLine(state);
}
}
}
public class InheritedNestedClass : BaseClass.NestedClass{
public InheritedNestedClass() : base()
{
}
}
}
Yeah, that works. The location of the base class inheritor doesn't really matter as long as it can access the namespace of the class it's inheriting
That's what I was expecting, but VS is telling me to try again.
namespace MyProject {
public class Outer
{
protected Animator _animator;
public abstract class InnerBase
{
protected Outer _outer;
public InnerBase(Outer outer)
{
_outer = outer;
_outer._animator.Whatever(); // totally fine
}
}
}
public class InnerChild : Outer.InnerBase
{
public InnerChild(Outer outer) : base (outer)
{
_outer._animator.Whatever(); // gives me "Outer._animator is inaccessible due to its protection level."
}
}
}
I wondered if it had to do with compilation units, but I re-tested and it's the same result no matter what file it's in. I can post the whole thing, but I recreated it with just this relevant bit.
Edit: It occurs to me that it might be relevant to mention that I'm targeting .NET Framework 4.7.1.
Edit2: Better example without any Unity bits
namespace NestedTest
{
public class Outer
{
protected int _protectedInt;
protected static int _staticInt;
public class InnerBase
{
public Outer _outer;
public InnerBase(Outer o)
{
_outer = o;
_outer._protectedInt = 42; // fine
Outer._staticInt = 43; // no problem
}
}
}
public class InnerChild : Outer.InnerBase
{
public InnerChild(Outer o) : base(o)
{
_outer._protectedInt = 99; // nope
_outer._staticInt = 100; // also nope
Outer._staticInt = 101; // additionally nope
}
}
}
How so? I think it's pretty analogous to the Java Inner Class idea.
It's a simple state machine, with classes derived from NestedClass acting as the different states. I could put together a more robust solution, but this is my compromise to rewrite as little as possible and move on.
There's definitely an element of that. The code I have now actually works fine.
It's just a big dumb mega class that Unity tends to encourage. I'm dividing up its responsibilities into a basic state machine. The inner class allows me to access the fields exposed in the outer class' inspector in Unity.
It's because your inner child hasn't inherited the outer class, so you can't get its protected members.
I don't java do I'm a little confused by the pattern here. What does the innerbase class bring to the table?
This is in C#, but IIRC it works the same in Java. An inner class can access the private and protected members of the outer class. In cases where you need to divide up responsibilities but still have to bundle them together, this is an easy way to do that without making anything public or passing around all of the outer class' members individually.
It's sort of a niche subset of what friend classes do in C++.
There, now I'm home with my own toys, so here's a Flic + Raspberry version of Mr. Brewbot. Fun in a different way than doing the electronics yourself. (Also not having to make any PCBs.)
....on instagram. Most influential individual person in tech on instagram.
That just Mr. Kruger, nothing to see here!
Can't be. Developers are significantly smarter than the average population and basic psychological biases don't apply to them. I don't think you are reading this right.
Posts
I live here.
Please bring sandwiches and coffee and a go runtime thx.
Maybe you guys can help me with some questions I have. I've been put on a Go project doing automated testing (not my wheelhouse, but it pays) and I'm having some growing pains. All the tests are part of a package we'll call app_tests for the sake of discussion. Having spent more years than I can count working in C# and Java, I'm used to classes and inheritance. What I am struggling with is that every step of the test case (there's one func for each step) are all global to the package. So if I have some variables that I want to use in multiple steps, they get created outside those functions, making them global to the package as well. This just feels wrong to me and makes me think I am missing some huge feature of Go that would make this easier.
I really, really want to like Go, but I can't help but feel I've been sucked into an alternate 1976 where someone added garbage collection to C and made pointers slightly easier.
I had that happen once, it was horrible. I majored in Art in college and just happened to learn to write code on the side, so I never took any CS classes where I would have learned to code algorithms and such. Those types of code tests scare the piss out of me. Want me to build an application based on some specs? I'll do that all day and kill it. Want me to write a sort algorithm straight off the top of my head? Uhhhhhh....
Also globals are in generally not a good sign. Sometimes they are unavoidable but it should be pretty rare. I google searched some ideas on how to avoid them.
Awesome, thank you. I'll check that out tomorrow.
public int[] newThread(int[] thread) { assert thread != null && thread.length > 0; if(thread.length >= 100) { return new int[1]; } }1) The app is running against the production server
2) The app is NOT plugged into the debugger
are you ..... are you joking me? What the hell is this? I know roughly what the issue is but debugging this thing has been a total nightmare, as I've had to make a new logging system that can run and save what I need, and then look at it when I replug it back into the tool chain
He showed me Node Red, and ten minutes later I made a Telegram chatbot that returns the temperature from his weather station when you send it a message.
So the scenario is something like this?
using System; namespace nesting { class Program { static void Main(string[] args) { var example = new InheritedNestedClass(); } } public class BaseClass { private static string state = "someState"; public class NestedClass{ public NestedClass(){ Console.WriteLine(state); } } } public class InheritedNestedClass : BaseClass.NestedClass{ public InheritedNestedClass() : base() { } } }Yeah, that works. The location of the base class inheritor doesn't really matter as long as it can access the namespace of the class it's inheriting
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/protected
namespace MyProject { public class Outer { protected Animator _animator; public abstract class InnerBase { protected Outer _outer; public InnerBase(Outer outer) { _outer = outer; _outer._animator.Whatever(); // totally fine } } } public class InnerChild : Outer.InnerBase { public InnerChild(Outer outer) : base (outer) { _outer._animator.Whatever(); // gives me "Outer._animator is inaccessible due to its protection level." } } }I wondered if it had to do with compilation units, but I re-tested and it's the same result no matter what file it's in. I can post the whole thing, but I recreated it with just this relevant bit.
Edit: It occurs to me that it might be relevant to mention that I'm targeting .NET Framework 4.7.1.
Edit2: Better example without any Unity bits
namespace NestedTest { public class Outer { protected int _protectedInt; protected static int _staticInt; public class InnerBase { public Outer _outer; public InnerBase(Outer o) { _outer = o; _outer._protectedInt = 42; // fine Outer._staticInt = 43; // no problem } } } public class InnerChild : Outer.InnerBase { public InnerChild(Outer o) : base(o) { _outer._protectedInt = 99; // nope _outer._staticInt = 100; // also nope Outer._staticInt = 101; // additionally nope } } }How so? I think it's pretty analogous to the Java Inner Class idea.
It's a simple state machine, with classes derived from NestedClass acting as the different states. I could put together a more robust solution, but this is my compromise to rewrite as little as possible and move on.
There's definitely an element of that. The code I have now actually works fine.
It's just a big dumb mega class that Unity tends to encourage. I'm dividing up its responsibilities into a basic state machine. The inner class allows me to access the fields exposed in the outer class' inspector in Unity.
I don't java do I'm a little confused by the pattern here. What does the innerbase class bring to the table?
http://steamcommunity.com/id/pablocampy
This is in C#, but IIRC it works the same in Java. An inner class can access the private and protected members of the outer class. In cases where you need to divide up responsibilities but still have to bundle them together, this is an easy way to do that without making anything public or passing around all of the outer class' members individually.
It's sort of a niche subset of what friend classes do in C++.
https://insights.stackoverflow.com/survey/2019
PS: I'm above average, but I don't know about the rest of you guys... https://insights.stackoverflow.com/survey/2019#evaluating-competence
That just Mr. Kruger, nothing to see here!
Can't be. Developers are significantly smarter than the average population and basic psychological biases don't apply to them. I don't think you are reading this right.
I have awakened!
New thread here .