3 ms·

I've coded golang for four years. Web services. I hated it at the start and I hate it even more now. The generics are miserable to use and are very limited in w

I've coded golang for four years. Web services. I hated it at the start and I hate it even more now. The generics are miserable to use and are very limited in what they can do, the standard library is awful (database/sql in particular is offensively bad, but you have to use it because all the third party tools rely on its interfaces), there's footguns and dangerous syntax subtleties everywhere, and the idea of the zero values for uninitialized struct fields is to me an even worse mistake than the concept of null. At least if you make a mistake with null the program crashes, which is obvious, instead of just silently doing the wrong thing, which is not. The language claims to be simple; it's not, it's just pointlessly restrictive in weird ways wherever it happens to offend Rob Pike's personal sense of aesthetics. At least it compiles quickly, I guess??? I wish we could use some boring language that works, like C# or Kotlin.

elvlysh 2y ago
More than one person designed the language than Pike, you know. He's retired. Maybe you can find another member of the devteam to pick on?
- renhanxue 2y ago
  Both (for example) Russ Cox and Ian Lance Taylor have contributed some very notably bad ideas to the project, yes. Does rephrasing it to "Rob Pike and people who think like him" make you happier?
  - elvlysh 2y ago
    "bad" ideas? Really? Are you so sure? Are your ideas really any better? What language have you made that has seen more success than Go? Clearly if they did such a bad job it would be easy for you to fix it all up and tell everyone about it.
    - int_19h 2y ago
      Go is basically a reinvention of a 30-year-old wheel. Why would someone who dislikes it for that reason want to reinvent the wheel themselves? There are already many better languages out there. In any case, designing and even implementing a PL better than Go is not a particularly hard thing to do. Making it popular in this day and age, on the other hand, generally requires a large corporation backing you.
      - deleted 2y ago
        [deleted]
      - elvlysh 2y ago
        How come a reinvention of a 30 year old wheel is more successful and popular than pretty much every language that attempted to evolve the wheel during that time? "It's because people who like Go are stupid and companies need stupid people to write stupid code" may have made you feel smug and secure during the last 15 years, but what about the next 15? Or the 15 after that? Are you still going to be complaining about the stupid 70 year old wheel made by that dumb guy Pike that you hate so much?
        int_19h 2y ago
        If you really want to make an argument from popularity, C, C++, C#, and Java are all more popular than Go.
        elvlysh 2y ago
        Yes, and all are equally offensive to the average Go hater, all of them have NULL, and all of them have terrible error handling. It's not "argument from popularity", it's "argument from success". Some things succeed. Other things don't. It would be worthwhile for you to investigate why things succeed despite all the hangups you have with their flaws instead of lamenting them because the things you like aren't succeeding.
        int_19h 2y ago
int_19h 2y ago
I'm not a Go fan to put it mildly, but C# also has the notion of zero values for structs, and for the exact same reason as Go. E.g. in something like: struct Foo { int X; } class Bar { Foo F; } the value of (new Bar().F.X) is zero.
- neonsunset 2y ago
  With NRTs this is a warning however for class-typed fields. Also `required` forces you to assign a value to it. Honestly I always thought struct init semantics in C# were slightly archaic and F# does it better by being strict in a way similar to Rust, so touching Go afterwards is a really big step back. (i.e. you can author default constructor and field initializers for structs, in C#, the main "hole" remains the use of 'default(MyStruct)', but at least it is explicit and you get what you ask for)
  - int_19h 2y ago
    The real problem is downcasting (and virtual dispatch as a form of implicit downcast during dispatch). Consider: new Derived(); class Base { public Base() { Foo(); } public virtual void Foo() {} } class Derived: Base { public string s; // non-null! public Derived() { s = "abc"; } public override void Foo() { WriteLine(s == null); } } This will compile without warnings even with #nullable enable, and will print True at runtime. Note that this could also be rewritten without virtual methods by doing a downcast or pattern match: void Foo(Base b) { WriteLine(((Derived)b).s == null); } C++ solves this problem by making all virtual calls dispatch to Base until Base() completes (which involves swapping vtable pointers at runtime as needed), and then doing the same in reverse for destructors; it also makes the type of object Base for all other purposes like dynamic_cast. That is, in effect, in C++ the actual type of the object changes as it is constructed or destructed. Which is great from a theoretical point of view, but very counter-intuitive unless you understand the problem it's trying to solve. That aside, with respect to default(T), the other problem is arrays. If T is non-nullable and you ask for a new T[1], what should the value of the element be? C# lies and allows it to be null even for non-nullable reference types, which means that (new string[1])[0].ToString() is an NRE with no compiler diagnostic even with #nullable enabled. In C++, you actually cannot do this at all if T doesn't have a default constructor, but this then means that the language needs stuff like in-place new and explicit destructor calls to actually make a generic dynamic array possible to implement.

elvlysh 2y ago

More than one person designed the language than Pike, you know. He's retired. Maybe you can find another member of the devteam to pick on?

renhanxue 2y ago
Both (for example) Russ Cox and Ian Lance Taylor have contributed some very notably bad ideas to the project, yes. Does rephrasing it to "Rob Pike and people who think like him" make you happier?
- elvlysh 2y ago
  "bad" ideas? Really? Are you so sure? Are your ideas really any better? What language have you made that has seen more success than Go? Clearly if they did such a bad job it would be easy for you to fix it all up and tell everyone about it.
  - int_19h 2y ago
    Go is basically a reinvention of a 30-year-old wheel. Why would someone who dislikes it for that reason want to reinvent the wheel themselves? There are already many better languages out there. In any case, designing and even implementing a PL better than Go is not a particularly hard thing to do. Making it popular in this day and age, on the other hand, generally requires a large corporation backing you.
    - deleted 2y ago
      [deleted]
    - elvlysh 2y ago
      How come a reinvention of a 30 year old wheel is more successful and popular than pretty much every language that attempted to evolve the wheel during that time? "It's because people who like Go are stupid and companies need stupid people to write stupid code" may have made you feel smug and secure during the last 15 years, but what about the next 15? Or the 15 after that? Are you still going to be complaining about the stupid 70 year old wheel made by that dumb guy Pike that you hate so much?
      - int_19h 2y ago
        If you really want to make an argument from popularity, C, C++, C#, and Java are all more popular than Go.
        elvlysh 2y ago
        Yes, and all are equally offensive to the average Go hater, all of them have NULL, and all of them have terrible error handling. It's not "argument from popularity", it's "argument from success". Some things succeed. Other things don't. It would be worthwhile for you to investigate why things succeed despite all the hangups you have with their flaws instead of lamenting them because the things you like aren't succeeding.
        int_19h 2y ago

int_19h 2y ago

I'm not a Go fan to put it mildly, but C# also has the notion of zero values for structs, and for the exact same reason as Go. E.g. in something like: struct Foo { int X; } class Bar { Foo F; } the value of (new Bar().F.X) is zero.

neonsunset 2y ago
With NRTs this is a warning however for class-typed fields. Also `required` forces you to assign a value to it. Honestly I always thought struct init semantics in C# were slightly archaic and F# does it better by being strict in a way similar to Rust, so touching Go afterwards is a really big step back. (i.e. you can author default constructor and field initializers for structs, in C#, the main "hole" remains the use of 'default(MyStruct)', but at least it is explicit and you get what you ask for)
- int_19h 2y ago
  The real problem is downcasting (and virtual dispatch as a form of implicit downcast during dispatch). Consider: new Derived(); class Base { public Base() { Foo(); } public virtual void Foo() {} } class Derived: Base { public string s; // non-null! public Derived() { s = "abc"; } public override void Foo() { WriteLine(s == null); } } This will compile without warnings even with #nullable enable, and will print True at runtime. Note that this could also be rewritten without virtual methods by doing a downcast or pattern match: void Foo(Base b) { WriteLine(((Derived)b).s == null); } C++ solves this problem by making all virtual calls dispatch to Base until Base() completes (which involves swapping vtable pointers at runtime as needed), and then doing the same in reverse for destructors; it also makes the type of object Base for all other purposes like dynamic_cast. That is, in effect, in C++ the actual type of the object changes as it is constructed or destructed. Which is great from a theoretical point of view, but very counter-intuitive unless you understand the problem it's trying to solve. That aside, with respect to default(T), the other problem is arrays. If T is non-nullable and you ask for a new T[1], what should the value of the element be? C# lies and allows it to be null even for non-nullable reference types, which means that (new string[1])[0].ToString() is an NRE with no compiler diagnostic even with #nullable enabled. In C++, you actually cannot do this at all if T doesn't have a default constructor, but this then means that the language needs stuff like in-place new and explicit destructor calls to actually make a generic dynamic array possible to implement.