4 ms·

Re your last part - is that fair? It's very common that programmers have to end up maintaining code written in languages they don't like, due to the original au

Re your last part - is that fair? It's very common that programmers have to end up maintaining code written in languages they don't like, due to the original authors moving on, lack of better jobs in their area, whatever. People advocate against Go partly because they'd rather not have to work on Go codebases in future.

jjuel 9y ago
Well I don't want to work on C++ or Rust in the future should I go into every thread about it and slam them for their shortcomings? Should I call every dev that uses them stupid? That is what he was talking about. You can not like the language, but don't call people who do like it and use it idiots. There are better ways to get your points across.
- jaredklewis 9y ago
  Welcome to HN lol. You’ve got it easy. Try being a front end dev, because as HN will tell you, none of us know anything about computer science, which is why we are wasting our lives making over engineered bloated shit. And we have a obsession with novelty, which is why all our technical decisions are based on what is currently fashionable. HN is not a very understanding place...
  - model_m_warrior 9y ago
    Indeed, Front enders will never be the geniuses the people writing ad hoc CRUD operation end points are.
- peoplewindow 9y ago
  People do! But not as much with C++ because it's very rare to find a C++ developer who is genuinely in love with the language and is unaware of its faults. Not many people starting new C++ codebases today unless they feel they have no credible alternative choice. To a lesser extent the same is true of Rustaceans - they tend to be well aware of the constraints of their language, and won't try to defend it or pump it outside of some specific use cases. Nor do the Rust designers who are fairly humble. Nobody should be calling Go users stupid. But they typically don't. At least not here. The language itself, on the other hand ...
Thaxll 9y ago
The reason is people have no clue about Go most of the time and advocate against it because it's popular. Pretty much like Node ect... I mean look at Erlang derivates / Haskell / Rust, you don't see negativity in related language.
- candiodari 9y ago
  Or perhaps they're language geeks. Go is truly a horror show when it comes to programming language concepts. Everything about go is a complete special case. Select ... has it's own type system exceptions (and so many exceptions you might as well say Go simply has different type systems for all built in types, for all built in functions, and for several special forms). Make ... ditto. New ... ditto. "Go" same. Channels ? Effectively a separate type system. Dicts ? Same. And so on. Everything is a compiler exception. Nothing makes sense. Nothing. The absolute worst in Go, in my opinion, is the "range" function/special case. It is return-type polymorphic. That's right, it does different things depending on what you assign it's result to (not even C++ dared to go there). Not parameter polymorphic, return type polymorphic. "Assign" a range to one variable, does X, two variables, does Y, nothing ? does something else yet again, channel ? Again something else and all of these are special cases in the type system (same -but not quite the same, of course- with case, channels and dicts, by the way) Needless to say, even though you have to assign ranges to things in Go, that's the only way to use it, that assignment does something entirely different from any other assignment in Go's type system. Go is how to make a language extremely dumb and yet make have a type system that can't be (fully) described shorter than Haskell's.
  - Vendan 9y ago
    Range is hardly return-type polymorphic. It always returns the same things, you are just free to ignore them, i.e. for k := range map { } is the same thing as for k, _ := range map { } Would requiring the second version instead of the first actually be that much of an improvement? The only true return-type polymorphism is type assertions, which is reasonable in my mind cause I don't think ignoring the "assertion failed" should ever be a logical thing to do.

jjuel 9y ago

Well I don't want to work on C++ or Rust in the future should I go into every thread about it and slam them for their shortcomings? Should I call every dev that uses them stupid? That is what he was talking about. You can not like the language, but don't call people who do like it and use it idiots. There are better ways to get your points across.

jaredklewis 9y ago
Welcome to HN lol. You’ve got it easy. Try being a front end dev, because as HN will tell you, none of us know anything about computer science, which is why we are wasting our lives making over engineered bloated shit. And we have a obsession with novelty, which is why all our technical decisions are based on what is currently fashionable. HN is not a very understanding place...
- model_m_warrior 9y ago
  Indeed, Front enders will never be the geniuses the people writing ad hoc CRUD operation end points are.
peoplewindow 9y ago
People do! But not as much with C++ because it's very rare to find a C++ developer who is genuinely in love with the language and is unaware of its faults. Not many people starting new C++ codebases today unless they feel they have no credible alternative choice. To a lesser extent the same is true of Rustaceans - they tend to be well aware of the constraints of their language, and won't try to defend it or pump it outside of some specific use cases. Nor do the Rust designers who are fairly humble. Nobody should be calling Go users stupid. But they typically don't. At least not here. The language itself, on the other hand ...

Thaxll 9y ago

The reason is people have no clue about Go most of the time and advocate against it because it's popular. Pretty much like Node ect... I mean look at Erlang derivates / Haskell / Rust, you don't see negativity in related language.

candiodari 9y ago
Or perhaps they're language geeks. Go is truly a horror show when it comes to programming language concepts. Everything about go is a complete special case. Select ... has it's own type system exceptions (and so many exceptions you might as well say Go simply has different type systems for all built in types, for all built in functions, and for several special forms). Make ... ditto. New ... ditto. "Go" same. Channels ? Effectively a separate type system. Dicts ? Same. And so on. Everything is a compiler exception. Nothing makes sense. Nothing. The absolute worst in Go, in my opinion, is the "range" function/special case. It is return-type polymorphic. That's right, it does different things depending on what you assign it's result to (not even C++ dared to go there). Not parameter polymorphic, return type polymorphic. "Assign" a range to one variable, does X, two variables, does Y, nothing ? does something else yet again, channel ? Again something else and all of these are special cases in the type system (same -but not quite the same, of course- with case, channels and dicts, by the way) Needless to say, even though you have to assign ranges to things in Go, that's the only way to use it, that assignment does something entirely different from any other assignment in Go's type system. Go is how to make a language extremely dumb and yet make have a type system that can't be (fully) described shorter than Haskell's.
- Vendan 9y ago
  Range is hardly return-type polymorphic. It always returns the same things, you are just free to ignore them, i.e. for k := range map { } is the same thing as for k, _ := range map { } Would requiring the second version instead of the first actually be that much of an improvement? The only true return-type polymorphism is type assertions, which is reasonable in my mind cause I don't think ignoring the "assertion failed" should ever be a logical thing to do.