7 ms·

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these co

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful languages. In under a decade Go swept up entire markets with a simple, down to earth language you can learn in a day and keep in your head. It optimized for the masses and the common cases and has absolutely eaten the lunch of these languages with lauded type systems that takes several courses in formal logic to even get started with.

nullwarp 3y ago
Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure. What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction) A full day later was still trying to get the Clojure app working correctly. He finished up the Go one in like an hour. Since then we've brought new devs on with zero Go experience and they are up writing good code in a day. I can't imagine where we would be if we had gone down the Clojure route.
- cempaka 3y ago
  As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or experience with," and then concluding the shovel is superior for all digging tasks from that point on.
  - Veraticus 3y ago
    I would say it skews towards languages that are easy to be immediately productive in, which is certainly one of Go's biggest strengths.
  - tornato7 3y ago
    Potentially. Devs might get up and running with Scratch even faster than Go. But I'm assuming the OP already determined that Go or Clojure would work well for the task. Go probably has a leg up on Clojure for reputation in production projects, considering Docker, K8s, Terraform, InfluxDB, and Geth are all written in Go. The biggest ones I can find written in Clojure are Puppet and CircleCI.
  - dogleash 3y ago
    > As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? pmuch. I migrated a team off of an aging enterprise application to the product that was rapidly gaining popularity in industry. I had some expertise and believed in it, I won't name products (and it wouldn't mean anything to HN anyway) but this was a painfully obvious change. We were the pilot project at the company, and went though 6 months of most users struggling. It was about 18 months after adoption that my boss told me he felt like the new product was both better and that the slow down had been worth it. Life isn't long enough for too many of those experiments. Not everything takes that long. And the experiment could have failed. But the experience really put lots of decisions into perspective. There's a saying that nobody uses technologies that their boss didn't learn in college. Factually inaccurate, quite astute in message.
  - cogman10 3y ago
    It skews towards languages that the developer is familiar with. Kotlin, for example, is a decent bit more complex than java is. It has a lot of new concepts to learn. Yet, most Java devs can be productive with kotlin in a day or two. Even with the added concepts, it's not that different of a language. The same is true of C and C++. A C dev could jump into C++ pretty quickly (even if they are just writing C with classes to start). Your analogy is more like "Dig a hole, here's a shovel and here's a post hole digger". The familiar tool will likely go faster than the unfamiliar tool. And, as it happens, most devs are highly familiar with imperative programming styles, not so much functional programming paradigms.
- za3faran 3y ago
  golang and Clojure are not in the same space, so it doesn't make sense to compare them. And I question this litmus test of using a junior dev anyway.
  - zimpenfish 3y ago
    > And I question this litmus test of using a junior dev anyway. As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard. [1] Sometimes literally a junior too. [2] There's a few things I think might trip up someone brand new to Go. [3] Looking at you, Perl and Ruby.
    - za3faran 3y ago
      Junior as in non-expert in the field. Using simplistic languages means optimizing for quickly pumping out code (at the expense of maintainability in the case of golang, as I've personally experienced at an employer that has one of the largest golang setups on the planet). Not to mention that golang comes with its own set of gotcha's and idiosyncrasies that need to be understood, especially in more involved programs. There's a good middle ground that can and has been achieved by other languages.
  - 59nadir 3y ago
    What does this actually mean? They are both programming languages made for solving general problems, what makes the comparison inappropriate? I've used both and pretty much all of their cousins, so I'm confused why you would think they aren't comparable. The "test" itself I agree is a bit shortsighted. I think Go might be a fine choice over time anyway, but the experiment itself doesn't necessarily highlight the things I'd want to highlight for medium- to long-term viability.
- giraffe_lady 3y ago
  I mean if you have ever written a for loop before you know enough go to get started. I like go fine but this seems like a very short sighted thing to optimize for.
- mr_00ff00 3y ago
  This seems good, except that it would always push for the languages that produce now and leave bugs for production. Python would beat anything by this measure, but static typing is amazing for stopping bugs.
- ducktective 3y ago
  Your "entry level" dev finished a non-trivial Go app in about an hour without knowing anything about Go? Literally how? Also he learned enough Clojure to mess around in, again with 0 knowledge about it. Again impressive. Or is this industry standard competency in some fields?
  - primax 3y ago
    A data dip via a single http endpoint is very easy to implement in go. Like 6-8 lines of code easy, with tons of examples available online
  - deleted 3y ago
    [deleted]
- john-radio 3y ago
  That's such a interesting experiment, but I can't help but think that whichever language's project was tackled first was playing at a serious disadvantage, even if the projects were somewhat different...
- IshKebab 3y ago
  I definitely agree that learning curve is important and Go is decent IMO but that still seems like a crazy way to choose a language. You don't hire a dev for one day and then fire them. It would be like deciding to dig the channel tunnel with a spade because TBMs are quite complicated to set up.
za3faran 3y ago
golang mainly ended up competing with and replacing the likes of python and ruby, where it was intended to compete with C and C++, where it didn't really change anything. It makes sense in retrospect of course, python and ruby are slow, dynamically typed languages, and any improvement in performance and typing is welcome. It doesn't mean that golang is inherently better somehow to other offerings. I still maintain that Java and C# are superior languages and ecosystems.
- matwood 3y ago
  Good point. I know I'm just being bitter, but I still can't stand Python after dealing with the 2->3 transition. I code mostly Java and use Go where I might have reached for Python before. The Go built in libs make it so easy to build small CLI apps where I may have used scripting before. And the cross compile situation makes it easy to ship wherever. I'm not a PLT person, and Go is easy for me to simply solve problems with. Probably also why I'm fine using modern Java.
- nateb2022 3y ago
  Why C#? It definitely has its own niche, and is good for building userspace Windows apps and games, however beyond Windows I don't think it has neither an established presence nor ecosystem. If anything, C# attempts to be more of a Java replacement than address Go's niche. Performance-wise, C# and Go are head-to-head: https://programming-language-benchmarks.vercel.app/go-vs-csharp https://programming-language-benchmarks.vercel.app/go-vs-csh... I also would say Go has been much more adopted for cross-platform use than C# ever was. Regarding language features, Go's devotion to staying intentionally bare-bones is worth a lot. C# may be more elegant in a lot of ways, however it seems to be in the process of being choked by Microsoft's continuous feature-creep.
  - Capricorn2481 3y ago
    C# has way, way more market share than Go as well as a bigger ecosystem and it's not even close. I would hardly call a Java replacement a "niche" since that's everywhere. There are, of course, other benchmarks that rank c# above go, but benchmarks are flawed. I imagine people are comparing C# to go because it's got a pretty solid type system
mikebenfield 3y ago
> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful Fine. But it's beside your parent comment's point. The article claims that everyone thought Go's type system was an advance on the state of the art. This isn't even close to true.
- primax 3y ago
  Building something that can be successfully adopted and operationalized at mass scale is an element of the state of the art.
  - xctr94 3y ago
    Amen. I’ll give Microsoft crap any day, but the most popular language on Earth is now routinely developed with a sane type interpreter that eliminates entire error categories.
monksy 3y ago
> you can learn in a day and keep in your head. I'm not sure that this successpoint is really that valuable. It sounds more valuable for those who want butts in seats than it does for long term satisfaction and survivability of your code base.
- omegabravo 3y ago
  Being able to read your code you wrote 2 years ago does wonders for survivability, which is a gross simplification of course. It's a great language for some problems, horrible for others. The problem is people tend to talk as though everyone works in their domain.
  - monksy 3y ago
    > Being able to read your code you wrote 2 years ago It won't stop you from asking wtf did someone write this and then doing a git blame and seeing your name.
  - kaba0 3y ago
    If “each individual line is easy” would work, we would be reading-writing in assembly. I don’t accept the premise that Go would be any better in this region, if anything, it is worse by cluttering up the happy path by error “handling” noise, and much harder than they should be opewtions.
- gaganyaan 3y ago
  Yeah, I can keep Brainfuck in my head easily. Doesn't mean I'm going to use it as anything other than a toy language.
tomcam 3y ago
Now you’ve got me curious. I’d like to type inference in go. Can you tell me what languages do it better?
- wk_end 3y ago
  In ML-lineage languages (including Haskell) you almost never need any type annotations whatsoever, at least not unless you’re poking around at the fringes of those languages (GADTs, various GHC extensions). Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself.
  - Mawr 3y ago
    From my experience, such type inference systems are awful in practice. Rust designers tried to do something like that initially but quickly realized understandability suffered greatly. You really do want to specify types manually, at least at boundaries, e.g. in function definitions. > Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself. See? That's not a good thing at all. If the compiler's capability makes the code less understandable, then it's undesirable. Doesn't matter how fancy and cool, or state-of-the-art it may be. You probably don't want to strap a jet engine to a car, no matter how cool you may think it would be.
    - tialaramex 3y ago
      Right, global inference turns out to be too much inference. Function boundaries are a convenient place to draw a line. As usual C++ choose to something much weirder and more dangerous. Instead of inference C++ can deduce types, in some cases there's no way to write a type's name so you have to deduce types, and they can be deduced at the edges of functions however unlike inference it's not an error to have ambiguity, in some cases deduction may choose one of the possibilities that it liked better even if that's astonishing for you. Because Rust's functions must tell you their types explicitly, and because some types can't be named specifically, the result is that in Rust you have to write these functions polymorphically, even if in practice there's only one possibility. In C++ you can write the non-polymorphic function, despite not being able to say the name of the type. How do you document that? It's OK, C++ doesn't require you to provide even halfway usable documentation.
tsss 3y ago
Go has "swept up entire markets" because they have an unlimited marketing budget. It has nothing to do with the merits of the language itself.
- philosopher1234 3y ago
  Can you point to something Go has spent this hypothetical marketing budget on?
  - pjmlp 3y ago
    Docker, Kubernetes and key CNCF projects.
    - philosopher1234 3y ago
      What was the marketing investment here..?
      - pjmlp 3y ago
        Google is using Go to implement Kubernetes. Kubernetes is cool, I want to play with Kubernetes. Maybe I should lean Go to play.
        philosopher1234 3y ago
        Ok, but calling this a marketing spend that has nothing to do with the language seems ridiculous.
worik 3y ago
> PLT community What is that?
- wk_end 3y ago
  “Programming Language Theory”
cheriot 3y ago
I'd phrase it as: ruby, python, and javascript created a generation of programmers that didn't know how to use a type system. When they needed something more light weight and performant, they migrated to the language with the most primitive type system. Typescript and swift have shown a better type system can appeal to the masses.
LinXitoW 3y ago
Go has succeeded because it's not horrible and supported and used by one of the biggest companies out there. That means you end up with a long list of decent libraries, which to me feels like the main factor of success for a language.
- sethammons 3y ago
  Why has Dart not taken off?
  - pjmlp 3y ago
    Because politics, Google wanted to do an hostile takeover JavaScript, it backfired, Chrome dropped DartiumVM, and they only got rescued thanks AdWords. Key language designers left after this. However it seems to have enough management support, that since it found an home in Flutter, I would assert there are having more adoption than Xamarin, React Native or Cordova.
  - lenkite 3y ago
    Dart is advertised as a client-optimized language. Optimized for UI is what the home page says. Say Goodbye to convincing people to use it on the server.
soulbadguy 3y ago
> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. And nothing says that go wouldn't have been more successful had they added those features. In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. But IMO, the success is not a good measure of wether or not the criticism of go were/are valid. > Go made me truly realize how insufferable the PLT community is Agree PLT folks can be a passionate bunch, i am not sure they are any worst to any other online community. > and why they are so absolutely lost when it comes to creating successful languages. Depends on who you include in the PLT group : - C# and typescript were design by Anders Hejlsberg , arguably the most successful language designer - Scala is also pretty successful and really tied to the PLT community - Kotlin by JetBrain, Dart started with Gilan Bracha Not to mentioned the wide range of features seen in most recent language (async-await, reactive programming for msft research) etc... etc... The fight between pragmatic and simple language vs complex and expressive language is not happening outside the PLT, we have proponent of both ways of thinking inside the community. Not everyone in the PLT is pushing for overly complex theoretical approaches. But more importantly, let's not forget the 1000's of engineer quietly implementing the compiler, libraries etc... that make go, or any other language possible. Back to go, my personal gripe with go wasn't the decisions they made, but the rational given for those decisions. Take the most famous example of not including generics. Designing a good generic type system is a very complicated task, and if the team had come out and say they didn't want generics because they didn't have the bandwidth or the know-how to do so, i wouldn't have care. But the rational given, describing generics as border line useless, or somehow too hard for the average programmer to grasp not only fly against basically 25 years of programming language history, but were just plain rediculous.
- Mawr 3y ago
  > In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. Not at all. It's the same as with literally any other product. If it's good, people will use it. Outliers are rare. Now, you may disagree with what most people consider good, but that's another discussion ;)
pjmlp 3y ago
As proven by Oberon-2 and Limbo ancestors, it helps to have a good godfather.
curryhoward 3y ago
> and why they are so absolutely lost when it comes to creating successful languages They aren't lost—they're just more interested in actually good ideas than in popularity. Popular languages must appeal to all kinds of programmers with varying backgrounds, so they are heavily constrained. Your argument is basically that mathematicians don't know what they're doing because their most advanced theories aren't used by mechanical engineers.
deleted 3y ago
[deleted]
Tainnor 3y ago
What do you mean by "Go has succeeded"? It has found its niche, yes, but so have those HM languages (maybe the Go niche is a bit bigger), and a bunch of other languages that people also like to hate. Meanwhile, most code is still written in languages like Java, C and PHP. That's no value judgement or anything, I don't think Java is an amazing language (neither do I think it's a terrible one), but it's not like Go has revolutionised anything. It's just become a new option among many.
- EspressoGPT 3y ago
  The fact that you mention Go, an 11-year-old language, alongside a 27-year-old, a 51-year-old and a 28-year-old language proves that it has succeeded.
  - Tainnor 3y ago
    Then so has Ruby, Haskell, Erlang, and a bunch of other languages that espouse virtues completely contrary to Go. So I'm not sure what your point is? Also you didn't even get my point because I explictly contrasted Go, as a niche language, with the big languages that most things are written in.
sharts 3y ago
Part of that success may have to do with "Wow, Google invented this...let's use it." Kubernetes adoption seems to be going up but does it really add value for most that adopt it? I would say, no.
gaganyaan 3y ago
Nah mate, sorry. Go is a language already past its prime, which is laughable given how young it is, and how it was modeled on better, long-lived languages. Take a look at Google trends if you disbelieve me. There was a slight bump in interest when generics finally got pushed out, but that's died off, and Go is entering the same decline as other has-beens like Ruby. Good riddance to a language designed for people that aren't good at programming (you'll have to look up the quote yourself, I'm too lazy).
- EspressoGPT 3y ago
  Most SWEs aren't particularly good at programming. It's not a shame to embrace that.

nullwarp 3y ago

Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure. What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction) A full day later was still trying to get the Clojure app working correctly. He finished up the Go one in like an hour. Since then we've brought new devs on with zero Go experience and they are up writing good code in a day. I can't imagine where we would be if we had gone down the Clojure route.

cempaka 3y ago
As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or experience with," and then concluding the shovel is superior for all digging tasks from that point on.
- Veraticus 3y ago
  I would say it skews towards languages that are easy to be immediately productive in, which is certainly one of Go's biggest strengths.
- tornato7 3y ago
  Potentially. Devs might get up and running with Scratch even faster than Go. But I'm assuming the OP already determined that Go or Clojure would work well for the task. Go probably has a leg up on Clojure for reputation in production projects, considering Docker, K8s, Terraform, InfluxDB, and Geth are all written in Go. The biggest ones I can find written in Clojure are Puppet and CircleCI.
- dogleash 3y ago
  > As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? pmuch. I migrated a team off of an aging enterprise application to the product that was rapidly gaining popularity in industry. I had some expertise and believed in it, I won't name products (and it wouldn't mean anything to HN anyway) but this was a painfully obvious change. We were the pilot project at the company, and went though 6 months of most users struggling. It was about 18 months after adoption that my boss told me he felt like the new product was both better and that the slow down had been worth it. Life isn't long enough for too many of those experiments. Not everything takes that long. And the experiment could have failed. But the experience really put lots of decisions into perspective. There's a saying that nobody uses technologies that their boss didn't learn in college. Factually inaccurate, quite astute in message.
- cogman10 3y ago
  It skews towards languages that the developer is familiar with. Kotlin, for example, is a decent bit more complex than java is. It has a lot of new concepts to learn. Yet, most Java devs can be productive with kotlin in a day or two. Even with the added concepts, it's not that different of a language. The same is true of C and C++. A C dev could jump into C++ pretty quickly (even if they are just writing C with classes to start). Your analogy is more like "Dig a hole, here's a shovel and here's a post hole digger". The familiar tool will likely go faster than the unfamiliar tool. And, as it happens, most devs are highly familiar with imperative programming styles, not so much functional programming paradigms.
za3faran 3y ago
golang and Clojure are not in the same space, so it doesn't make sense to compare them. And I question this litmus test of using a junior dev anyway.
- zimpenfish 3y ago
  > And I question this litmus test of using a junior dev anyway. As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard. [1] Sometimes literally a junior too. [2] There's a few things I think might trip up someone brand new to Go. [3] Looking at you, Perl and Ruby.
  - za3faran 3y ago
    Junior as in non-expert in the field. Using simplistic languages means optimizing for quickly pumping out code (at the expense of maintainability in the case of golang, as I've personally experienced at an employer that has one of the largest golang setups on the planet). Not to mention that golang comes with its own set of gotcha's and idiosyncrasies that need to be understood, especially in more involved programs. There's a good middle ground that can and has been achieved by other languages.
- 59nadir 3y ago
  What does this actually mean? They are both programming languages made for solving general problems, what makes the comparison inappropriate? I've used both and pretty much all of their cousins, so I'm confused why you would think they aren't comparable. The "test" itself I agree is a bit shortsighted. I think Go might be a fine choice over time anyway, but the experiment itself doesn't necessarily highlight the things I'd want to highlight for medium- to long-term viability.
giraffe_lady 3y ago
I mean if you have ever written a for loop before you know enough go to get started. I like go fine but this seems like a very short sighted thing to optimize for.
mr_00ff00 3y ago
This seems good, except that it would always push for the languages that produce now and leave bugs for production. Python would beat anything by this measure, but static typing is amazing for stopping bugs.
ducktective 3y ago
Your "entry level" dev finished a non-trivial Go app in about an hour without knowing anything about Go? Literally how? Also he learned enough Clojure to mess around in, again with 0 knowledge about it. Again impressive. Or is this industry standard competency in some fields?
- primax 3y ago
  A data dip via a single http endpoint is very easy to implement in go. Like 6-8 lines of code easy, with tons of examples available online
- deleted 3y ago
  [deleted]
john-radio 3y ago
That's such a interesting experiment, but I can't help but think that whichever language's project was tackled first was playing at a serious disadvantage, even if the projects were somewhat different...
IshKebab 3y ago
I definitely agree that learning curve is important and Go is decent IMO but that still seems like a crazy way to choose a language. You don't hire a dev for one day and then fire them. It would be like deciding to dig the channel tunnel with a spade because TBMs are quite complicated to set up.

za3faran 3y ago

golang mainly ended up competing with and replacing the likes of python and ruby, where it was intended to compete with C and C++, where it didn't really change anything. It makes sense in retrospect of course, python and ruby are slow, dynamically typed languages, and any improvement in performance and typing is welcome. It doesn't mean that golang is inherently better somehow to other offerings. I still maintain that Java and C# are superior languages and ecosystems.

matwood 3y ago
Good point. I know I'm just being bitter, but I still can't stand Python after dealing with the 2->3 transition. I code mostly Java and use Go where I might have reached for Python before. The Go built in libs make it so easy to build small CLI apps where I may have used scripting before. And the cross compile situation makes it easy to ship wherever. I'm not a PLT person, and Go is easy for me to simply solve problems with. Probably also why I'm fine using modern Java.
nateb2022 3y ago
Why C#? It definitely has its own niche, and is good for building userspace Windows apps and games, however beyond Windows I don't think it has neither an established presence nor ecosystem. If anything, C# attempts to be more of a Java replacement than address Go's niche. Performance-wise, C# and Go are head-to-head: https://programming-language-benchmarks.vercel.app/go-vs-csharp https://programming-language-benchmarks.vercel.app/go-vs-csh... I also would say Go has been much more adopted for cross-platform use than C# ever was. Regarding language features, Go's devotion to staying intentionally bare-bones is worth a lot. C# may be more elegant in a lot of ways, however it seems to be in the process of being choked by Microsoft's continuous feature-creep.
- Capricorn2481 3y ago
  C# has way, way more market share than Go as well as a bigger ecosystem and it's not even close. I would hardly call a Java replacement a "niche" since that's everywhere. There are, of course, other benchmarks that rank c# above go, but benchmarks are flawed. I imagine people are comparing C# to go because it's got a pretty solid type system

mikebenfield 3y ago

> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful Fine. But it's beside your parent comment's point. The article claims that everyone thought Go's type system was an advance on the state of the art. This isn't even close to true.

primax 3y ago
Building something that can be successfully adopted and operationalized at mass scale is an element of the state of the art.
- xctr94 3y ago
  Amen. I’ll give Microsoft crap any day, but the most popular language on Earth is now routinely developed with a sane type interpreter that eliminates entire error categories.

monksy 3y ago

> you can learn in a day and keep in your head. I'm not sure that this successpoint is really that valuable. It sounds more valuable for those who want butts in seats than it does for long term satisfaction and survivability of your code base.

omegabravo 3y ago
Being able to read your code you wrote 2 years ago does wonders for survivability, which is a gross simplification of course. It's a great language for some problems, horrible for others. The problem is people tend to talk as though everyone works in their domain.
- monksy 3y ago
  > Being able to read your code you wrote 2 years ago It won't stop you from asking wtf did someone write this and then doing a git blame and seeing your name.
- kaba0 3y ago
  If “each individual line is easy” would work, we would be reading-writing in assembly. I don’t accept the premise that Go would be any better in this region, if anything, it is worse by cluttering up the happy path by error “handling” noise, and much harder than they should be opewtions.
gaganyaan 3y ago
Yeah, I can keep Brainfuck in my head easily. Doesn't mean I'm going to use it as anything other than a toy language.

tomcam 3y ago

Now you’ve got me curious. I’d like to type inference in go. Can you tell me what languages do it better?

wk_end 3y ago
In ML-lineage languages (including Haskell) you almost never need any type annotations whatsoever, at least not unless you’re poking around at the fringes of those languages (GADTs, various GHC extensions). Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself.
- Mawr 3y ago
  From my experience, such type inference systems are awful in practice. Rust designers tried to do something like that initially but quickly realized understandability suffered greatly. You really do want to specify types manually, at least at boundaries, e.g. in function definitions. > Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself. See? That's not a good thing at all. If the compiler's capability makes the code less understandable, then it's undesirable. Doesn't matter how fancy and cool, or state-of-the-art it may be. You probably don't want to strap a jet engine to a car, no matter how cool you may think it would be.
  - tialaramex 3y ago
    Right, global inference turns out to be too much inference. Function boundaries are a convenient place to draw a line. As usual C++ choose to something much weirder and more dangerous. Instead of inference C++ can deduce types, in some cases there's no way to write a type's name so you have to deduce types, and they can be deduced at the edges of functions however unlike inference it's not an error to have ambiguity, in some cases deduction may choose one of the possibilities that it liked better even if that's astonishing for you. Because Rust's functions must tell you their types explicitly, and because some types can't be named specifically, the result is that in Rust you have to write these functions polymorphically, even if in practice there's only one possibility. In C++ you can write the non-polymorphic function, despite not being able to say the name of the type. How do you document that? It's OK, C++ doesn't require you to provide even halfway usable documentation.

tsss 3y ago

Go has "swept up entire markets" because they have an unlimited marketing budget. It has nothing to do with the merits of the language itself.

philosopher1234 3y ago
Can you point to something Go has spent this hypothetical marketing budget on?
- pjmlp 3y ago
  Docker, Kubernetes and key CNCF projects.
  - philosopher1234 3y ago
    What was the marketing investment here..?
    - pjmlp 3y ago
      Google is using Go to implement Kubernetes. Kubernetes is cool, I want to play with Kubernetes. Maybe I should lean Go to play.
      - philosopher1234 3y ago
        Ok, but calling this a marketing spend that has nothing to do with the language seems ridiculous.

worik 3y ago

> PLT community What is that?

wk_end 3y ago
“Programming Language Theory”

cheriot 3y ago

I'd phrase it as: ruby, python, and javascript created a generation of programmers that didn't know how to use a type system. When they needed something more light weight and performant, they migrated to the language with the most primitive type system. Typescript and swift have shown a better type system can appeal to the masses.

LinXitoW 3y ago

Go has succeeded because it's not horrible and supported and used by one of the biggest companies out there. That means you end up with a long list of decent libraries, which to me feels like the main factor of success for a language.

sethammons 3y ago
Why has Dart not taken off?
- pjmlp 3y ago
  Because politics, Google wanted to do an hostile takeover JavaScript, it backfired, Chrome dropped DartiumVM, and they only got rescued thanks AdWords. Key language designers left after this. However it seems to have enough management support, that since it found an home in Flutter, I would assert there are having more adoption than Xamarin, React Native or Cordova.
- lenkite 3y ago
  Dart is advertised as a client-optimized language. Optimized for UI is what the home page says. Say Goodbye to convincing people to use it on the server.

soulbadguy 3y ago

> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. And nothing says that go wouldn't have been more successful had they added those features. In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. But IMO, the success is not a good measure of wether or not the criticism of go were/are valid. > Go made me truly realize how insufferable the PLT community is Agree PLT folks can be a passionate bunch, i am not sure they are any worst to any other online community. > and why they are so absolutely lost when it comes to creating successful languages. Depends on who you include in the PLT group : - C# and typescript were design by Anders Hejlsberg , arguably the most successful language designer - Scala is also pretty successful and really tied to the PLT community - Kotlin by JetBrain, Dart started with Gilan Bracha Not to mentioned the wide range of features seen in most recent language (async-await, reactive programming for msft research) etc... etc... The fight between pragmatic and simple language vs complex and expressive language is not happening outside the PLT, we have proponent of both ways of thinking inside the community. Not everyone in the PLT is pushing for overly complex theoretical approaches. But more importantly, let's not forget the 1000's of engineer quietly implementing the compiler, libraries etc... that make go, or any other language possible. Back to go, my personal gripe with go wasn't the decisions they made, but the rational given for those decisions. Take the most famous example of not including generics. Designing a good generic type system is a very complicated task, and if the team had come out and say they didn't want generics because they didn't have the bandwidth or the know-how to do so, i wouldn't have care. But the rational given, describing generics as border line useless, or somehow too hard for the average programmer to grasp not only fly against basically 25 years of programming language history, but were just plain rediculous.

Mawr 3y ago
> In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. Not at all. It's the same as with literally any other product. If it's good, people will use it. Outliers are rare. Now, you may disagree with what most people consider good, but that's another discussion ;)

pjmlp 3y ago

As proven by Oberon-2 and Limbo ancestors, it helps to have a good godfather.

curryhoward 3y ago

> and why they are so absolutely lost when it comes to creating successful languages They aren't lost—they're just more interested in actually good ideas than in popularity. Popular languages must appeal to all kinds of programmers with varying backgrounds, so they are heavily constrained. Your argument is basically that mathematicians don't know what they're doing because their most advanced theories aren't used by mechanical engineers.

deleted 3y ago

[deleted]

Tainnor 3y ago

What do you mean by "Go has succeeded"? It has found its niche, yes, but so have those HM languages (maybe the Go niche is a bit bigger), and a bunch of other languages that people also like to hate. Meanwhile, most code is still written in languages like Java, C and PHP. That's no value judgement or anything, I don't think Java is an amazing language (neither do I think it's a terrible one), but it's not like Go has revolutionised anything. It's just become a new option among many.

EspressoGPT 3y ago
The fact that you mention Go, an 11-year-old language, alongside a 27-year-old, a 51-year-old and a 28-year-old language proves that it has succeeded.
- Tainnor 3y ago
  Then so has Ruby, Haskell, Erlang, and a bunch of other languages that espouse virtues completely contrary to Go. So I'm not sure what your point is? Also you didn't even get my point because I explictly contrasted Go, as a niche language, with the big languages that most things are written in.

sharts 3y ago

Part of that success may have to do with "Wow, Google invented this...let's use it." Kubernetes adoption seems to be going up but does it really add value for most that adopt it? I would say, no.

gaganyaan 3y ago

Nah mate, sorry. Go is a language already past its prime, which is laughable given how young it is, and how it was modeled on better, long-lived languages. Take a look at Google trends if you disbelieve me. There was a slight bump in interest when generics finally got pushed out, but that's died off, and Go is entering the same decline as other has-beens like Ruby. Good riddance to a language designed for people that aren't good at programming (you'll have to look up the quote yourself, I'm too lazy).

EspressoGPT 3y ago
Most SWEs aren't particularly good at programming. It's not a shame to embrace that.