| ▲ | monksy a day ago |
| > Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with. |
|
| ▲ | Cthulhu_ a day ago | parent | next [-] |
| Counterpoint, other languages - notably Javascript, Scala, PHP, maybe Java - have taken the stance that they adopt other languages' features, not because the language needs it, but because developers were clamoring for it. Which led to added complexity, because they kept adding more and more ways to solve a problem or structure an application, which led to every codebase being so different from the next that the amount of transferable skills and knowledge became less and less. Scala is the worst offender for that IMO. One frequent praise one hears of Go is that a developer can open any codebase and immediately understand what's happening. Go is readable and stable, which are critical for code for the long term. |
| |
| ▲ | monksy a day ago | parent | next [-] | | I like scala and I think it's a great language even with teams. I think you're overlooking the context of the language. It was a language that introduced a lot of new concepts to most programmers out there on top of that it was flexible to accomidate existing Java developers (for better or for worse). It evolved and grew quite a bit. The fact that you could develop different styles made the language a lot more useful. I'm not sure what you mean by transferable skills.. but that sounds like code for overly excessive coding preferences by hiring groups. If you're working with Play you'll be able to learn Finagale, or go to Http4s. When you attack a codebase, you can't consume it and understand the full context easily, the range of operations that a code base is expected to do is far too vast for that. Even with Go, you can't just pickup and go that quickly. It may (if you're that experienced) become easier to understand. But with a large codebase, it's going to make it much harder as that it encourages large drawn out functions and verbose handling of errors. Also, Go's testing preferences tend to make it harder to write good and effective tests. | |
| ▲ | worldsayshi a day ago | parent | prev | next [-] | | The one language feature that I miss in most languages is pattern matching. I wonder if there's any minimalistic language that implements pattern matching well? | | | |
| ▲ | guappa 10 hours ago | parent | prev [-] | | I don't even need to open a go codebase to know what's happening. 60% is "if err != nil". |
|
|
| ▲ | theshrike79 a day ago | parent | prev | next [-] |
| I love the fact that I can pick up a Go project from 5+ years ago and it still compiles with the current toolchain. I might need to do a 'go mod init' first. It didn't get 67 new features that start shooting deprecation warnings on old functions in the meantime. I don't have to learn new paradigms or switch integral parts of my code to something new. Generics has been in Go for dunno how long, haven't used it once. Didn't need to. |
| |
| ▲ | monksy a day ago | parent | next [-] | | I'm not sure that's a good thing. But for your arugement, code from 5+ years ago and keeping the same deps you're mostly able to do that with java*. (With exception to some java9 and minor deprications). However, wait long enough that will come to Go, or it'll become less useful. | |
| ▲ | ralegh a day ago | parent | prev [-] | | I used generics once, was kinda useful, but definitely avoidable. The only feature I could see myself using is something Linq-esque for slices and maps. Otherwise I’m content. |
|
|
| ▲ | pmezard a day ago | parent | prev [-] |
| And a lot of people using Go have experienced other language features as well and either decided against them or that the whole tradeoff was not worth it. I will keep very fast compilation times and decade long backward compatibility over a lot of your features. Because those are features too. |
| |
| ▲ | Cthulhu_ a day ago | parent [-] | | I mean I miss some language features for sure, but the problem with adding language features is that it adds long-term inconsistency. Take a Go codebase from 10 years ago and it should look mostly the same as it would if it was rewritten in modern Go. Do the same with Java and across generations you'd go from straight for loops, to generic iterators and their for-each syntactic sugar, to for-comprehensions, streams and their functional programming style, to whatever Java is up to in 2024, I stopped paying attention years ago. |
|
