5 ms·

Good write up. I can agree with him on a couple of points. I've found Rust code to become terribly verbose and unreadable for certain tasks. You have to be ca

Good write up. I can agree with him on a couple of points. I've found Rust code to become terribly verbose and unreadable for certain tasks. You have to be careful to not end up with messy and hard to read code. Lifetimes of course make it even worse. Some common patterns are hard / awkward to implement. The stdlib is (intentionally) very small, and throwing together various crates adds a considerable maintenance overhead. Overall I find Rust really promising though. It might need a few more years to mature. I totally agree on Go: I intially really loved it and used it all the time. The more code, and especially the more reusable libraries I wrote, I started hating it more and more, to the point where I only touch Go if I have to, or for small, one-off, self contained projects that need a bit more perf than Python or where Haskell is not appropriate (team, problem space). The only thing that's a plus for go is it's dead-easy concurrency.

cm3 10y ago
> The only thing that's a plus for go is it's dead-easy concurrency. Since you mention Haskell, I would like to say that Haskell's concurrency support is more diverse and at least as easy as Go's.
- masklinn 10y ago
  > I would like to say that Haskell's concurrency support is more diverse and at least as easy as Go's. More diverse is easy, Go is opinionated about its concurrency. "At least as easy" is a flaming lie. The diversity alone makes it impossible but beyond that: * when you look for concurrent go you're introduced to 3 constructs (`go`, channels and `select`) and you're off to the race having barely learned the language * when you look for concurrent haskell you're directed towards the corresponding paper, "tackling the awkward squad" and a world of Async, MVar, ThreadId, STM and various types of Chan, and at that point you still can't write a line of concurrent haskell Like the_duke I don't enjoy Go, but with respect to dead-easy concurrency the only language that's in the same ballpark is Erlang (and it's similarly boiled down to a complete lack of diversity — though a different model than Go's — and three basic constructs: `spawn`, `receive` and `!`).
  - mitchty 10y ago
    > * when you look for concurrent haskell you're directed towards the corresponding paper, "tackling the awkward squad" and a world of Async, MVar, ThreadId, STM and various types of Chan, and at that point you still can't write a line of concurrent haskell I was directed here: http://community.haskell.org/~simonmar/pcph/ http://community.haskell.org/~simonmar/pcph/ And after reading the first few chapters, I'd place go's options under the Rich Hickey quote of simple versus easy. Additionally I sped up a simulated annealing program with the accelerate framework in Haskell by typing "Acc " twice. From 1 000 iterations/minute to about 500 000. I'd call that an easy win. Haskell also allows for more than simply concurrent programming. I always ended up with locks in go and wondering why I was using it over c with an event loop and threads at that point.
    - cm3 10y ago
      Yeah, also the STM support is often overlooked and is a good fit for some tasks where everything else is much harder.
    - jerf 10y ago
      Haskell's concurrency advantage is that the answer to the question "Does Haskell have X concurrency construct?" is "yes", and additionally, it's generally safe to use because everything is immutable. It even has support for things that have proved difficult or impossible in almost every other context because of that immutability, most notably STM. Haskell's concurrency disadvantage is the same set of answers to the same question. It intrinsically has a big toolbox to start with, and a bigger one once you get into the libraries that implement further things on top of it (the pipe libraries, for instance), and that intrinsically makes it harder. So, for instance, yes, you certainly sped up your program very easily, but new users often have a hard time finding their way to the best resources, and if their problem is not a trivially parallelizable algorithm, which it sounds like you had, there can still be some trouble in figuring out which concurrency construct they need.
      - dbaupp 10y ago
        STM is useless with full immutability: it is safe in Haskell because effects (including mutation) can be controlled/packaged into contained areas, via abstractions like monads. That said, one downside of STM is that it isn't as efficient as some other schemes especially with high contention, as everything gets serialized through the metadata for tracking transactions. It's an awesome tool, but not a panacea (like with any other technology). (I'm sure you know this, but others reading the thread may not.)
sethammons 10y ago
I've not looked at Rust, but I've been using Go in production now for years at this point with non-trivial code bases. In our cases, they are mostly SMTP and HTTP servers. Sometimes the boiler plate gets in the way (and I think Go should almost never be used for simple CRUD stuff, there are better options), but I find the readability fantastic. It really dawned on my how readable it can be when I had to fix a missed condition in clean up on shutdown. It was fixed in an hour. For the perl version that the Go one replaced, it would have been a day before I even understood what would have needed fixing.
- stormcrowsx 10y ago
  Really not a property of Go. Any codebase can be hard to follow if the designer wants it to be. It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code.
  - kbenson 10y ago
    > It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code. That's one way to look at it. The other is that they embedded more syntax which makes the learning curve longer, but yields more more efficient writing and reading of code once you've fully internalized that syntax. The big mistake, IMO, was that they also made the language easily usable to get something done before you've fully internalized those rules, which leads to subtly wrong or weird programs that just work most of the time. Perl is fundamentally different than most languages in how it uses context, but you can get away with not really understanding that at all by just learning a few rules-of-thumb. This, predictably, results in frustration in the writer, as they run up against what look like rough edges and weird idiosyncrasies in the language but are often just places where they've never actually learned how Perl really works. That's not to say Perl doesn't have actual rough points and problems (what language doesn't after almost 30 years?), but contrary to popular belief, Perl is actually highly designed, and usually conforms to a few core principles (even it those principles are not what many other languages emphasize).

cm3 10y ago

> The only thing that's a plus for go is it's dead-easy concurrency. Since you mention Haskell, I would like to say that Haskell's concurrency support is more diverse and at least as easy as Go's.

masklinn 10y ago
> I would like to say that Haskell's concurrency support is more diverse and at least as easy as Go's. More diverse is easy, Go is opinionated about its concurrency. "At least as easy" is a flaming lie. The diversity alone makes it impossible but beyond that: * when you look for concurrent go you're introduced to 3 constructs (`go`, channels and `select`) and you're off to the race having barely learned the language * when you look for concurrent haskell you're directed towards the corresponding paper, "tackling the awkward squad" and a world of Async, MVar, ThreadId, STM and various types of Chan, and at that point you still can't write a line of concurrent haskell Like the_duke I don't enjoy Go, but with respect to dead-easy concurrency the only language that's in the same ballpark is Erlang (and it's similarly boiled down to a complete lack of diversity — though a different model than Go's — and three basic constructs: `spawn`, `receive` and `!`).
- mitchty 10y ago
  > * when you look for concurrent haskell you're directed towards the corresponding paper, "tackling the awkward squad" and a world of Async, MVar, ThreadId, STM and various types of Chan, and at that point you still can't write a line of concurrent haskell I was directed here: http://community.haskell.org/~simonmar/pcph/ http://community.haskell.org/~simonmar/pcph/ And after reading the first few chapters, I'd place go's options under the Rich Hickey quote of simple versus easy. Additionally I sped up a simulated annealing program with the accelerate framework in Haskell by typing "Acc " twice. From 1 000 iterations/minute to about 500 000. I'd call that an easy win. Haskell also allows for more than simply concurrent programming. I always ended up with locks in go and wondering why I was using it over c with an event loop and threads at that point.
  - cm3 10y ago
    Yeah, also the STM support is often overlooked and is a good fit for some tasks where everything else is much harder.
  - jerf 10y ago
    Haskell's concurrency advantage is that the answer to the question "Does Haskell have X concurrency construct?" is "yes", and additionally, it's generally safe to use because everything is immutable. It even has support for things that have proved difficult or impossible in almost every other context because of that immutability, most notably STM. Haskell's concurrency disadvantage is the same set of answers to the same question. It intrinsically has a big toolbox to start with, and a bigger one once you get into the libraries that implement further things on top of it (the pipe libraries, for instance), and that intrinsically makes it harder. So, for instance, yes, you certainly sped up your program very easily, but new users often have a hard time finding their way to the best resources, and if their problem is not a trivially parallelizable algorithm, which it sounds like you had, there can still be some trouble in figuring out which concurrency construct they need.
    - dbaupp 10y ago
      STM is useless with full immutability: it is safe in Haskell because effects (including mutation) can be controlled/packaged into contained areas, via abstractions like monads. That said, one downside of STM is that it isn't as efficient as some other schemes especially with high contention, as everything gets serialized through the metadata for tracking transactions. It's an awesome tool, but not a panacea (like with any other technology). (I'm sure you know this, but others reading the thread may not.)

sethammons 10y ago

I've not looked at Rust, but I've been using Go in production now for years at this point with non-trivial code bases. In our cases, they are mostly SMTP and HTTP servers. Sometimes the boiler plate gets in the way (and I think Go should almost never be used for simple CRUD stuff, there are better options), but I find the readability fantastic. It really dawned on my how readable it can be when I had to fix a missed condition in clean up on shutdown. It was fixed in an hour. For the perl version that the Go one replaced, it would have been a day before I even understood what would have needed fixing.

stormcrowsx 10y ago
Really not a property of Go. Any codebase can be hard to follow if the designer wants it to be. It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code.
- kbenson 10y ago
  > It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code. That's one way to look at it. The other is that they embedded more syntax which makes the learning curve longer, but yields more more efficient writing and reading of code once you've fully internalized that syntax. The big mistake, IMO, was that they also made the language easily usable to get something done before you've fully internalized those rules, which leads to subtly wrong or weird programs that just work most of the time. Perl is fundamentally different than most languages in how it uses context, but you can get away with not really understanding that at all by just learning a few rules-of-thumb. This, predictably, results in frustration in the writer, as they run up against what look like rough edges and weird idiosyncrasies in the language but are often just places where they've never actually learned how Perl really works. That's not to say Perl doesn't have actual rough points and problems (what language doesn't after almost 30 years?), but contrary to popular belief, Perl is actually highly designed, and usually conforms to a few core principles (even it those principles are not what many other languages emphasize).