5 ms·

Those of us who think that Go is a truly sad language to release at modern times (nullability everywhere, no parameteric polymorphism, no sums, products for err

by Peaker 13y ago

Those of us who think that Go is a truly sad language to release at modern times (nullability everywhere, no parameteric polymorphism, no sums, products for errors instead of sums, ...) have just lost interest in explaining over and over again why a new language without those features belongs in the 1970's or 1980's, and not modern times. The crowd that remains is mostly composed of people who have never used an ML-style language (Haskell, OCaml, F#, SML, ..) and come from a background of C, Java and Python. Go is definitely an improvement over these languages in many areas.

deleted 13y ago
[deleted]
MetaCosm 13y ago
As a pragmatist and someone who enjoys Haskell and F#, I find your comments very academic. There will always be less popular, feature packed fun languages like Rust, Haskell and OCaml, and there will always be teams that use them to great advantage (Jane Street). But IMHO, lots of these systems are a little creaky in the support structures (cabal for example) and deploy features. That said, I think a lot of what makes Go great is because of its simplicity, lack of surprises, and general lack of cleverness. You can get your hands around the language features very easily, in mere hours. Beyond that, I think the ease of building tooling on top of the AST (or in general), the ease of deploying code to production, the build speeds, the inclusion of go get and fmt, the policies around imports and variable use (use or lose) all add up to be more than the sum of its parts. It is very obviously built by a team looking to use it in production, on real projects, as soon as possible.
- Peaker 13y ago
  > But IMHO, lots of these systems are a little creaky in the support structures (cabal for example) and deploy features Cabal used to be horrendous. Now it's just mediocre, and better than the distribution tools I've seen in the Python world (e.g: easy_install). Much better than the lack of distribution tools in the C and C++ world. > That said, I think a lot of what makes Go great is because of its simplicity, lack of surprises, and general lack of cleverness. You can get your hands around the language features very easily, in mere hours nil everywhere is an easy to explain language feature. It might be easier to explain than pattern matching. It's definitely worse though. I'm not saying that Go has no strong points in its favor. It has plenty surrounding it that you mention. It's just sad that this is all around such a poor language.
  - MetaCosm 13y ago
    The horror of python dependencies, build and deploy (I currently am working on a 250k+ LOC python project) is part of what made me really love what is around the edges of Go. There is a lot of "worse" in Go. It seems the "worse" choices were for 3 reasons: (1) make the language simpler, and (2) make the compiler / tooling simpler to build or (3) ship a production usable product in X time. I think all might yield benefits in the long term. Getting angry about a "poor language" is pointless, there are hundreds. It seems people get more angry that it might get popular more than their favorite language. For a bit, I was a bit of a stick in the mud about Go because I was hoping Erlang (maybe with Elixir) would take off. After that I was worried it might get popular before Rust had a chance to get off the ground. But, after having spent some time with it -- I have grown to like its odd, pragmatic mix of tooling and features.
    - Peaker 13y ago
      I didn't say I was angry. I said a new language that repeats past mistakes again is sad. The authors of Eiffel went ahead and paid a very dear price to fix their nullability-everywhere. The C# author says if he could go back in time and fix one design mistake in the language, it would be the nullability-everywhere mistake. That it is responsible for a huge percentage of field issues with C#. Yet Go was designed after these, and still put in nullability everywhere. Seeing society pour tonnes of resources into a bad language, when we could all have benefited from these resources being poured into a good one is sad. Having a new language with new approaches and ideas is great. But one that we already know will create poorer quality software, not so great. What a huge waste of talent and resources we're seeing here. P.S: Cabal is not really so bad anymore. My experience when using "cabal install <pkgname>" is generally 90% success, and 9% failures that I can fix by a simple "cabal unpack" on some overly restrictive package to fix its version constraints and carry on.
      - burntsushi 13y ago
        Fixing the "null" issue isn't straight-forward. If you eliminate it completely, then you need to add sum types to the language. If you provide nullable pointers in addition to non-nullable pointers, then you're adding complexity to the language by having two different kinds of pointers. It's a trade off. The Go designers chose a different side of that trade off than you would have. That's perfectly reasonable. I don't think you appreciate arguments for pragmatism. I write plenty of C and Go code. I rarely run into null pointer errors in Go, while I run into plenty of them in C. It's possible to mitigate the Billion Dollar Mistake without encoding it into the type system. This null issue has come up plenty of times on the Go mailing list. Search for the billion dollar mistake, and you should find some responses from the Go devs. > But one that we already know will create poorer quality software We do? I think you meant, "I believe it will create ...".
taliesinb 13y ago
1. Parametric polymorphism may still come. I think we need to understand their connection with interfaces and builtins before it will be clear what to do. A thousand frameworks may need to bloom before we have enough data to do that. 2. Nullability IS a kind of sum... and the idea of a zero value would be impossible (or at least ruinously inefficient) without nullability. Secondly, the fact that all dereferences are checked gives you most of the same benefits, just minus all the type noise. 3. Products for errors are actually a GOOD thing, in that they allow developers to easily choose between pedantic error handling or relying on downstream panicing to handle situations that are unrecoverable anyway. Whereas with type-level enforcement, you HAVE to do all that extra checking, and that straitjacket costs you clarity and elegance. 4. Interfaces do allow for sum types, and type switch statements and/or dispatch allow for pattern matching. Not terribly elegant, but effective and understandable. My closing thought: type systems are crutches for reasoning about the behavior of programs at compile time... and we need all the help we can get with that challenge, so yay for type systems! At some point, however, they become cages, because there will always be a frontier beyond which they will be unable to encode contraints that are obvious to the person writing the program, and at that point, the resulting contortions will obscure, not enlighten.
- Peaker 13y ago
  2. Nullability is an implicit sum you have everywhere. One that is not checked for exhaustiveness by the compiler. What do you mean "a zero value would be impossible"? The whole idea is that sometimes you need it, and sometimes you don't, so you want your language to let you distinguish these 2 cases and then check for your program's exhaustiveness in checking it when you do have a zero value. The fact dereferences are checked converts one runtime error into another. Proper sum types convert a runtime error into a compile-time error. How do you possibly view this as "most of the same benefits"? 3. No, they allow you to use the wrong value when there actually was an error and the value has a different meaning than intended (or just another nil dereference). The type system forces you to have either error checking or you can use explicit type system escape hatches which are then greppable. For example, Haskell does have unsafe functions like "fromJust" which unsafely assume a result value is not an error -- but these functions are rightly considered a code smell. If you want to use them, you can, at least making the smelly parts of the code easily findable. In Go, all the code is smelly, instead. 4. Type switch statements are so clunky I don't think they can, with a straight face, be considered "effective" alternatives for pattern matching. Consider: myFunction Nothing = ... myFunction (Just x) = ... This is understandable. This is effective. Do you think the equivalent type switch in Go is? Type systems don't become cages and aren't "crutches". They are tools that you can use as much as you want. A program in Haskell can be written to be type-unsafe and put all the code in useless types. Or it can encode any amount from very little to a lot in the type system. It's just a tool you get to choose how much of your invariants you want to verify. Go doesn't offer you that tool.

by Peaker 13y ago

deleted 13y ago

[deleted]

MetaCosm 13y ago

As a pragmatist and someone who enjoys Haskell and F#, I find your comments very academic. There will always be less popular, feature packed fun languages like Rust, Haskell and OCaml, and there will always be teams that use them to great advantage (Jane Street). But IMHO, lots of these systems are a little creaky in the support structures (cabal for example) and deploy features. That said, I think a lot of what makes Go great is because of its simplicity, lack of surprises, and general lack of cleverness. You can get your hands around the language features very easily, in mere hours. Beyond that, I think the ease of building tooling on top of the AST (or in general), the ease of deploying code to production, the build speeds, the inclusion of go get and fmt, the policies around imports and variable use (use or lose) all add up to be more than the sum of its parts. It is very obviously built by a team looking to use it in production, on real projects, as soon as possible.

Peaker 13y ago
> But IMHO, lots of these systems are a little creaky in the support structures (cabal for example) and deploy features Cabal used to be horrendous. Now it's just mediocre, and better than the distribution tools I've seen in the Python world (e.g: easy_install). Much better than the lack of distribution tools in the C and C++ world. > That said, I think a lot of what makes Go great is because of its simplicity, lack of surprises, and general lack of cleverness. You can get your hands around the language features very easily, in mere hours nil everywhere is an easy to explain language feature. It might be easier to explain than pattern matching. It's definitely worse though. I'm not saying that Go has no strong points in its favor. It has plenty surrounding it that you mention. It's just sad that this is all around such a poor language.
- MetaCosm 13y ago
  The horror of python dependencies, build and deploy (I currently am working on a 250k+ LOC python project) is part of what made me really love what is around the edges of Go. There is a lot of "worse" in Go. It seems the "worse" choices were for 3 reasons: (1) make the language simpler, and (2) make the compiler / tooling simpler to build or (3) ship a production usable product in X time. I think all might yield benefits in the long term. Getting angry about a "poor language" is pointless, there are hundreds. It seems people get more angry that it might get popular more than their favorite language. For a bit, I was a bit of a stick in the mud about Go because I was hoping Erlang (maybe with Elixir) would take off. After that I was worried it might get popular before Rust had a chance to get off the ground. But, after having spent some time with it -- I have grown to like its odd, pragmatic mix of tooling and features.
  - Peaker 13y ago
    I didn't say I was angry. I said a new language that repeats past mistakes again is sad. The authors of Eiffel went ahead and paid a very dear price to fix their nullability-everywhere. The C# author says if he could go back in time and fix one design mistake in the language, it would be the nullability-everywhere mistake. That it is responsible for a huge percentage of field issues with C#. Yet Go was designed after these, and still put in nullability everywhere. Seeing society pour tonnes of resources into a bad language, when we could all have benefited from these resources being poured into a good one is sad. Having a new language with new approaches and ideas is great. But one that we already know will create poorer quality software, not so great. What a huge waste of talent and resources we're seeing here. P.S: Cabal is not really so bad anymore. My experience when using "cabal install <pkgname>" is generally 90% success, and 9% failures that I can fix by a simple "cabal unpack" on some overly restrictive package to fix its version constraints and carry on.
    - burntsushi 13y ago
      Fixing the "null" issue isn't straight-forward. If you eliminate it completely, then you need to add sum types to the language. If you provide nullable pointers in addition to non-nullable pointers, then you're adding complexity to the language by having two different kinds of pointers. It's a trade off. The Go designers chose a different side of that trade off than you would have. That's perfectly reasonable. I don't think you appreciate arguments for pragmatism. I write plenty of C and Go code. I rarely run into null pointer errors in Go, while I run into plenty of them in C. It's possible to mitigate the Billion Dollar Mistake without encoding it into the type system. This null issue has come up plenty of times on the Go mailing list. Search for the billion dollar mistake, and you should find some responses from the Go devs. > But one that we already know will create poorer quality software We do? I think you meant, "I believe it will create ...".

taliesinb 13y ago

1. Parametric polymorphism may still come. I think we need to understand their connection with interfaces and builtins before it will be clear what to do. A thousand frameworks may need to bloom before we have enough data to do that. 2. Nullability IS a kind of sum... and the idea of a zero value would be impossible (or at least ruinously inefficient) without nullability. Secondly, the fact that all dereferences are checked gives you most of the same benefits, just minus all the type noise. 3. Products for errors are actually a GOOD thing, in that they allow developers to easily choose between pedantic error handling or relying on downstream panicing to handle situations that are unrecoverable anyway. Whereas with type-level enforcement, you HAVE to do all that extra checking, and that straitjacket costs you clarity and elegance. 4. Interfaces do allow for sum types, and type switch statements and/or dispatch allow for pattern matching. Not terribly elegant, but effective and understandable. My closing thought: type systems are crutches for reasoning about the behavior of programs at compile time... and we need all the help we can get with that challenge, so yay for type systems! At some point, however, they become cages, because there will always be a frontier beyond which they will be unable to encode contraints that are obvious to the person writing the program, and at that point, the resulting contortions will obscure, not enlighten.

Peaker 13y ago
2. Nullability is an implicit sum you have everywhere. One that is not checked for exhaustiveness by the compiler. What do you mean "a zero value would be impossible"? The whole idea is that sometimes you need it, and sometimes you don't, so you want your language to let you distinguish these 2 cases and then check for your program's exhaustiveness in checking it when you do have a zero value. The fact dereferences are checked converts one runtime error into another. Proper sum types convert a runtime error into a compile-time error. How do you possibly view this as "most of the same benefits"? 3. No, they allow you to use the wrong value when there actually was an error and the value has a different meaning than intended (or just another nil dereference). The type system forces you to have either error checking or you can use explicit type system escape hatches which are then greppable. For example, Haskell does have unsafe functions like "fromJust" which unsafely assume a result value is not an error -- but these functions are rightly considered a code smell. If you want to use them, you can, at least making the smelly parts of the code easily findable. In Go, all the code is smelly, instead. 4. Type switch statements are so clunky I don't think they can, with a straight face, be considered "effective" alternatives for pattern matching. Consider: myFunction Nothing = ... myFunction (Just x) = ... This is understandable. This is effective. Do you think the equivalent type switch in Go is? Type systems don't become cages and aren't "crutches". They are tools that you can use as much as you want. A program in Haskell can be written to be type-unsafe and put all the code in useless types. Or it can encode any amount from very little to a lot in the type system. It's just a tool you get to choose how much of your invariants you want to verify. Go doesn't offer you that tool.