9 ms·

IIRC Rust was influenced more by OCaml than Haskell, but I could be wrong. The article really rubbed me the wrong way with this tidbit > (we don’t talk about

IIRC Rust was influenced more by OCaml than Haskell, but I could be wrong. The article really rubbed me the wrong way with this tidbit > (we don’t talk about Go…) So since the author is speaking of "premier system’s language" we choose to ignore the world's premier cloud language? Interesting.

zingplex 6y ago
I'm pretty sure that was just a joke about Go's primitive type system.
- dimitrios1 6y ago
  I mean if we save the "intellectual superiority" of Haskells or other FP languages -- (I've used them all) -- in practice with teams of other engineers, and in production where it counts the most, Go has outshined them all. So primitive is surely a way to describe it.
  - kdkeyser 6y ago
    I fail to see how else than "primitive" you can call the Go type system: it is roughly what you would get from a language designed in the 70's, and a lot of advances have since been made. Whether or not these advances make a difference (positive or negative) in production is different question, but I'd rather not use "how much is a language used", as an inherent quality metric for a programming language. Otherwise, I fear we might all end up doing old-school Java, Javascript, Visual Basic and ABAP.
    - dimitrios1 6y ago
      > "how much is a language used", as an inherent quality metric for a programming language. Define quality. Because what I've realized with the PL-elitist crowd is this almost always boils down to "the ability to be expressive" which is fine but it certainly isn't a complete metric, and, to borrow a common refrain, we've had expressive languages in the 70's as well, we've had s-expressions for a while now. What about other metrics, such as "ability for mass amounts of programmers to program the computer to do the correct thing?" and "ability for programmer to maintain said program?" -- you know, real world quality. My point is, people's usual quality metrics are often incomplete or narrowly defined. In either case, if Go is so primitive, then why didn't the 70s produce a language like Go? Why did developers who created languages, operating systems, and systems software in the 70s not make Go until the 2000s (you do know who created Go, right?) I just don't buy this argument, especially having used those "advanced" type systems for many years, sorry.
      - AnimalMuppet 6y ago
        I mostly agree with you, but the claim was that Go's type system was 70s-era primitive. And I think that claim is probably correct. The type system of Go isn't all that sophisticated or "advanced". But all that says is that the magic of Go isn't in the type system. The couldn't produce-it-until-the-2000s isn't in the type system. The thing that makes Go more used in the real world than Haskell isn't the sophistication of the type system. I don't see much to argue with in those claims.
      - Vampiero 6y ago
        There's a difference in mentality between people who make either argument. The "PL-elitist" crowd looks at programming languages from a computer science perspective, while the "PL-pragmatist" crowd (for lack of a better term) looks at it from a workplace perspective. At least that's how I see it. In other words, one group writes tooling and libraries; the other writes business applications using said tooling and libraries. One paradigm invites complex, highly expressive code as to minimize the chance of unforeseen errors (even if just by having a smaller codebase), and as to provide a clean and powerful interface that "does more with less". The other invites simple, highly maintainable code as to minimize the training overhead of new employees and the chance that their lack of rigor might end up accidentally introducing or reintroducing bugs. Furthermore, a simpler language means that new teams can hop onto a pre-existing project faster, because they don't have to scrutinize each LOC to the same extent. I might be wrong on any or all of this, but that's how I perceive it.
        deleted 6y ago
        [deleted]
      - kdkeyser 6y ago
        I am not sure that my message was completely clear: my point was that despite Go having an objectively old/primitive type system, compared to modern state of the art, that does not preclude it from being a successful "production" language. The value the type system brings is, in my experience, rarely the most important factor in the success/failure of a software project. My second point was that the popularity of Go (or any language) does not mean that it is inherently a good language, where good can mean, productivity, defect rate, .... Adoption of a language depends on many things, I believe quality of the tools, availability of libraries, and good old marketing (the Google aura around Go has helped in adoption) are often more important. The effort to make an initial, crappy, proof-of-concept is in my experience often decisive for the choice of language. The cost of long term maintenance (where a good type system might bring value) is rarely considered. For Go, it also hasn't hurt that some of the core developers where being paid by Google to work on it. The metric of the "ability for mass amounts of programmers to program the computer", is indeed a very relevant one, and I think Go shines there. When reading Go code, I typically find it easy to understand what the goal of the code is. However, "to do the correct thing", is often less of a success: there are off-by-one error and corner cases that have bugs, and reimplementations of the same basic logic. If you have a lot of developers available, you simply have them fix these issues, and your Go project becomes a success. My point is, that in this scenario, the language itself is of minor importance: success is determined by the fact that you have access to a large pool of relatively cheap labor of reasonable quality (Google or VC funded startups are perfect examples). A 20 or even 50% productivity gain by having a "better" language would simply not matter for the outcome, certainly not if it takes your labor longer to get up to speed. So, in that context, compared to the alternatives, the quality of Go is relatively high. But I do think that, if during the design of Go they had taken a couple of basic concepts from ML like sum types, polymorphism, and a decent module system, they would have ended up with a language that would make the current Go look unproductive and poor quality, even in that same context. It wouldn't make a difference to Google, but it would make the life of many a developer a little bit more productive and joyful. And yes, I do know who created Go, but arguments by authority carry little weight.
    - AnimalMuppet 6y ago
      "How much a language is used" is a proxy for "how useful is the language for actually writing programs". And, really, what else do we mean by the "quality" of a programming language? If it's beautiful, but not as good for actually writing programs, then it has quality as a work of art, but less quality as a programming language.
      - goatlover 6y ago
        There's other reasons languages become popular such as platform support, marketing, what people learn in school or as a first language, and what gets you hired. Popularity does not necessarily imply any sort of superiority of a PL usage compared to others.
        AnimalMuppet 6y ago
        I think you are going too far here. Taken at face value, your post says that for programming languages, there is zero correlation between popularity (use) and superiority (fitness for use). That implies that everyone choosing a language for a project is either stupid or ignorant (not the same thing). That may offer consolation to those who think that certain languages are the best, and who wonder why those "best" languages are used so little. But I don't think it's true. I don't think programmers are stupid, ignorant, or sheep. I think if a tool offers them advantages, they'll use it. Perhaps I should qualify: significant advantages. There is a cost to switching. The switched-to language has to be enough better to pay back the cost.
      - rowanG077 6y ago
        This is not actually true. Do you seriously believe Go would have ANY popularity now if it wasn't released and massively marketed by a BigCo?
        Jtsummers 6y ago
        It probably would've ended up in the same place as Limbo and Alef. Interesting, useful, but of limited use and exposure to the world.
    - pjmlp 6y ago
      Actually it is worse than that, have a look at most languages designed in the 70s, like CLU and Modula-2.
      - zingplex 6y ago
        Worse in what ways?
        pjmlp 6y ago
        Support for generics (CLI) and exceptions (both). There are other languages I can take out of the bag like Mesa/Cedar, Interlisp-D, Smalltalk-80, although they are already on the 80's borderline, which then also brings Ada, Standard ML and Object Pascal into the picture.
  - bird_monster 6y ago
    Careful, here on HN you can't suggest getting things completed is a valid metric for success.
    - dang 6y ago
      Would you please stop posting supercilious dismissals of the community? You've already done this more than once, and that's a very bad sign for a new account. (Edit: Perhaps I should explain that last bit. Actual new users never comment this way—only seasoned users, and the ones who do it are usually using new accounts because they've behaved badly with earlier ones.) https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - bird_monster 6y ago
        I can try to be more direct in pointing out the obvious biases that we have on this echochamber, if you think that would spark more thoughtful debate? If you think the tone of the post was wrong, I can address that, but I don't really think that it's fair to suggest we avoid talking about this kind of thing? My other comment that you're calling a "supercilious dismissal" also received 31 upvotes and some interesting responses, fwiw.
        dang 6y ago
        What people call "obvious biases" are typically what they themselves are choosing to select out of the statistical cloud of posts that get made here. The bias at work in making such a selection is one's own, but we project it onto the community, and then create a superior image of ourselves by posturing above it, which is what I mean by supercilious. This is a drama between oneself and oneself, which has nothing to do with real conversation. It's a way of changing the subject to oneself. To be fair, you're hardly the only one doing it; it's quite common, but I have to tell you that it tends to be low-quality commenters who do this. It frequently comes with labels like "echochamber" and "groupthink", which are also ways of elevating oneself as the noble freethinker standing against the mob, or some such image. Actual noble freethinkers never behave like this, so the whole thing is incongruent—it's simply a way of flattering oneself, which (ironically, because we all feel so unique) is one of the most repetitive and tedious things that people do. That's why we shouldn't do it on a site that's trying to have interesting conversation. Another angle: people seem to posture above the community when they feel like they need to defend themselves against it. Presumably they want to defend themselves against some claim of i-am-very-smartness that they feel is emanating from the community, so they puff themselves up and put the community down by way of compensation. In reality, though, no one is making such a claim. HN isn't making such a claim—HN isn't a person to begin with—and certainly the people running HN are making no such claim. It rather arises in the psyche of some readers, for whatever internal reasons. The internet can be crazy-making that way.
  - przemo_li 6y ago
    You really have to stop assuming "intellectual superiority" when people talk about more advanced / less advanced stuff. Go have limited capabilities type system. C have limited capabilities type system. Both are quite successful. If talking about C I didn't shown "intellectual superiority", maybe it would be incorrect label if I where to talk about Go?
    - eru 6y ago
      Go is just a lot of missed opportunities, that they could have taken without making the language any more complicated.
  - eru 6y ago
    In what sense has Go outshined anything?
JulianMorrison 6y ago
I was amused at that. It's clear this author is not Go's constituency. You cannot use types to ensure consistency in Go, you just have to write the algorithm correctly. But Go fronts the algorithm and keeps the noise around it to a minimum. They are opposed but equivalent strategies.
- eru 6y ago
  You still have to get the algorithms right in eg Haskell. It's just that in Haskell you have to write fewer tests to be sure you did it right, because for many kinds of mistakes you could have made, the compiler can yell at you. The other advantage of nicer types is that they serve as part of the documentation. Exactly because the types can constraint the behaviour of implementations more than in Go. So the reader can make more valid assumptions from the type alone. Hoogle uses those types to give you a truly extra-ordinary way to search the Haskell libraries via types. That approach would be almost useless in Go, and you have to fall back to searching via keywords etc only.
steveklabnik 6y ago
Rust was initially implemented in OCaml, even. But that said, it gained a lot of more Haskell like features later on; we ended up with type classes, not ML modules, for example. EDIT: also, strictly speaking, Rust doesn't use Hindley-Milner, and we don't have parametric polymorphism.
- veets 6y ago
  Can you clarify why you don't think Rust has parametric polymorphism? struct Person<T> { age: T, } Is parametric polymorphism and valid Rust.
  - steveklabnik 6y ago
    Just because some bounds are parametric does not mean that all of them are; specialization violates parametricity, for example. While that's not in Rust proper yet, it did require making sure that dropck could handle it, for example, and the intention is to ship it. There's also more minor things like https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179973108 https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179...
    - Rusky 6y ago
      In a sense even things like `TypeId::of` or `mem::size_of` violate parametricity.
    - veets 6y ago
      I don't doubt you know more about Rust than I do, but this seems pedantic to me. Kind of like correcting someone for pronouncing forte as "for-TAY" instead of "fort" or telling someone "well technically you don't actually touch _anything_ because of the electrostatic force." If you ask all the developers out there to describe parametric and ad-hoc polymorphism I think a vast majority would give the example of a type parameter (e.g., Java generics or C++ templates) for parametric polymorphism and Java interfaces or Haskell's classes for ad-hoc polymorphism. I can even quote directly from Pierce (Types and Programming Languages): > Parametric polymorphism, the topic of this chapter, allows a single piece of code to be typed "generically," using variables in place of actual types, and then instantiated with particular types as needed. Parametric definitions are uniform: all of their instances behave the same. I think Rust and the aforementioned languages fit this definition. Outside of a specific compiler issue, claiming otherwise seems to only confuse the issue, especially for those just casually reading and not familiar with programming language theory.
cgh 6y ago
Yes, this was my favourite line: > However, in 2020, the premier system’s language is surely Rust. Yesterday I was speaking with a friend who runs a small company doing contracted embedded programming (the embedded OS is often Linux but often not) and he'd never even heard of Rust. Maybe it's a little lower level than what's meant by "systems" here but still, the article's statement is just delusional.
- Jtsummers 6y ago
  The largest vocal community today for a systems language (meaning down to the OS level with strong determinism guarantees, not the redefinition to make Go a systems language meaning server systems) is definitely Rust. But in practice, no one is using it because their systems predate it, don't have compilers for it, or they simply can't use it due to their problem domain (it has an insufficient history, they can't contract support with the compiler team for it, or whatever). I can go to Green Hills and get a contract that guarantees their compiler will be available and supported for my target platform for the next 10+ years. Rust is still a moving target with a single implementation, and no (present) way to get the guarantees needed for the embedded domains I've been involved in. I'd like to see Rust experimented with there, but it won't be the "go to" language for quite some time.
  - steveklabnik 6y ago
    Fun story: here's a recent talk by someone at Green Hills, talking about experiences giving Rust a try https://www.youtube.com/watch?v=G5A7rSPYpb8 https://www.youtube.com/watch?v=G5A7rSPYpb8
    - Jtsummers 6y ago
      Thanks for the link, I'll check it out later.
    - deleted 6y ago
      [deleted]
  - dimitrios1 6y ago
rowanG077 6y ago
How is Go the premier cloud computing language? I would say that crown goes to Python. I almost never encounter Go when working with cloud computing.
sweeneyrod 6y ago
What does "premier cloud language" mean?
eru 6y ago
Are you saying Go is the 'premier system's language'?

zingplex 6y ago

I'm pretty sure that was just a joke about Go's primitive type system.

dimitrios1 6y ago
I mean if we save the "intellectual superiority" of Haskells or other FP languages -- (I've used them all) -- in practice with teams of other engineers, and in production where it counts the most, Go has outshined them all. So primitive is surely a way to describe it.
- kdkeyser 6y ago
  I fail to see how else than "primitive" you can call the Go type system: it is roughly what you would get from a language designed in the 70's, and a lot of advances have since been made. Whether or not these advances make a difference (positive or negative) in production is different question, but I'd rather not use "how much is a language used", as an inherent quality metric for a programming language. Otherwise, I fear we might all end up doing old-school Java, Javascript, Visual Basic and ABAP.
  - dimitrios1 6y ago
    > "how much is a language used", as an inherent quality metric for a programming language. Define quality. Because what I've realized with the PL-elitist crowd is this almost always boils down to "the ability to be expressive" which is fine but it certainly isn't a complete metric, and, to borrow a common refrain, we've had expressive languages in the 70's as well, we've had s-expressions for a while now. What about other metrics, such as "ability for mass amounts of programmers to program the computer to do the correct thing?" and "ability for programmer to maintain said program?" -- you know, real world quality. My point is, people's usual quality metrics are often incomplete or narrowly defined. In either case, if Go is so primitive, then why didn't the 70s produce a language like Go? Why did developers who created languages, operating systems, and systems software in the 70s not make Go until the 2000s (you do know who created Go, right?) I just don't buy this argument, especially having used those "advanced" type systems for many years, sorry.
    - AnimalMuppet 6y ago
      I mostly agree with you, but the claim was that Go's type system was 70s-era primitive. And I think that claim is probably correct. The type system of Go isn't all that sophisticated or "advanced". But all that says is that the magic of Go isn't in the type system. The couldn't produce-it-until-the-2000s isn't in the type system. The thing that makes Go more used in the real world than Haskell isn't the sophistication of the type system. I don't see much to argue with in those claims.
    - Vampiero 6y ago
      There's a difference in mentality between people who make either argument. The "PL-elitist" crowd looks at programming languages from a computer science perspective, while the "PL-pragmatist" crowd (for lack of a better term) looks at it from a workplace perspective. At least that's how I see it. In other words, one group writes tooling and libraries; the other writes business applications using said tooling and libraries. One paradigm invites complex, highly expressive code as to minimize the chance of unforeseen errors (even if just by having a smaller codebase), and as to provide a clean and powerful interface that "does more with less". The other invites simple, highly maintainable code as to minimize the training overhead of new employees and the chance that their lack of rigor might end up accidentally introducing or reintroducing bugs. Furthermore, a simpler language means that new teams can hop onto a pre-existing project faster, because they don't have to scrutinize each LOC to the same extent. I might be wrong on any or all of this, but that's how I perceive it.
      - deleted 6y ago
        [deleted]
    - kdkeyser 6y ago
      I am not sure that my message was completely clear: my point was that despite Go having an objectively old/primitive type system, compared to modern state of the art, that does not preclude it from being a successful "production" language. The value the type system brings is, in my experience, rarely the most important factor in the success/failure of a software project. My second point was that the popularity of Go (or any language) does not mean that it is inherently a good language, where good can mean, productivity, defect rate, .... Adoption of a language depends on many things, I believe quality of the tools, availability of libraries, and good old marketing (the Google aura around Go has helped in adoption) are often more important. The effort to make an initial, crappy, proof-of-concept is in my experience often decisive for the choice of language. The cost of long term maintenance (where a good type system might bring value) is rarely considered. For Go, it also hasn't hurt that some of the core developers where being paid by Google to work on it. The metric of the "ability for mass amounts of programmers to program the computer", is indeed a very relevant one, and I think Go shines there. When reading Go code, I typically find it easy to understand what the goal of the code is. However, "to do the correct thing", is often less of a success: there are off-by-one error and corner cases that have bugs, and reimplementations of the same basic logic. If you have a lot of developers available, you simply have them fix these issues, and your Go project becomes a success. My point is, that in this scenario, the language itself is of minor importance: success is determined by the fact that you have access to a large pool of relatively cheap labor of reasonable quality (Google or VC funded startups are perfect examples). A 20 or even 50% productivity gain by having a "better" language would simply not matter for the outcome, certainly not if it takes your labor longer to get up to speed. So, in that context, compared to the alternatives, the quality of Go is relatively high. But I do think that, if during the design of Go they had taken a couple of basic concepts from ML like sum types, polymorphism, and a decent module system, they would have ended up with a language that would make the current Go look unproductive and poor quality, even in that same context. It wouldn't make a difference to Google, but it would make the life of many a developer a little bit more productive and joyful. And yes, I do know who created Go, but arguments by authority carry little weight.
  - AnimalMuppet 6y ago
    "How much a language is used" is a proxy for "how useful is the language for actually writing programs". And, really, what else do we mean by the "quality" of a programming language? If it's beautiful, but not as good for actually writing programs, then it has quality as a work of art, but less quality as a programming language.
    - goatlover 6y ago
      There's other reasons languages become popular such as platform support, marketing, what people learn in school or as a first language, and what gets you hired. Popularity does not necessarily imply any sort of superiority of a PL usage compared to others.
      - AnimalMuppet 6y ago
        I think you are going too far here. Taken at face value, your post says that for programming languages, there is zero correlation between popularity (use) and superiority (fitness for use). That implies that everyone choosing a language for a project is either stupid or ignorant (not the same thing). That may offer consolation to those who think that certain languages are the best, and who wonder why those "best" languages are used so little. But I don't think it's true. I don't think programmers are stupid, ignorant, or sheep. I think if a tool offers them advantages, they'll use it. Perhaps I should qualify: significant advantages. There is a cost to switching. The switched-to language has to be enough better to pay back the cost.
    - rowanG077 6y ago
      This is not actually true. Do you seriously believe Go would have ANY popularity now if it wasn't released and massively marketed by a BigCo?
      - Jtsummers 6y ago
        It probably would've ended up in the same place as Limbo and Alef. Interesting, useful, but of limited use and exposure to the world.
  - pjmlp 6y ago
    Actually it is worse than that, have a look at most languages designed in the 70s, like CLU and Modula-2.
    - zingplex 6y ago
      Worse in what ways?
      - pjmlp 6y ago
        Support for generics (CLI) and exceptions (both). There are other languages I can take out of the bag like Mesa/Cedar, Interlisp-D, Smalltalk-80, although they are already on the 80's borderline, which then also brings Ada, Standard ML and Object Pascal into the picture.
- bird_monster 6y ago
  Careful, here on HN you can't suggest getting things completed is a valid metric for success.
  - dang 6y ago
    Would you please stop posting supercilious dismissals of the community? You've already done this more than once, and that's a very bad sign for a new account. (Edit: Perhaps I should explain that last bit. Actual new users never comment this way—only seasoned users, and the ones who do it are usually using new accounts because they've behaved badly with earlier ones.) https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - bird_monster 6y ago
      I can try to be more direct in pointing out the obvious biases that we have on this echochamber, if you think that would spark more thoughtful debate? If you think the tone of the post was wrong, I can address that, but I don't really think that it's fair to suggest we avoid talking about this kind of thing? My other comment that you're calling a "supercilious dismissal" also received 31 upvotes and some interesting responses, fwiw.
      - dang 6y ago
        What people call "obvious biases" are typically what they themselves are choosing to select out of the statistical cloud of posts that get made here. The bias at work in making such a selection is one's own, but we project it onto the community, and then create a superior image of ourselves by posturing above it, which is what I mean by supercilious. This is a drama between oneself and oneself, which has nothing to do with real conversation. It's a way of changing the subject to oneself. To be fair, you're hardly the only one doing it; it's quite common, but I have to tell you that it tends to be low-quality commenters who do this. It frequently comes with labels like "echochamber" and "groupthink", which are also ways of elevating oneself as the noble freethinker standing against the mob, or some such image. Actual noble freethinkers never behave like this, so the whole thing is incongruent—it's simply a way of flattering oneself, which (ironically, because we all feel so unique) is one of the most repetitive and tedious things that people do. That's why we shouldn't do it on a site that's trying to have interesting conversation. Another angle: people seem to posture above the community when they feel like they need to defend themselves against it. Presumably they want to defend themselves against some claim of i-am-very-smartness that they feel is emanating from the community, so they puff themselves up and put the community down by way of compensation. In reality, though, no one is making such a claim. HN isn't making such a claim—HN isn't a person to begin with—and certainly the people running HN are making no such claim. It rather arises in the psyche of some readers, for whatever internal reasons. The internet can be crazy-making that way.
- przemo_li 6y ago
  You really have to stop assuming "intellectual superiority" when people talk about more advanced / less advanced stuff. Go have limited capabilities type system. C have limited capabilities type system. Both are quite successful. If talking about C I didn't shown "intellectual superiority", maybe it would be incorrect label if I where to talk about Go?
  - eru 6y ago
    Go is just a lot of missed opportunities, that they could have taken without making the language any more complicated.
- eru 6y ago
  In what sense has Go outshined anything?

JulianMorrison 6y ago

I was amused at that. It's clear this author is not Go's constituency. You cannot use types to ensure consistency in Go, you just have to write the algorithm correctly. But Go fronts the algorithm and keeps the noise around it to a minimum. They are opposed but equivalent strategies.

eru 6y ago
You still have to get the algorithms right in eg Haskell. It's just that in Haskell you have to write fewer tests to be sure you did it right, because for many kinds of mistakes you could have made, the compiler can yell at you. The other advantage of nicer types is that they serve as part of the documentation. Exactly because the types can constraint the behaviour of implementations more than in Go. So the reader can make more valid assumptions from the type alone. Hoogle uses those types to give you a truly extra-ordinary way to search the Haskell libraries via types. That approach would be almost useless in Go, and you have to fall back to searching via keywords etc only.

steveklabnik 6y ago

Rust was initially implemented in OCaml, even. But that said, it gained a lot of more Haskell like features later on; we ended up with type classes, not ML modules, for example. EDIT: also, strictly speaking, Rust doesn't use Hindley-Milner, and we don't have parametric polymorphism.

veets 6y ago
Can you clarify why you don't think Rust has parametric polymorphism? struct Person<T> { age: T, } Is parametric polymorphism and valid Rust.
- steveklabnik 6y ago
  Just because some bounds are parametric does not mean that all of them are; specialization violates parametricity, for example. While that's not in Rust proper yet, it did require making sure that dropck could handle it, for example, and the intention is to ship it. There's also more minor things like https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179973108 https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179...
  - Rusky 6y ago
    In a sense even things like `TypeId::of` or `mem::size_of` violate parametricity.
  - veets 6y ago
    I don't doubt you know more about Rust than I do, but this seems pedantic to me. Kind of like correcting someone for pronouncing forte as "for-TAY" instead of "fort" or telling someone "well technically you don't actually touch _anything_ because of the electrostatic force." If you ask all the developers out there to describe parametric and ad-hoc polymorphism I think a vast majority would give the example of a type parameter (e.g., Java generics or C++ templates) for parametric polymorphism and Java interfaces or Haskell's classes for ad-hoc polymorphism. I can even quote directly from Pierce (Types and Programming Languages): > Parametric polymorphism, the topic of this chapter, allows a single piece of code to be typed "generically," using variables in place of actual types, and then instantiated with particular types as needed. Parametric definitions are uniform: all of their instances behave the same. I think Rust and the aforementioned languages fit this definition. Outside of a specific compiler issue, claiming otherwise seems to only confuse the issue, especially for those just casually reading and not familiar with programming language theory.

cgh 6y ago

Yes, this was my favourite line: > However, in 2020, the premier system’s language is surely Rust. Yesterday I was speaking with a friend who runs a small company doing contracted embedded programming (the embedded OS is often Linux but often not) and he'd never even heard of Rust. Maybe it's a little lower level than what's meant by "systems" here but still, the article's statement is just delusional.

Jtsummers 6y ago
The largest vocal community today for a systems language (meaning down to the OS level with strong determinism guarantees, not the redefinition to make Go a systems language meaning server systems) is definitely Rust. But in practice, no one is using it because their systems predate it, don't have compilers for it, or they simply can't use it due to their problem domain (it has an insufficient history, they can't contract support with the compiler team for it, or whatever). I can go to Green Hills and get a contract that guarantees their compiler will be available and supported for my target platform for the next 10+ years. Rust is still a moving target with a single implementation, and no (present) way to get the guarantees needed for the embedded domains I've been involved in. I'd like to see Rust experimented with there, but it won't be the "go to" language for quite some time.
- steveklabnik 6y ago
  Fun story: here's a recent talk by someone at Green Hills, talking about experiences giving Rust a try https://www.youtube.com/watch?v=G5A7rSPYpb8 https://www.youtube.com/watch?v=G5A7rSPYpb8
  - Jtsummers 6y ago
    Thanks for the link, I'll check it out later.
  - deleted 6y ago
    [deleted]
- dimitrios1 6y ago

rowanG077 6y ago

How is Go the premier cloud computing language? I would say that crown goes to Python. I almost never encounter Go when working with cloud computing.

sweeneyrod 6y ago

What does "premier cloud language" mean?

eru 6y ago

Are you saying Go is the 'premier system's language'?