4 ms·

>GO syntax is very regressive comparing to where we hopped programming languages should go. Speak for yourself maybe, but I appreciate Go's overall style. You

by F-0X 7y ago

>GO syntax is very regressive comparing to where we hopped programming languages should go. Speak for yourself maybe, but I appreciate Go's overall style. You also mention Rust and Scala in your post. If that is to be the future of language syntax, I should quit.

minxomat 7y ago
The syntax being regressive is pretty objective. It's not a value judgement. It has it's pros and cons.
shantly 7y ago
I like that I can dive into pretty much any Go code and it won't be doing anything basic some way I'm not used to or can't very quickly figure out without having to look anything up. Kinda like Java in that regard, but even more so, plus way less verbose. I mean it's gotten better but take Javascript where just a few years ago fundamental branching & execution order and might be provided by some library and it wasn't always the same one (thinking especially of various competing promise libraries) or friggin' imports might look different. Or Rails where you might have a codebase come across your laptop that's in some version you haven't used recently and using a bunch of libraries you're not used to and now half the symbols in a given file aren't defined there or anywhere else that Grep can find and it's unclear where they even come from, so it's off to the docs for a bunch of abandoned gems to get any sense of what's even going on. Go mostly avoids that sort of deeply unproductive junk. It does achieve that by not providing certain things, plus static typing (thank god for TypeScript, finally some sanity). I'm OK with that. I don't use it as my daily driver but I'm never even a little sad to drop into or contribute to a Go codebase, and I don't need a huge margin of uncertainty on the question "how fast can you get up to speed with this?" for Go code, which I can't say of just about any other language, sight-unseen.
- spullara 7y ago
  Go is pretty verbose, especially error handling, vs modern Java code.
  - reificator 7y ago
    You and I clearly have different error handling strategies. I will say that a rust-style error propagation operator would cut verbosity even further. (Though that is harder to do in go with their choice of multiple return over sum types.) Still, try/catch seems far more verbose for common error handling strategies to me. And I'd rather see an acknowledgement that something can fail as close to that thing as possible, rather than hunting thorough the stack to find some global try/catch block that silently swallows the error in order to cut down on verbosity.
    - spullara 7y ago
      I'd rather have the choice to handle it locally or not. If you have bad habits you have bad habits and another language isn't going to fix that. If Go adapts Rust style then I would agree, it could get to be where you can choose to handle the errors locally or up the stack, like exceptions, and you will be in a better place.
      - reificator 7y ago
        It's less about bad habits and more about there being a clear and consistent signal for what can throw or not. It's similar to why I like options over nulls despite the fact that you're basically doing the same thing in both systems. If only Java's particular implementation hadn't ruined the public opinion on checked exceptions...
        kjeetgill 7y ago
        What do you think is the best way to handle checked exceptions? This comes up all the time on HN and I've personally landed on preferring Java's checked/unchecked system from anything else I've seen. I get that sometimes you should handle your errors in the small, like Go's errors or Rust's Maybe (or Try?) styles might prefer, but I hate not having any exceptions options to "let things crash".
        7y ago
- erik_seaberg 7y ago
  If experts' code never becomes more clear and concise than novices', there's no payoff for getting better with the language, and nobody ever really gets up to speed.
  - zxcmx 7y ago
    Big IMHO disclaimer, but: Yes! If expert code and novice code look pretty much the same, that is great! I think rather than futzing around with the language, go frees you to think harder about the problem domain. Better architecture, design decisions, problem domain modelling, documentation / communication, core data structure and algorithm selection, api design - these are the things that distinguish expert from novice output, not statement level expressiveness. There's obviously a line to be drawn somewhere! - an expert can write "good" code and develop useful systems in GW Basic, but few would voluntarily choose to in 2019. Really though, the runtime limits the problems you can solve in GW Basic more than the language syntax. I think this is why go focuses a lot on the runtime - low latency gc, concurrency, etc - at the high end of programming ability the limits on what problems you can solve in a language (without dropping down / calling out) are dictated by the power of your runtime, not language syntax. As a data point, when I think about programmers with the most impactful software outputs (rather than talks, essays etc) it's hard to overlook the C programmers. Git could have been written in any number of languages but fairly straightforward C is enough to get the job done. The "expert" work in git exists at a much higher level than the source code.
  - nemothekid 7y ago
    >there's no payoff for getting better with the language, and nobody ever really gets up to speed. Or maybe it's an indication that I should spend less time playing code golf and more time building what I actually set out to build. I'd imagine an expert could write a better, performant database than a novice and the fact that can be achieved in language that will effectively communicate to a novice is arguably a good thing.
    - erik_seaberg 7y ago
      Novices should see queues and sorted sets by their proper names. They should see reduce(map(filter(…))), not big loops that inline all three written from scratch repeatedly because experts didn't want the compiler doing work that might make it slower.

by F-0X 7y ago

minxomat 7y ago

The syntax being regressive is pretty objective. It's not a value judgement. It has it's pros and cons.

shantly 7y ago

I like that I can dive into pretty much any Go code and it won't be doing anything basic some way I'm not used to or can't very quickly figure out without having to look anything up. Kinda like Java in that regard, but even more so, plus way less verbose. I mean it's gotten better but take Javascript where just a few years ago fundamental branching & execution order and might be provided by some library and it wasn't always the same one (thinking especially of various competing promise libraries) or friggin' imports might look different. Or Rails where you might have a codebase come across your laptop that's in some version you haven't used recently and using a bunch of libraries you're not used to and now half the symbols in a given file aren't defined there or anywhere else that Grep can find and it's unclear where they even come from, so it's off to the docs for a bunch of abandoned gems to get any sense of what's even going on. Go mostly avoids that sort of deeply unproductive junk. It does achieve that by not providing certain things, plus static typing (thank god for TypeScript, finally some sanity). I'm OK with that. I don't use it as my daily driver but I'm never even a little sad to drop into or contribute to a Go codebase, and I don't need a huge margin of uncertainty on the question "how fast can you get up to speed with this?" for Go code, which I can't say of just about any other language, sight-unseen.

spullara 7y ago
Go is pretty verbose, especially error handling, vs modern Java code.
- reificator 7y ago
  You and I clearly have different error handling strategies. I will say that a rust-style error propagation operator would cut verbosity even further. (Though that is harder to do in go with their choice of multiple return over sum types.) Still, try/catch seems far more verbose for common error handling strategies to me. And I'd rather see an acknowledgement that something can fail as close to that thing as possible, rather than hunting thorough the stack to find some global try/catch block that silently swallows the error in order to cut down on verbosity.
  - spullara 7y ago
    I'd rather have the choice to handle it locally or not. If you have bad habits you have bad habits and another language isn't going to fix that. If Go adapts Rust style then I would agree, it could get to be where you can choose to handle the errors locally or up the stack, like exceptions, and you will be in a better place.
    - reificator 7y ago
      It's less about bad habits and more about there being a clear and consistent signal for what can throw or not. It's similar to why I like options over nulls despite the fact that you're basically doing the same thing in both systems. If only Java's particular implementation hadn't ruined the public opinion on checked exceptions...
      - kjeetgill 7y ago
        What do you think is the best way to handle checked exceptions? This comes up all the time on HN and I've personally landed on preferring Java's checked/unchecked system from anything else I've seen. I get that sometimes you should handle your errors in the small, like Go's errors or Rust's Maybe (or Try?) styles might prefer, but I hate not having any exceptions options to "let things crash".
        7y ago
erik_seaberg 7y ago
If experts' code never becomes more clear and concise than novices', there's no payoff for getting better with the language, and nobody ever really gets up to speed.
- zxcmx 7y ago
  Big IMHO disclaimer, but: Yes! If expert code and novice code look pretty much the same, that is great! I think rather than futzing around with the language, go frees you to think harder about the problem domain. Better architecture, design decisions, problem domain modelling, documentation / communication, core data structure and algorithm selection, api design - these are the things that distinguish expert from novice output, not statement level expressiveness. There's obviously a line to be drawn somewhere! - an expert can write "good" code and develop useful systems in GW Basic, but few would voluntarily choose to in 2019. Really though, the runtime limits the problems you can solve in GW Basic more than the language syntax. I think this is why go focuses a lot on the runtime - low latency gc, concurrency, etc - at the high end of programming ability the limits on what problems you can solve in a language (without dropping down / calling out) are dictated by the power of your runtime, not language syntax. As a data point, when I think about programmers with the most impactful software outputs (rather than talks, essays etc) it's hard to overlook the C programmers. Git could have been written in any number of languages but fairly straightforward C is enough to get the job done. The "expert" work in git exists at a much higher level than the source code.
- nemothekid 7y ago
  >there's no payoff for getting better with the language, and nobody ever really gets up to speed. Or maybe it's an indication that I should spend less time playing code golf and more time building what I actually set out to build. I'd imagine an expert could write a better, performant database than a novice and the fact that can be achieved in language that will effectively communicate to a novice is arguably a good thing.
  - erik_seaberg 7y ago
    Novices should see queues and sorted sets by their proper names. They should see reduce(map(filter(…))), not big loops that inline all three written from scratch repeatedly because experts didn't want the compiler doing work that might make it slower.