3 ms·

> Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools This is not reasonable. Go's concurrency shin

by tapirl 7y ago

> Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools This is not reasonable. Go's concurrency shines for its flexibility. It has nothing related to whether or not the written programs are short/long-lived. It is the only language which gives me a happy and fun experience in concurrent programming. > For long lived processes though, like most services, it feels very error-prone or very boilerplatey and manual. This is not reasonable too. Whether or not a written program is robust depends on the experience of the authors. Rust may reduce many mistakes at compile time, but it can't prevent all mistakes. Programmers still need experience to avoid many mistakes.

Groxx 7y ago
That's kinda like saying "language ergonomics and api design don't matter, you just need to be careful". Which is true to some degree, you can build anything in anything if you're careful enough. But programming history is full of repeated, preventable errors, and languages where X error is impossible or much less likely if you're less than perfect. Go's rather far down "unsafe" in my books, especially in regards to concurrency and error handling. For simple code, it's pleasantly simple. For larger, robust code, it's several times more verbose than other langs I've used, and often requires continually re-implementing common "wheels" (that should not usually be written by hand, as they're finnicky to get right, which is also easy to miss in code review) to get around a lack of generics.
- tapirl 7y ago
  Go's concurrency features provide a larger super set of possibilities of other language. If you only do concurrency programming in a simple way (just as most languages), it is hard to make some mistakes even if you are a moderate Go programmer. On the other hand, Go allows you to do concurrency programming with many creative ideas which are hard to apply in other languages. Surely, you should be an experienced Go programmer to implement these creative ideas. Rust does prevent some errors at compile time, but achieving this has its own cost, such as sacrificing flexibility and simplicity. For many use cases, the sacrifices are not worth it. > it's several times more verbose than other langs I've used, and often requires continually re-implementing common "wheels" If the common wheels need generics to implement, I have nothing to defend. I can only say generics will come to Go eventually.

by tapirl 7y ago

Groxx 7y ago

That's kinda like saying "language ergonomics and api design don't matter, you just need to be careful". Which is true to some degree, you can build anything in anything if you're careful enough. But programming history is full of repeated, preventable errors, and languages where X error is impossible or much less likely if you're less than perfect. Go's rather far down "unsafe" in my books, especially in regards to concurrency and error handling. For simple code, it's pleasantly simple. For larger, robust code, it's several times more verbose than other langs I've used, and often requires continually re-implementing common "wheels" (that should not usually be written by hand, as they're finnicky to get right, which is also easy to miss in code review) to get around a lack of generics.

tapirl 7y ago
Go's concurrency features provide a larger super set of possibilities of other language. If you only do concurrency programming in a simple way (just as most languages), it is hard to make some mistakes even if you are a moderate Go programmer. On the other hand, Go allows you to do concurrency programming with many creative ideas which are hard to apply in other languages. Surely, you should be an experienced Go programmer to implement these creative ideas. Rust does prevent some errors at compile time, but achieving this has its own cost, such as sacrificing flexibility and simplicity. For many use cases, the sacrifices are not worth it. > it's several times more verbose than other langs I've used, and often requires continually re-implementing common "wheels" If the common wheels need generics to implement, I have nothing to defend. I can only say generics will come to Go eventually.