6 ms·

IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high perform

IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large codebase can require a huge footprint of lines modified, just because so much code winds up duplicated in slightly different contexts. That being said, I really hope that Go's core team understands the drivers of its popularity and doesn't compromise the operational side for the sake of language improvements. Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times. I don't know if there's any theoretical reason for it to hold, but more typing complexity inevitably leads to slow compile times. And as for the topic of clear error messages, the higher-typed languages are all atrocious at this. Even templates in C++ are notorious for puking near impossible to decipher errors. This is something I'm sure can be fixed with enough engineering effort, but it would probably take a lot of effort to get there. In general, I bitch about the Go language all the time. But I think we should recognize that the simplicity of the language gives us developers a lot of peripheral really nice usability benefits.

SloopJon 6y ago
> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.
- bcrosby95 6y ago
  This is why I've always hated C++. Taking something like templates, and abusing the turing-completeness of it. If I wanted macros I would use a language that actually supports them so I wouldn't have to resort to byzantine hacks. Stuff like this is why lots of people would rather use C over C++.
  - AnimalMuppet 6y ago
    Doesn't C++ exactly support C macros? In what way is using C macros "better" than using the exact same macros in C++?
  - teleforce 6y ago
    D language is probably the Goldilocks of programming languages for the rest of us in terms of compilation speed (comparable to Go), program execution (comparable to C/C++) and ease of programming and debugging (comparable to Python). The author of the D language despises macro more than you, and has designed a solution for modern and sane approaches to template programming [1][2]. If you want to program like C in D modern eco system there is a safer betterC. Heck now there is even borrow checking capability if you want safety guarantees similar to Rust. [1]https://mobile.twitter.com/WalterBright/status/1343128003178541056 https://mobile.twitter.com/WalterBright/status/1343128003178... [2]https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/ https://dlang.org/blog/2018/03/29/std-variant-is-everything-...
- zwieback 6y ago
  I love-hate C++ templates because deep down they are just macros and you don't have to obsess about constraints like in Java and C#. To me it's pretty interesting how the three big static OO languages have implemented generics: super flexible permissive macros in C++ (with murderous error messages), type erasure in Java (gross) and actual generics in the runtime (C#). For everyday usage it doesn't matter much but I always like thinking about what's going on under the hood.
  - kaba0 6y ago
    This is my usual nitpick, but pretty much every language does type erasure and there is nothing bad with it, blahblah. Haskell is arguably great with types, and it does type erasure as well.
Zababa 6y ago
> Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times. OCaml has always been known for having really fast compile times, and could be described as a "higher-typed language" I think. > And as for the topic of clear error messages, the higher-typed languages are all atrocious at this. Elm and Rust have made good progress here and have some of the most readable and useful errors out here, especially for beginners.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
rurban 6y ago
> high performance I would not call 2x slower than C high performance. Decent performance, yes. But certainly not high. It has easy to use concurrency, so it waits less than typical C code. This might lead to some high perf claims. But it is not
- carlhjerpe 6y ago
  If you put Python and Ruby in the same graph Go and C will look more the same. Though let's be honest, how much does language speed really matter for most things? It's crap code that kills performance more than anything from my limited experience, and with a higher level language you might have easier access to libraries implementing efficient algorithms for. When good performance is needed we don't even "write code" anymore, we use ASICs. BTC mining, network switching/routing and encryption comes to mind.
patrickmcnamara 6y ago
4) It's standard library is also big, modern and well documented.
novok 6y ago
I think specific features make compile time very long. Nullable types + ADTs / sum types / 'enums' are not one of them, because they don't add exponentials to the compile time like type inference & operator overloading does for example. Also adding nullables after the fact isn't very hard, other languages such as dart & objective-c have done it. The migration path isn't that hard either, since it is a completely new syntax that doesn't have to be a breaking change, so migrations can be gradual. Out of all the features that the new higher typed languages give, I think nullables are probably the best one out of them, and one of the cheapest for all the others to adopt. And while your adding nullables, you might as well add sum types because that is how you implement it anyway.
eyelidlessness 6y ago
> Scala, Haskell, even Typescript have painful compile times. Can’t speak to the first two, but in some places TS has pathological compile times when you’re trying to give more information to the compiler. A recent example is trying to appease type inference on a set of generics where a wrapped function couldn’t narrow types from its wrapper even though they were totally valid but mostly inferred. I wrote a type guard which passed the same values with explicitly narrowed types and... it just never completes. Pegs all my CPU cores in VSCode. Used throughout my project and effectively kills type checking. I know enough about the underlying function I’m calling that I just cast to any, but now I have a mine waiting to be triggered. To be fair, this is in frontend land where it’s not TS’s fault that the types they support are so bonkers to begin with. But holy hell it’s not always obvious what’s gonna cause compile times to skyrocket.
- scns 6y ago
  You can try ReasonML/Bucklescript/ReScript. WARNING it may spoil you, by compiling in fractions of a second and make waiting for tsc miserable. Only do it if you have a high frustration tolerance.
gwd 6y ago
> That being said, I really hope that Go's core team understands the drivers of its popularity and doesn't compromise the operational side for the sake of language improvements. Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Indeed, this is part of the reason the generics have been so long in coming to Go; you can find discussions about how to implement them as far back as 2009. One of the reasons they aren't using `<T>` to indicate them is specifically because it drastically changes the speed of parsing (since you would need to figure out whether that `<` is a "less than" operator or a syntax for generics). I can't find the reference right now, but there was a quote in one of the early discussions that was something like: The Generic Paradox is this: You can have slow programmers (no generics; programmers have to do their own code duplication), slow executables (where you do loads of unboxing), or slow compile times. EDIT: Found the reference; the exact quote is: "The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" [1] The Golang generics proposal was specifically designed to try to reduce the "slow programmers" effect while avoiding either of the other two effects as much as possible. [1] https://research.swtch.com/generic https://research.swtch.com/generic

SloopJon 6y ago

> Even templates in C++ are notorious for puking near impossible to decipher errors. "Even"? I actually miss the macro-like power of templates when I'm using generics in Java and C#, but generating the longest possible error message using templates is practically an Olympic sport. I presume that SFINAE is partially to blame, because a lot of the output enumerates all the candidates that didn't match.

bcrosby95 6y ago
This is why I've always hated C++. Taking something like templates, and abusing the turing-completeness of it. If I wanted macros I would use a language that actually supports them so I wouldn't have to resort to byzantine hacks. Stuff like this is why lots of people would rather use C over C++.
- AnimalMuppet 6y ago
  Doesn't C++ exactly support C macros? In what way is using C macros "better" than using the exact same macros in C++?
- teleforce 6y ago
  D language is probably the Goldilocks of programming languages for the rest of us in terms of compilation speed (comparable to Go), program execution (comparable to C/C++) and ease of programming and debugging (comparable to Python). The author of the D language despises macro more than you, and has designed a solution for modern and sane approaches to template programming [1][2]. If you want to program like C in D modern eco system there is a safer betterC. Heck now there is even borrow checking capability if you want safety guarantees similar to Rust. [1]https://mobile.twitter.com/WalterBright/status/1343128003178541056 https://mobile.twitter.com/WalterBright/status/1343128003178... [2]https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/ https://dlang.org/blog/2018/03/29/std-variant-is-everything-...
zwieback 6y ago
I love-hate C++ templates because deep down they are just macros and you don't have to obsess about constraints like in Java and C#. To me it's pretty interesting how the three big static OO languages have implemented generics: super flexible permissive macros in C++ (with murderous error messages), type erasure in Java (gross) and actual generics in the runtime (C#). For everyday usage it doesn't matter much but I always like thinking about what's going on under the hood.
- kaba0 6y ago
  This is my usual nitpick, but pretty much every language does type erasure and there is nothing bad with it, blahblah. Haskell is arguably great with types, and it does type erasure as well.

Zababa 6y ago

> Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times. OCaml has always been known for having really fast compile times, and could be described as a "higher-typed language" I think. > And as for the topic of clear error messages, the higher-typed languages are all atrocious at this. Elm and Rust have made good progress here and have some of the most readable and useful errors out here, especially for beginners.

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]

rurban 6y ago

> high performance I would not call 2x slower than C high performance. Decent performance, yes. But certainly not high. It has easy to use concurrency, so it waits less than typical C code. This might lead to some high perf claims. But it is not

carlhjerpe 6y ago
If you put Python and Ruby in the same graph Go and C will look more the same. Though let's be honest, how much does language speed really matter for most things? It's crap code that kills performance more than anything from my limited experience, and with a higher level language you might have easier access to libraries implementing efficient algorithms for. When good performance is needed we don't even "write code" anymore, we use ASICs. BTC mining, network switching/routing and encryption comes to mind.

patrickmcnamara 6y ago

4) It's standard library is also big, modern and well documented.

novok 6y ago

I think specific features make compile time very long. Nullable types + ADTs / sum types / 'enums' are not one of them, because they don't add exponentials to the compile time like type inference & operator overloading does for example. Also adding nullables after the fact isn't very hard, other languages such as dart & objective-c have done it. The migration path isn't that hard either, since it is a completely new syntax that doesn't have to be a breaking change, so migrations can be gradual. Out of all the features that the new higher typed languages give, I think nullables are probably the best one out of them, and one of the cheapest for all the others to adopt. And while your adding nullables, you might as well add sum types because that is how you implement it anyway.

eyelidlessness 6y ago

> Scala, Haskell, even Typescript have painful compile times. Can’t speak to the first two, but in some places TS has pathological compile times when you’re trying to give more information to the compiler. A recent example is trying to appease type inference on a set of generics where a wrapped function couldn’t narrow types from its wrapper even though they were totally valid but mostly inferred. I wrote a type guard which passed the same values with explicitly narrowed types and... it just never completes. Pegs all my CPU cores in VSCode. Used throughout my project and effectively kills type checking. I know enough about the underlying function I’m calling that I just cast to any, but now I have a mine waiting to be triggered. To be fair, this is in frontend land where it’s not TS’s fault that the types they support are so bonkers to begin with. But holy hell it’s not always obvious what’s gonna cause compile times to skyrocket.

scns 6y ago
You can try ReasonML/Bucklescript/ReScript. WARNING it may spoil you, by compiling in fractions of a second and make waiting for tsc miserable. Only do it if you have a high frustration tolerance.

gwd 6y ago

> That being said, I really hope that Go's core team understands the drivers of its popularity and doesn't compromise the operational side for the sake of language improvements. Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Indeed, this is part of the reason the generics have been so long in coming to Go; you can find discussions about how to implement them as far back as 2009. One of the reasons they aren't using `<T>` to indicate them is specifically because it drastically changes the speed of parsing (since you would need to figure out whether that `<` is a "less than" operator or a syntax for generics). I can't find the reference right now, but there was a quote in one of the early discussions that was something like: The Generic Paradox is this: You can have slow programmers (no generics; programmers have to do their own code duplication), slow executables (where you do loads of unboxing), or slow compile times. EDIT: Found the reference; the exact quote is: "The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" [1] The Golang generics proposal was specifically designed to try to reduce the "slow programmers" effect while avoiding either of the other two effects as much as possible. [1] https://research.swtch.com/generic https://research.swtch.com/generic