4 ms·

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming langu

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C? Go's type system is a joke. Like literally, it's a joke. If you get a bunch of people who know about types languages in a room discussing types, "What about Go?" is guaranteed to get a laugh.

jsmith0295 10y ago
Maybe if by "people who know about types languages" you mean "Haskell snobs"
- spion 10y ago
  But also ML, Scala, C++, C#, Java, TypeScript, Hack, Dart, Swift, Objective C (as of late), Visual Basic... and COBOL snobs.
  - jsmith0295 10y ago
    I was referring more to the "joke" part of this. Just because a type system offers slightly more safety doesn't make it better. I'm primarily a Java developer, and I would prefer Go's type system over Java's the vast majority of the time. It does a much better job at staying out of the way.
    - spion 10y ago
      That may be true, but the joke part comes when you actually want to develop new abstractions that are type-safe. For example you cant write a thread-safe map container in Go without sacrificing type safety (i.e. one that would not crash the program when there are concurrent writes to the map). The standard library doesn't offer one either. This means you end up copy pasting the lock related code for every map you want to make thread safe. You have to remember to declare and initialise its lock, to use that lock every time you access it, and to remember to unlock it. Now for some things, this cost isn't too bad. For others, it makes the language a joke. As a result, Go is a toy, or at least, a non-general-purpose language. If the problem you're solving fits its limited set of built-in abstractions, its great. Otherwise, its a disaster. In my experience, well written programs evolve over time to gain new carefully chosen abstractions that cleanly implement shared underlying concepts of the problem domain. These abstractions often require the use of generics. When this happens in a Go project, however, you're out of luck. Even worse, developing primarily in Go means distorting your thinking to fit its limits. This is more or less true in any language, and its not a binary thing. Languages are all over the place on the ladder of abstraction (with lisps being close to the top, Go near the bottom). p.s. Java also suffers because it added generics too late: by the time they were added there was already a clear picture painted of "idiomatic Java". To make matters worse lambdas were also added way too late, and the verbosity of type declarations is still staggeringly high. However, modern Java is a much better language than Go.
    - devishard 10y ago
      I can definitely see the tradeoffs of choosing between Java's bad namespacing conventions and lack of type inference, but keep in mind you're comparing to a 20 year old language. Other languages (i.e. C#, Nim) have learned from Java's mistakes. Go hasn't; they've just gone back to making most of C's mistakes (in type systems). I've no particular love for Java's type system, but I can't criticize it as much because it was a lot more reasonable when it was released (1996). In 2016 there's no excuse for having a type system as broken as Go's.
- devishard 10y ago
  Or literally any statically-typed language I know of after C. I suppose it's possible there's some language I'm unaware of that has managed to somehow provide less type-checking than Go, but it's certainly not a commonly-used one.
  - jsmith0295 10y ago
    It's not really a matter of less or more in my opinion. Java has more type checking, but it doesn't give you much more safety than Go, and it's a lot more cumbersome. In general I find Go's type system to be better than Java's because of this.
    - devishard 10y ago
      I think that Java can definitely provide significantly more protection than Go, but I do agree that Java's horrible namespacing conventions and lack of type inference makes it cumbersome. So what, you're on par with a 20 year old language? C# for example learned from Java's mistakes; why couldn't Go?
      - jsmith0295 10y ago
        I think I just don't come across situations where I find myself needing generics in the software that I typically write. I can imagine it would suck in those situations. There is a workaround for it, though. Basically you write a template and do code generation off of that to sort of approximate generics. I've never done it myself, though.
        devishard 10y ago
        > I think I just don't come across situations where I find myself needing generics in the software that I typically write. You don't need generics, sure. You can write working code in assembly, too. But abstractions catch more of your mistakes for you. > There is a workaround for it, though. Basically you write a template and do code generation off of that to sort of approximate generics. I've never done it myself, though. So, basically slightly more powerful macros, like in C, with most of the pitfalls and dangers associated with them. There are better approaches to these problems.
pierre_massat 10y ago
Why is the type system a joke (genuine question)?
- spion 10y ago
  Mainly because it has no generics.
  - tome 10y ago
    Nor sum types.
    - prodigal_erik 10y ago
      Interface values have a "type", despite being nil, that can make equality fail.
    - dllthomas 10y ago
      Interfaces can be used to messily construct open sum types. Not enough to save go's error handling story, though.
- premium-concern 10y ago
  It provides zero abstraction, which is especially painful when handling errors. In Go you basically _have_ to handle the error right when you receive it, there is no way of usefully combining or composing it. Also error handling itself is very verbose and can't be abstracted over. In other languages you can compose errors just as regular values, which allows you to handle the errors at the place where you have all the information to deal with it. Not only that, the types represent the structure of the computation you ran. For example, your type is Future[Option[List[Person]]] and just by looking at the return types of the things you called, you can tell exactly _where_ an issue occurred and how to handle it: Your value is a Success(None)? -> The method inside your asynchronous computation that returned Option[List] failed! Just to note, Future[Option[List[Person]]] is not some made-up example, it could be a real-world query against the database–for instance "do we know the friends of user X"? - Future – we run it async - Option – we might not know it - List – his friends This let's us very neatly tell apart things like - Failure – "the database response from the database timed out" - Success(None) – "we have no idea about user X' friends" - Success(Some(Nil)) – "X has no friends" - Success(Some(List(...))) – "here are X' friends" (And the compiler will make sure that you handle all possibilities) In Go the closest pattern would likely be to extract the string from the error value and compare it to error strings you recognize. An alternative would be to define a special single-purpose data type specially for each type including all combinators, as Go would not be able to express any commonality between Future[Option[List[Person]]] and Future[Option[List[Pet]]]. You would need to define 4 new data types and all operations anew.
e1452654a78d238 10y ago
The other great thing about Go is it has a lot fewer language snobs like this guy as the people who use it typically don't have time for that kind of crap (SysAdmins, DevOps guys, people building orchestration tools, etc etc)
_ph_ 10y ago
Sorry, your posting is unnecessarily abrasive. I am well aware about more advanced type systems. I have never claimed that Go has the most advanced type system. But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system. It could possibly have a more advanced one, but strict it is. And it gets work done.
- devishard 10y ago
  > Sorry, your posting is unnecessarily abrasive. Go is a much bigger problem in our industry than the tone of my post. > I have never claimed that Go has the most advanced type system. You claimed it had "strict type checking", when it has the least strict type system of any statically-typed language in common usage except C. > But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system. With template types, you can definitely get more strict type-checking out of C++ than out of Go. So basically, Go has a more modern type system than C. And that's arguably not true. None of which disproves what I said: I said, "people who like Go only like it because they have no idea what has happened in programming languages for the last few decades." > And it gets work done. You can make that claim about any language. The question is, does it get work done as efficiently as other languages? And the answer is pretty clearly no.

jsmith0295 10y ago

Maybe if by "people who know about types languages" you mean "Haskell snobs"

spion 10y ago
But also ML, Scala, C++, C#, Java, TypeScript, Hack, Dart, Swift, Objective C (as of late), Visual Basic... and COBOL snobs.
- jsmith0295 10y ago
  I was referring more to the "joke" part of this. Just because a type system offers slightly more safety doesn't make it better. I'm primarily a Java developer, and I would prefer Go's type system over Java's the vast majority of the time. It does a much better job at staying out of the way.
  - spion 10y ago
    That may be true, but the joke part comes when you actually want to develop new abstractions that are type-safe. For example you cant write a thread-safe map container in Go without sacrificing type safety (i.e. one that would not crash the program when there are concurrent writes to the map). The standard library doesn't offer one either. This means you end up copy pasting the lock related code for every map you want to make thread safe. You have to remember to declare and initialise its lock, to use that lock every time you access it, and to remember to unlock it. Now for some things, this cost isn't too bad. For others, it makes the language a joke. As a result, Go is a toy, or at least, a non-general-purpose language. If the problem you're solving fits its limited set of built-in abstractions, its great. Otherwise, its a disaster. In my experience, well written programs evolve over time to gain new carefully chosen abstractions that cleanly implement shared underlying concepts of the problem domain. These abstractions often require the use of generics. When this happens in a Go project, however, you're out of luck. Even worse, developing primarily in Go means distorting your thinking to fit its limits. This is more or less true in any language, and its not a binary thing. Languages are all over the place on the ladder of abstraction (with lisps being close to the top, Go near the bottom). p.s. Java also suffers because it added generics too late: by the time they were added there was already a clear picture painted of "idiomatic Java". To make matters worse lambdas were also added way too late, and the verbosity of type declarations is still staggeringly high. However, modern Java is a much better language than Go.
  - devishard 10y ago
    I can definitely see the tradeoffs of choosing between Java's bad namespacing conventions and lack of type inference, but keep in mind you're comparing to a 20 year old language. Other languages (i.e. C#, Nim) have learned from Java's mistakes. Go hasn't; they've just gone back to making most of C's mistakes (in type systems). I've no particular love for Java's type system, but I can't criticize it as much because it was a lot more reasonable when it was released (1996). In 2016 there's no excuse for having a type system as broken as Go's.
devishard 10y ago
Or literally any statically-typed language I know of after C. I suppose it's possible there's some language I'm unaware of that has managed to somehow provide less type-checking than Go, but it's certainly not a commonly-used one.
- jsmith0295 10y ago
  It's not really a matter of less or more in my opinion. Java has more type checking, but it doesn't give you much more safety than Go, and it's a lot more cumbersome. In general I find Go's type system to be better than Java's because of this.
  - devishard 10y ago
    I think that Java can definitely provide significantly more protection than Go, but I do agree that Java's horrible namespacing conventions and lack of type inference makes it cumbersome. So what, you're on par with a 20 year old language? C# for example learned from Java's mistakes; why couldn't Go?
    - jsmith0295 10y ago
      I think I just don't come across situations where I find myself needing generics in the software that I typically write. I can imagine it would suck in those situations. There is a workaround for it, though. Basically you write a template and do code generation off of that to sort of approximate generics. I've never done it myself, though.
      - devishard 10y ago
        > I think I just don't come across situations where I find myself needing generics in the software that I typically write. You don't need generics, sure. You can write working code in assembly, too. But abstractions catch more of your mistakes for you. > There is a workaround for it, though. Basically you write a template and do code generation off of that to sort of approximate generics. I've never done it myself, though. So, basically slightly more powerful macros, like in C, with most of the pitfalls and dangers associated with them. There are better approaches to these problems.

pierre_massat 10y ago

Why is the type system a joke (genuine question)?

spion 10y ago
Mainly because it has no generics.
- tome 10y ago
  Nor sum types.
  - prodigal_erik 10y ago
    Interface values have a "type", despite being nil, that can make equality fail.
  - dllthomas 10y ago
    Interfaces can be used to messily construct open sum types. Not enough to save go's error handling story, though.
premium-concern 10y ago
It provides zero abstraction, which is especially painful when handling errors. In Go you basically _have_ to handle the error right when you receive it, there is no way of usefully combining or composing it. Also error handling itself is very verbose and can't be abstracted over. In other languages you can compose errors just as regular values, which allows you to handle the errors at the place where you have all the information to deal with it. Not only that, the types represent the structure of the computation you ran. For example, your type is Future[Option[List[Person]]] and just by looking at the return types of the things you called, you can tell exactly _where_ an issue occurred and how to handle it: Your value is a Success(None)? -> The method inside your asynchronous computation that returned Option[List] failed! Just to note, Future[Option[List[Person]]] is not some made-up example, it could be a real-world query against the database–for instance "do we know the friends of user X"? - Future – we run it async - Option – we might not know it - List – his friends This let's us very neatly tell apart things like - Failure – "the database response from the database timed out" - Success(None) – "we have no idea about user X' friends" - Success(Some(Nil)) – "X has no friends" - Success(Some(List(...))) – "here are X' friends" (And the compiler will make sure that you handle all possibilities) In Go the closest pattern would likely be to extract the string from the error value and compare it to error strings you recognize. An alternative would be to define a special single-purpose data type specially for each type including all combinators, as Go would not be able to express any commonality between Future[Option[List[Person]]] and Future[Option[List[Pet]]]. You would need to define 4 new data types and all operations anew.

e1452654a78d238 10y ago

The other great thing about Go is it has a lot fewer language snobs like this guy as the people who use it typically don't have time for that kind of crap (SysAdmins, DevOps guys, people building orchestration tools, etc etc)

_ph_ 10y ago

Sorry, your posting is unnecessarily abrasive. I am well aware about more advanced type systems. I have never claimed that Go has the most advanced type system. But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system. It could possibly have a more advanced one, but strict it is. And it gets work done.

devishard 10y ago
> Sorry, your posting is unnecessarily abrasive. Go is a much bigger problem in our industry than the tone of my post. > I have never claimed that Go has the most advanced type system. You claimed it had "strict type checking", when it has the least strict type system of any statically-typed language in common usage except C. > But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system. With template types, you can definitely get more strict type-checking out of C++ than out of Go. So basically, Go has a more modern type system than C. And that's arguably not true. None of which disproves what I said: I said, "people who like Go only like it because they have no idea what has happened in programming languages for the last few decades." > And it gets work done. You can make that claim about any language. The question is, does it get work done as efficiently as other languages? And the answer is pretty clearly no.