3 ms·

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

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 ...".
      - tikhonj 13y ago
        Adding sum types to the language is not a bad thing. In fact, it's a great thing, even outside of nullability! It would also make error handling much neater--and not a special case--in Go. Sum types also have a natural symmetry with structs, and in language design (just like in physics), I figure symmetry means you're on the right track. Of course, to make both of these reasonable, you would also have to add parametric polymorphism. And while you're at it, you may as well throw in full type inference. (I mean, why not?) These aren't gigantic changes, and it's already well-understood how to implement all these efficiently--OCaml has it all, along with a fast compiler that outputs fast code. But Go doesn't. I really wish Go had taken more (i.e. some) inspiration from OCaml. Also, ignoring the merits of this particular case, I don't agree that a decision is reasonable just because it's the "different side" of a tradeoff. Virtually any choices can be recast as tradeoffs, but there are still wrong decisions to be made!

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 ...".
    - tikhonj 13y ago
      Adding sum types to the language is not a bad thing. In fact, it's a great thing, even outside of nullability! It would also make error handling much neater--and not a special case--in Go. Sum types also have a natural symmetry with structs, and in language design (just like in physics), I figure symmetry means you're on the right track. Of course, to make both of these reasonable, you would also have to add parametric polymorphism. And while you're at it, you may as well throw in full type inference. (I mean, why not?) These aren't gigantic changes, and it's already well-understood how to implement all these efficiently--OCaml has it all, along with a fast compiler that outputs fast code. But Go doesn't. I really wish Go had taken more (i.e. some) inspiration from OCaml. Also, ignoring the merits of this particular case, I don't agree that a decision is reasonable just because it's the "different side" of a tradeoff. Virtually any choices can be recast as tradeoffs, but there are still wrong decisions to be made!