4 ms·

It's not at all surprising that those startups solved their problems with Go: if you switch from a language that doesn't address your problems to one that does,

It's not at all surprising that those startups solved their problems with Go: if you switch from a language that doesn't address your problems to one that does, you're going to see a big benefit. But there are lots of languages that address the problems mentioned by those startups, and I think that Go is possibly the worst of the options. It's telling that none of the startups in question switched out of a language which provides good compile-time type and thread-safety guarantees: 1. iron.io: ruby -> go 2. SendGrid: perl -> python -> go 3. TJ Holowaychuck: node.js -> go Go would have a reasonable compile-time type system, except that without generics you end up having to cast a lot, which renders your compile-time type system almost irrelevant. It's also telling that none of the authors mentioned experience with functional programming. Go supports some functional programming, but it doesn't seem to be a very big part of the language. The only one who mentions that they even considered any functional languages is the iron.io guy, and it seems like a big part of his choice was not technical: he mentions that he had to sell the idea of Go to his team by mentioning that Google supports it. A language that was a more serious paradigm shift (OO -> functional) would have been an even harder sell. (EDIT: Okay, the SendGrid guy did mention considering Scala.) The fact is, there are a bunch of languages that would have solved their problems, in addition to a few they didn't know they had. Julia has coroutines similar to Go, but is much more expressive, Rust has a more traditional threading model but a type system and focus on immutability that provides better safety guarantees. There are other choices, but those two stand out as the major ones that could have solved their problems better than go.

rogpeppe1 12y ago
> Go would have a reasonable compile-time type system, except that without > generics you end up having to cast a lot, which renders your compile-time > type system almost irrelevant. In my experience of Go, this is not actually true. For example, in the latest project I've been working on, there are 8487 lines of non-test code. In that code, there are a total of 16 dynamic casts, more than half of which are checked (mostly checking for particular error types). There are a total of 4 occurrences which might possibly be amenable to generics. The type system is totally relevant, and checks 99.9% of our code.
- copsarebastards 12y ago
  How do you deal with container-type classes? The only way I can see to do this without casts is to duplicate the same container class for each contained type, which is fraught with its own problems.

rogpeppe1 12y ago

> Go would have a reasonable compile-time type system, except that without > generics you end up having to cast a lot, which renders your compile-time > type system almost irrelevant. In my experience of Go, this is not actually true. For example, in the latest project I've been working on, there are 8487 lines of non-test code. In that code, there are a total of 16 dynamic casts, more than half of which are checked (mostly checking for particular error types). There are a total of 4 occurrences which might possibly be amenable to generics. The type system is totally relevant, and checks 99.9% of our code.

copsarebastards 12y ago
How do you deal with container-type classes? The only way I can see to do this without casts is to duplicate the same container class for each contained type, which is fraught with its own problems.