7 ms·

More golang Stockholm syndrome. These arguments are always weird to me. Go has plenty of complex features that go developers don't seem to think cause too much

More golang Stockholm syndrome. These arguments are always weird to me. Go has plenty of complex features that go developers don't seem to think cause too much cognitive burden (automatic gc, structural subtyping, etc.). Why is it that relatively simple and ubiquitous language features like exceptions and generics are just way too much and cause an unacceptable amount of complexity? I just don't buy it. Turn the argument around. Are there any Java, C++, etc. developers arguing for the removal of these features from their languages? Are there people who say that even though these languages have generics you shouldn't touch them because they're bad? Do any devs with option/maybe types really want to go back to unsafe code that can fail if you forget to check for nil/null? Show me someone who hasn't drunk the go kool-aid who still makes these sorts of arguments and I might actually start listening.

dangerlibrary 9y ago
Personally, I think checked exceptions are sometimes a headache in Java and I've worked in places where the default when encountering a checked exception was to catch and throw RuntimeException with a helpful error, which is pretty similar to Go's error/panic model.
- grasleya 9y ago
  Checked vs unchecked exceptions is kind of a separate thing from exceptions vs no exceptions. There are plenty of modern languages without checked exceptions but few with no exceptions period.
  - kasey_junk 9y ago
    Go has exceptions in the form of panics, they are discouraged and less sophisticated than other language exceptions but they certainly exist.
    - int_19h 9y ago
      There is a valid argument about whether exceptions are the best way to signal errors or not. But most modern alternatives are some form of capturing errors directly in the type system, so that return types can carry error information (option or error types etc), and so that callers are forced to check for errors.
      - kasey_junk 9y ago
        Oh I'm firmly in the monadic error return camp. Its just a misnomer that go doesn't have exceptions. It has both exceptions and by convention error returns. Its sort of the worst case scenario. I will say that there is some good post compiler tooling around making sure that error handling isn't skipped but its definitely a weakness of the language.
bredov 9y ago
Yes, google c++ style guide (https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html) recommends to avoid exception as well as complex template metaprogramming, and if one has to be used, user visible api should avoid templates if possible.
- clhodapp 9y ago
  Google recommends avoiding exceptions for a completely different reason though: Google has a massive C++ codebase that was built when C++'s particular implementation of exceptions had huge technical issues that made dangerous to use dangerous to use. Now that Google has a bunch of code that was written as if exceptions didn't exist, they have made the decision that it will be easier for Google if they just continue to pretend that exceptions don't exist, rather than having to rework (and possibly break) a bunch of already-working code.
- justicezyx 9y ago
  That mostly is a historical reason. The style is set when exceptions support in c++ is shitty. Turns out you can handling error like go in c++, or I should say go just used the proven working way of error handling in google c++. Complex templates are just a type of complexity, like any complexity, avoiding them is always the right thing to do.
  - bredov 9y ago
    So that is the point. Go design doesn't allow these complexities, so there will be no confusion when one should use them and when not. This somewhat limiting, of course, but turns out it's not the end of the world, benefits may outweigh the limitations. If you really need those, C++ is always available to you. edit: missed a word
    - camus2 9y ago
      > Go design doesn't allow these complexities, Go allows a wide range of complex metaprogramming through reflection, struct tags, ... to say that Go is void of that kind of garbage is lying. Go also has a bunch of weird rules regarding type conversion and assertion, its type system isn't covariant... Go has its share of problems, so much that go maintainers themselves keep on introducing type unsafe API in their own std lib. Go has a type system problem, period. Finally all platforms supported by Go aren't first class. Windows doesn't support Go plugins or Go shared libs AFAIK for instance.
perturbation 9y ago
I mostly agree with you, but I there could be an argument being made for C++- the generics there are done through templating, and I've seen people froth at the mouth about the complexity of C++'s template metaprogramming. I agree though with your initial reaction to Go and generics- it seems strange to argue not to include generics due to complexity when the alternative is either type assertions from interface{} types, code generation through some sort of [preprocessor](https://github.com/cheekybits/genny https://github.com/cheekybits/genny), or copy-pasting code. All of these are more complex than a simple generics implementaton! Golang could even include some sort of generics less complex than Java since it wouldn't have to worry about co vs contra variant types, and Java's generics aren't that hard to work with.
- grasleya 9y ago
  I agree that template metaprogramming can get overly complex. I think it would probably be a mistake to bolt a full C++ template metaprogramming system onto go. But just a standard generics system like Java's would go a long way to improving the language.
- deleted 9y ago
  [deleted]
Thaxll 9y ago
Removing and not using them is two different things, templating in C++ in large project leads to very complex things.
rev_null 9y ago
I think it's fair to argue that these features shouldn't be added to go. Not because they're bad features, but because they'd basically require a rewrite of the stdlib and, as a result, all go code. So, generics and exceptions would improve go. It just wouldn't be go anymore. I assumed that was what the term "Simplicity Debt" was referring to.
- clhodapp 9y ago
  Heh, perhaps the right answer is "Let Go hit its natural limits and kill itself" rather than trying to get its stewards to fix it. I suppose that might teach a whole generation of programmers what happens to codebases over time when you don't have the ability to build robust abstractions (or teach the rest of us something if it actually works out). It's just scary to actually let this go (pun intended) because the more successful Go becomes, the more likely each of us is to have to work professionally in a language without e.g. parametric polymorphism.
duncan_bayne 9y ago
> Are there any Java, C++, etc. developers arguing for the removal of these features from their languages? No, but I'll bet money that there are Java, C++, etc. developers who have abandoned those languages for Go. Developers often vote with their feet before trying to change a standard.
marcus_holmes 9y ago
If think the popularity of Go as a language (despite not having these features) is an argument that they're not actually needed. If they were really needed, then you'd have significant numbers of people trying Go and then leaving because it isn't expressive enough. Not that that doesn't happen, but we're seeing the language gain mindshare as more people appreciate the simplicity, partly due to not having these features.
43224gg252 9y ago
Java and C++ are already horrible so using every horrible feature doesn't make it worse. Source: Former Java dev
brandonbloom 9y ago
> Are there any Java, C++, etc. developers arguing for the removal of these features from their languages? I will. Generics in Java are a net loss in my opinion. They provide marginal static safety, no additional dynamic safety, no performance benefits, and lead to substantially more complex APIs. I'd have been happier if they were never added. I would prefer a Go-like type-assertion construct or an analogous "occurrence typing" feature. C#, on the other hand, has a sensible generics implementation that provides meaningful utility thanks to value types. However, I am not ashamed to admit that, in the absence of value types, I'll resort to Whatever<Object> plus some casts without a second thought if I find myself doing even the slightest bit of work to satisfy the compiler.
- hota_mazi 9y ago
  With the exception of value types, there is virtually no difference between Java and C# in terms of parametric polymorphism. Liking one and finding the other a net loss is a bit mystifying. Besides, the introduction of generics has added a tremendous amount of safety to what used to be typecast littered Java code pre 1.5.
  - brandonbloom 9y ago
    How is it mystifying? You said "besides the one difference you cited, they are not different". I explicitly listed that difference as being the thing that I feel justifies the feature's existence! > the introduction of generics has added a tremendous amount of safety It's added marginal _static_ safety. It added no dynamic safety. Static safety is welcome, but frequently not worth the lengths people go to achieve it. Hence my comment about instantiating generic types with Object in the event that the cost outweighs the safety. > to what used to be typecast littered Java code pre 1.5 Occurrence typing would dramatically minimize the syntactic overhead to casting. There have been research variations of Java that accomplished this: instanceof checks insert implicit casts on branches where the instanceof check is true. Similar extensions have been explored for collections to further omit the instanceof checks without requiring explicit type parameterization. For example, if a collection is only written to privately, you can infer casts from what types are inserted in to the collection. This can achieve the same safety without massive complexity increases to sub-typing, static dispatch, reflection, type signatures, etc.

dangerlibrary 9y ago

Personally, I think checked exceptions are sometimes a headache in Java and I've worked in places where the default when encountering a checked exception was to catch and throw RuntimeException with a helpful error, which is pretty similar to Go's error/panic model.

grasleya 9y ago
Checked vs unchecked exceptions is kind of a separate thing from exceptions vs no exceptions. There are plenty of modern languages without checked exceptions but few with no exceptions period.
- kasey_junk 9y ago
  Go has exceptions in the form of panics, they are discouraged and less sophisticated than other language exceptions but they certainly exist.
  - int_19h 9y ago
    There is a valid argument about whether exceptions are the best way to signal errors or not. But most modern alternatives are some form of capturing errors directly in the type system, so that return types can carry error information (option or error types etc), and so that callers are forced to check for errors.
    - kasey_junk 9y ago
      Oh I'm firmly in the monadic error return camp. Its just a misnomer that go doesn't have exceptions. It has both exceptions and by convention error returns. Its sort of the worst case scenario. I will say that there is some good post compiler tooling around making sure that error handling isn't skipped but its definitely a weakness of the language.

bredov 9y ago

Yes, google c++ style guide (https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html) recommends to avoid exception as well as complex template metaprogramming, and if one has to be used, user visible api should avoid templates if possible.

clhodapp 9y ago
Google recommends avoiding exceptions for a completely different reason though: Google has a massive C++ codebase that was built when C++'s particular implementation of exceptions had huge technical issues that made dangerous to use dangerous to use. Now that Google has a bunch of code that was written as if exceptions didn't exist, they have made the decision that it will be easier for Google if they just continue to pretend that exceptions don't exist, rather than having to rework (and possibly break) a bunch of already-working code.
justicezyx 9y ago
That mostly is a historical reason. The style is set when exceptions support in c++ is shitty. Turns out you can handling error like go in c++, or I should say go just used the proven working way of error handling in google c++. Complex templates are just a type of complexity, like any complexity, avoiding them is always the right thing to do.
- bredov 9y ago
  So that is the point. Go design doesn't allow these complexities, so there will be no confusion when one should use them and when not. This somewhat limiting, of course, but turns out it's not the end of the world, benefits may outweigh the limitations. If you really need those, C++ is always available to you. edit: missed a word
  - camus2 9y ago
    > Go design doesn't allow these complexities, Go allows a wide range of complex metaprogramming through reflection, struct tags, ... to say that Go is void of that kind of garbage is lying. Go also has a bunch of weird rules regarding type conversion and assertion, its type system isn't covariant... Go has its share of problems, so much that go maintainers themselves keep on introducing type unsafe API in their own std lib. Go has a type system problem, period. Finally all platforms supported by Go aren't first class. Windows doesn't support Go plugins or Go shared libs AFAIK for instance.

perturbation 9y ago

I mostly agree with you, but I there could be an argument being made for C++- the generics there are done through templating, and I've seen people froth at the mouth about the complexity of C++'s template metaprogramming. I agree though with your initial reaction to Go and generics- it seems strange to argue not to include generics due to complexity when the alternative is either type assertions from interface{} types, code generation through some sort of [preprocessor](https://github.com/cheekybits/genny https://github.com/cheekybits/genny), or copy-pasting code. All of these are more complex than a simple generics implementaton! Golang could even include some sort of generics less complex than Java since it wouldn't have to worry about co vs contra variant types, and Java's generics aren't that hard to work with.

grasleya 9y ago
I agree that template metaprogramming can get overly complex. I think it would probably be a mistake to bolt a full C++ template metaprogramming system onto go. But just a standard generics system like Java's would go a long way to improving the language.
deleted 9y ago
[deleted]

Thaxll 9y ago

Removing and not using them is two different things, templating in C++ in large project leads to very complex things.

rev_null 9y ago

I think it's fair to argue that these features shouldn't be added to go. Not because they're bad features, but because they'd basically require a rewrite of the stdlib and, as a result, all go code. So, generics and exceptions would improve go. It just wouldn't be go anymore. I assumed that was what the term "Simplicity Debt" was referring to.

clhodapp 9y ago
Heh, perhaps the right answer is "Let Go hit its natural limits and kill itself" rather than trying to get its stewards to fix it. I suppose that might teach a whole generation of programmers what happens to codebases over time when you don't have the ability to build robust abstractions (or teach the rest of us something if it actually works out). It's just scary to actually let this go (pun intended) because the more successful Go becomes, the more likely each of us is to have to work professionally in a language without e.g. parametric polymorphism.

duncan_bayne 9y ago

> Are there any Java, C++, etc. developers arguing for the removal of these features from their languages? No, but I'll bet money that there are Java, C++, etc. developers who have abandoned those languages for Go. Developers often vote with their feet before trying to change a standard.

marcus_holmes 9y ago

If think the popularity of Go as a language (despite not having these features) is an argument that they're not actually needed. If they were really needed, then you'd have significant numbers of people trying Go and then leaving because it isn't expressive enough. Not that that doesn't happen, but we're seeing the language gain mindshare as more people appreciate the simplicity, partly due to not having these features.

43224gg252 9y ago

Java and C++ are already horrible so using every horrible feature doesn't make it worse. Source: Former Java dev

brandonbloom 9y ago

> Are there any Java, C++, etc. developers arguing for the removal of these features from their languages? I will. Generics in Java are a net loss in my opinion. They provide marginal static safety, no additional dynamic safety, no performance benefits, and lead to substantially more complex APIs. I'd have been happier if they were never added. I would prefer a Go-like type-assertion construct or an analogous "occurrence typing" feature. C#, on the other hand, has a sensible generics implementation that provides meaningful utility thanks to value types. However, I am not ashamed to admit that, in the absence of value types, I'll resort to Whatever<Object> plus some casts without a second thought if I find myself doing even the slightest bit of work to satisfy the compiler.

hota_mazi 9y ago
With the exception of value types, there is virtually no difference between Java and C# in terms of parametric polymorphism. Liking one and finding the other a net loss is a bit mystifying. Besides, the introduction of generics has added a tremendous amount of safety to what used to be typecast littered Java code pre 1.5.
- brandonbloom 9y ago
  How is it mystifying? You said "besides the one difference you cited, they are not different". I explicitly listed that difference as being the thing that I feel justifies the feature's existence! > the introduction of generics has added a tremendous amount of safety It's added marginal _static_ safety. It added no dynamic safety. Static safety is welcome, but frequently not worth the lengths people go to achieve it. Hence my comment about instantiating generic types with Object in the event that the cost outweighs the safety. > to what used to be typecast littered Java code pre 1.5 Occurrence typing would dramatically minimize the syntactic overhead to casting. There have been research variations of Java that accomplished this: instanceof checks insert implicit casts on branches where the instanceof check is true. Similar extensions have been explored for collections to further omit the instanceof checks without requiring explicit type parameterization. For example, if a collection is only written to privately, you can infer casts from what types are inserted in to the collection. This can achieve the same safety without massive complexity increases to sub-typing, static dispatch, reflection, type signatures, etc.