3 ms·

- Fast compilation In return, you spend more time debugging since there are no interesting static guarantees. - Multi platform So is Rust? Even if it weren't

- Fast compilation In return, you spend more time debugging since there are no interesting static guarantees. - Multi platform So is Rust? Even if it weren't, you've already tied yourself to the platform support of Rust at this point. - Great tooling Not familiar enough to comment on this one. - Good std lib I can't take Go's stdlib seriously with the way they handle errors. - Easy learning curve Despite using it for a year I still have to google Go's syntax and semantics daily. By far the least consistent and hardest to learn general purpose language I have touched. - Fast enough for most scenarios Sure. - Good concurrency model This is literally just wrong. How can you claim to be serious about concurrency when you have no concept of immutability in your language?

Vendan 9y ago
- - Fast compilation - In return, you spend more time debugging since there are no interesting static guarantees. I spend almost no time debugging my Go code... It generally either works correctly, or fails to compile... and in the cases where it doesn't work correctly, I'd prefer to have a test that makes it obvious what went wrong, and then make the test pass. - - Great tooling - Not familiar enough to comment on this one. Go's tooling is one of the reasons I use it, esp. the very strict formatting style - - Good std lib - I can't take Go's stdlib seriously with the way they handle errors. I prefer the way Go handles errors, cause it makes it so all control flow is visible by default. - - Easy learning curve - Despite using it for a year I still have to google Go's syntax and semantics daily. By far the least consistent and hardest to learn general purpose language I have touched. I'd seriously question this, I was competent in the language after about a week, meaning at the point of just having to look up package specific stuff. Granted, I have a lot of background in C family languages, but still... - - Good concurrency model - This is literally just wrong. How can you claim to be serious about concurrency when you have no concept of immutability in your language? Share memory by communicating, don't communicate by sharing memory. Yes, it's completely different from what most people are used to, but it's a valid paradigm. I'd go look up "communicating sequential processes" and do some reading if I were you.
- dbaupp 9y ago
  > Share memory by communicating, don't communicate by sharing memory. I suspect the parent was referring to the fact that Go just has this as a convention, there's no static guarantee that the programmer gets it right and it is undefined behaviour if they don't (fortunately the race detector exists). Interestingly, Rust does provide guarantees about this sort of concurrency patterns, allowing one to get stronger control around sharing using Go/CSP-like channels.
  - Vendan 9y ago
    Yes, but saying it doesn't have a concurrency model cause it's missing a feature that's arguably irrelevant to the concurrency model that's recommended by the language is pointless, and seemingly serves no other reason then to attack the language.
    - dbaupp 9y ago
      Having some "feature" that means the concurrency model is sound (aka without undefined behaviour) isn't irrelevant to concurrency models. (I quoted feature because there's a variety of different ways to get this guarantee, some of which don't feel like language features, per se.) On the other hand, it's fair that the convention/tooling is usually good enough; this is a stronger argument and probably a better one to be making than a dubious one about being irrelevant.
- kmicklas 9y ago
  > Share memory by communicating, don't communicate by sharing memory. Yes, it's completely different from what most people are used to, but it's a valid paradigm. I'd go look up "communicating sequential processes" and do some reading if I were you. LOL this is the classic sort of condescension from the Go community that makes the programming languages community rage. There is a lot of irony here because Go is basically founded on an anti-intellectual ignoring of all previous research.
  - Vendan 9y ago

Vendan 9y ago

- - Fast compilation - In return, you spend more time debugging since there are no interesting static guarantees. I spend almost no time debugging my Go code... It generally either works correctly, or fails to compile... and in the cases where it doesn't work correctly, I'd prefer to have a test that makes it obvious what went wrong, and then make the test pass. - - Great tooling - Not familiar enough to comment on this one. Go's tooling is one of the reasons I use it, esp. the very strict formatting style - - Good std lib - I can't take Go's stdlib seriously with the way they handle errors. I prefer the way Go handles errors, cause it makes it so all control flow is visible by default. - - Easy learning curve - Despite using it for a year I still have to google Go's syntax and semantics daily. By far the least consistent and hardest to learn general purpose language I have touched. I'd seriously question this, I was competent in the language after about a week, meaning at the point of just having to look up package specific stuff. Granted, I have a lot of background in C family languages, but still... - - Good concurrency model - This is literally just wrong. How can you claim to be serious about concurrency when you have no concept of immutability in your language? Share memory by communicating, don't communicate by sharing memory. Yes, it's completely different from what most people are used to, but it's a valid paradigm. I'd go look up "communicating sequential processes" and do some reading if I were you.

dbaupp 9y ago
> Share memory by communicating, don't communicate by sharing memory. I suspect the parent was referring to the fact that Go just has this as a convention, there's no static guarantee that the programmer gets it right and it is undefined behaviour if they don't (fortunately the race detector exists). Interestingly, Rust does provide guarantees about this sort of concurrency patterns, allowing one to get stronger control around sharing using Go/CSP-like channels.
- Vendan 9y ago
  Yes, but saying it doesn't have a concurrency model cause it's missing a feature that's arguably irrelevant to the concurrency model that's recommended by the language is pointless, and seemingly serves no other reason then to attack the language.
  - dbaupp 9y ago
    Having some "feature" that means the concurrency model is sound (aka without undefined behaviour) isn't irrelevant to concurrency models. (I quoted feature because there's a variety of different ways to get this guarantee, some of which don't feel like language features, per se.) On the other hand, it's fair that the convention/tooling is usually good enough; this is a stronger argument and probably a better one to be making than a dubious one about being irrelevant.
kmicklas 9y ago
> Share memory by communicating, don't communicate by sharing memory. Yes, it's completely different from what most people are used to, but it's a valid paradigm. I'd go look up "communicating sequential processes" and do some reading if I were you. LOL this is the classic sort of condescension from the Go community that makes the programming languages community rage. There is a lot of irony here because Go is basically founded on an anti-intellectual ignoring of all previous research.
- Vendan 9y ago