6 ms·
As far as I know, Go already has a really strong static type system (int32 cannot be assigned to int for example). Which parts are weak?
by jackyb 12y ago
As far as I know, Go already has a really strong static type system (int32 cannot be assigned to int for example). Which parts are weak?
- AlisdairO 12y agoI assume they meant strong as in 'good' - presumably they're talking about generics.
- cgag 12y agoNo generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak. Edit: I don't think there's anything like type classes either but I'm not 100%.
- peterhunt 12y agoYeah, I mainly want to get a feel for building a real system using a strict type system and algebraic data types. I've done some toys with them but nothing real yet.
- Kiro 12y agoWould you consider JavaScript's type system strong?
- deleted 12y ago[deleted]
- otikik 12y ago> Go's type system is weak. It is strong enough for me. I see the lack of algebraic data types and type classes as a feature, honestly. It means I can learn the things I need and start working in 2 days instead of in 2 weeks or a month. I sometimes need generics, but not frequently enough to miss them. You think Go's type system is weak. I think Haskell's type system is overcomplicated. So, there.
- cgag 12y agoEven if it were true that it were overly complicated, that wouldn't change the fact that it's much more powerful than Go's. “When I work at this system up to 12hrs a day, I’m profoundly uninterested in what user interface a novice user would prefer.” —Erik Naggum Are you using visual basic because you could pick it up in 2 days instead of taking a month to learn Go? It's easy to learn because it doesn't do anything interesting that you're not already familiar with. If you're not missing them, you're missing out on simple beautiful abstractions like map and filter. You're also missing out on type safe libraries for containers. It's not possible to write a generic container without casts to interface{}, which is a shame imo.
- otikik 12y ago> visual basic Bringing The Language Which Shall not Be Named to the discussion is a low blow. But I deserve it. My phrase about overcomplication was flamebaity and uncalled for, and I apologize. > you're missing out on simple beautiful abstractions like map and filter The thing is, in Go, those take almost as much space as a plain for loop. I know, you will tell me "that's because Go's too verbose". I will grant that it's more verbose than Haskell. But I am not doing maps and filters all the time in my code. > It's not possible to write a generic container without casts to interface{}, which is a shame imo. My point is that generic containers are the feature where generics are genuinely needed. And in those cases interface{} makes it possible. Not super-awesome, but possible. I actually like that the language doesn't bend over to fulfill something that looks almost like an edge case. It is not "programming with mathematics". It's still "moving bits around". But the bits can be moved with ease.
- jacques_chester 12y agointerface{} doesn't give you generics. The point of generics is to give you two distinct things: 1. You can write code that performs identical logic for a range of different data types, without having to know what they are. 2. That code can be checked for type safety. interface{} gives you half of 1. You can write code that performs common logic and takes an interface{}, but then that code has to manually switch on type, or convert type before running. Which gives you trouble with 2. Once you don't have a distinct type, you can't check for safety. All the compiler can do is check that an interface{} is passed in; which is a pretty weak guarantee. Meanwhile, in languages with generics, the you can write a generic method that uses the + operator and the compiler can check whether it works for numbers (OK), strings (OK), HTTP servers (uh oh, stop the bus!)...
- NateDad 12y agoI don't understand why all the ML-lovers have to bash Go for not being OCaml or Haskell or Rust. It's like bashing Python for not having static typing. Go is not one of those ML languages with a complicated type system. It has a simple type system. This is a feature for Go, just as dynamic typing is a feature for python. Neither is right or wrong or backwards. They're different design choices. If you don't like it, that's fine, don't use it. But it's not an inherently bad choice.