7 ms·

I like seeing people embrace static typing, but it makes me sad that it's a language where you can't even write a container (a map/dictionry/linked-list/etc) wi

by cgag 13y ago

I like seeing people embrace static typing, but it makes me sad that it's a language where you can't even write a container (a map/dictionry/linked-list/etc) without giving up type safety. I recognize that Golang is filling a gap, letting people get static typing without having to learn much new stuff, and there's value in that, but I think Go enthusiasts should read these great posts by Tikhon Jelvis with an open mind: https://www.quora.com/Googles-programming-language-Go-seems-to-be-the-most-modern-and-well-featured-language-in-existence-today-Is-that-the-case-or-are-there-major-drawbacks-that-Im-not-seeing https://www.quora.com/Googles-programming-language-Go-seems-... https://www.quora.com/Go-programming-language/Do-you-feel-that-golang-is-ugly https://www.quora.com/Go-programming-language/Do-you-feel-th...

burntsushi 13y ago
Quite frankly, those articles are absolutely terrible. Firstly, it's clear that the author assumes there exists some correct way to design a language. (I reject that.) Secondly, the author never acknowledges any of the trade offs that come from adding additional features to a language. (Hint: one of those trade offs is... there are more features!) This isn't a revolutionary thought. More compile time safety generally means more complexity in the type system. We, as programmers, must decide when, where and how much we're willing to pay for that type safety. You can go balls-to-the-wall with Idris or Agda or ATS and encode a whole mess of things directly into your types. Maybe you can completely remove out-of-bounds errors! Surely, this is better than the alternative, which admits less safety. This isn't a fair comparison because all three of those languages are ridiculously hard to use for practical things. (Well, it's hard for me, anyway.) Then there are other, more practical languages like Rust, Java, Haskell, OCaml, etc., that all provide a helluva lot more compile time type safety than Go does. (Or, to be precise, a lot more expressive power with respect to compile time safe polymorphism.) Some of the languages go even further; Rust eliminates data races and Haskell isolates "side effects" with monads. All of these things are wonderful, because we get a lot more guarantees about ways in which our program cannot fail once it's compiled. But they aren't free. They come with a cost. Typically the cost is in greater language complexity. The programmer must write code that the compiler accepts. If you're in that language's wheelhouse, maybe the complexity isn't so bad. But when you want to write a program that isn't easily accepted by the compiler, you run into complexity. Maybe it's not that bad---maybe you just need to figure out how to write a monad transformer. Or maybe you just need to think a bit more carefully about the lifetime of a borrowed pointer. But other times, you need type families and multi-parameter type classes before you can make an unboxed vector with your own type: http://hackage.haskell.org/package/vector-0.10.9.1/docs/Data-Vector-Unboxed.html http://hackage.haskell.org/package/vector-0.10.9.1/docs/Data... --- The safety is great, but dammit, you're going to pay for it. On some days and for some projects, I'm more than happy to pay the price for safety. It is immensely satisfying to write a program and be able to make all sorts of claims about its safety. (I just wrote a regexp implementation in Rust. Guaranteed no memory errors. No GC. Totally type safe. It's awesome.) But other times, I don't feel like paying the cost. And that's OK. It's not sad. It's not "ugly." It's a legitimate and reasonable choice given a trade off. Saying a language is "badly designed" just because it didn't include your preferred set of features is bad juju IMO.
- fauigerzigerk 13y ago
  I agree with much of what you said, but an expressive type system isn't just a safety mechanism. It's also a tool to write fast code productively. Without compile time metaprogramming some things will always be either extremely resource hungry or extremely repetitive. It's absolutely true that there is always a trade-off. Metaprogramming makes code more difficult to understand and hence more prone to certain types of errors. That's true for runtime metaprogramming as well though. So if the lack of generics leads to an overuse of reflection (or worse to custom code generators) then the complexity you avoided in the language is re-introduced through the backdoor. At the end of the day I think it's about the culture that gets established around a language. Go's creators are trying really hard to socially engineer a culture of simplicity, and that's laudable. But it reminds me of the early days of Java even though the Go community would rather have me think of C. The big difference: C had compile time metaprogramming from the beginning, Java did not. Look which one turned out to be the simpler ecosystem in the end.
zurn 13y ago
> you can't even write a container (a map/dictionry/linked-list/etc) without giving up type safety Nit: they're typesafe (when done using interfaces), just not statically so.

by cgag 13y ago

burntsushi 13y ago

Quite frankly, those articles are absolutely terrible. Firstly, it's clear that the author assumes there exists some correct way to design a language. (I reject that.) Secondly, the author never acknowledges any of the trade offs that come from adding additional features to a language. (Hint: one of those trade offs is... there are more features!) This isn't a revolutionary thought. More compile time safety generally means more complexity in the type system. We, as programmers, must decide when, where and how much we're willing to pay for that type safety. You can go balls-to-the-wall with Idris or Agda or ATS and encode a whole mess of things directly into your types. Maybe you can completely remove out-of-bounds errors! Surely, this is better than the alternative, which admits less safety. This isn't a fair comparison because all three of those languages are ridiculously hard to use for practical things. (Well, it's hard for me, anyway.) Then there are other, more practical languages like Rust, Java, Haskell, OCaml, etc., that all provide a helluva lot more compile time type safety than Go does. (Or, to be precise, a lot more expressive power with respect to compile time safe polymorphism.) Some of the languages go even further; Rust eliminates data races and Haskell isolates "side effects" with monads. All of these things are wonderful, because we get a lot more guarantees about ways in which our program cannot fail once it's compiled. But they aren't free. They come with a cost. Typically the cost is in greater language complexity. The programmer must write code that the compiler accepts. If you're in that language's wheelhouse, maybe the complexity isn't so bad. But when you want to write a program that isn't easily accepted by the compiler, you run into complexity. Maybe it's not that bad---maybe you just need to figure out how to write a monad transformer. Or maybe you just need to think a bit more carefully about the lifetime of a borrowed pointer. But other times, you need type families and multi-parameter type classes before you can make an unboxed vector with your own type: http://hackage.haskell.org/package/vector-0.10.9.1/docs/Data-Vector-Unboxed.html http://hackage.haskell.org/package/vector-0.10.9.1/docs/Data... --- The safety is great, but dammit, you're going to pay for it. On some days and for some projects, I'm more than happy to pay the price for safety. It is immensely satisfying to write a program and be able to make all sorts of claims about its safety. (I just wrote a regexp implementation in Rust. Guaranteed no memory errors. No GC. Totally type safe. It's awesome.) But other times, I don't feel like paying the cost. And that's OK. It's not sad. It's not "ugly." It's a legitimate and reasonable choice given a trade off. Saying a language is "badly designed" just because it didn't include your preferred set of features is bad juju IMO.

fauigerzigerk 13y ago
I agree with much of what you said, but an expressive type system isn't just a safety mechanism. It's also a tool to write fast code productively. Without compile time metaprogramming some things will always be either extremely resource hungry or extremely repetitive. It's absolutely true that there is always a trade-off. Metaprogramming makes code more difficult to understand and hence more prone to certain types of errors. That's true for runtime metaprogramming as well though. So if the lack of generics leads to an overuse of reflection (or worse to custom code generators) then the complexity you avoided in the language is re-introduced through the backdoor. At the end of the day I think it's about the culture that gets established around a language. Go's creators are trying really hard to socially engineer a culture of simplicity, and that's laudable. But it reminds me of the early days of Java even though the Go community would rather have me think of C. The big difference: C had compile time metaprogramming from the beginning, Java did not. Look which one turned out to be the simpler ecosystem in the end.

zurn 13y ago

> you can't even write a container (a map/dictionry/linked-list/etc) without giving up type safety Nit: they're typesafe (when done using interfaces), just not statically so.