7 ms·

If O(3) people want to design a new language, how should they incorporate the "optimizations that other languages have had for 30 years" into that language that

If O(3) people want to design a new language, how should they incorporate the "optimizations that other languages have had for 30 years" into that language that will satisfy the internet's peanut gallery? (alternatively) Go is the most successful language released in the last 20 to 30 years, so if this is meant as a critique I can't see how it's valid.

staticassertion 4y ago
Using existing compiler toolchains, obviously. In 11 years I think it's interesting to see how that has panned out. Go is very popular for a relatively new languages, yes.
- pjmlp 4y ago
  Meaning keeping C and C++ alive, if nothing else as the languages those compiler toolchains are written on.
  - staticassertion 4y ago
    Does anyone think that C and C++ are going to die? Anyway, I'm actually glad that Go went down this path exactly because it allows us to look at the decision and see the costs. I'm very curious to see if we do hit that S curve, as another poster mentioned.
    - pjmlp 4y ago
      Not on our lifetime, but reducing the use cases that require their uses helps. This is also why I follow GraalVM since the days it used to be MaximeVM.
      - staticassertion 4y ago
        I personally have no issue with C++ being used for compilers, but to each their own.
        pjmlp 4y ago
        Depends on how one stands in regards to secure code. I love C++, but secure like the ALGOL linage it will never be, no matter how many fixes we throw at it, because that C copy-paste compatibility layer is never going to be thrown away.
        staticassertion 4y ago
        I'm quite fond of secure code but attackers don't really exploit memory unsafety in compilers as they're not often in a position to or, if they are, there are much simpler ways to execute code.
        pjmlp 4y ago
        Except compilers aren't used in isolation, if one writes the compiler toolchain in C++, chances are other system critical components are also written in C++, if nothing else for the comfort of single language use. Security must be applied end to end, and not pontual.
    - Shorel 4y ago
      Ten years ago, that was the feeling. C++ was perceived as a dead end. Everything was going to be Java or C#. But it didn't die. And today there are more C++ jobs available than a decade ago. In contrast, today there are some new languages that can actually be good contenders for C++. My personal favourite is Dlang.
      - pjmlp 4y ago
        Kind of true, depends where you look at. Compilers, HPC, GPGPU, game engines, OS drivers, C++ is probaly the king of those domains. Distributed computing, GUI frameworks, mobile apps, CNCF, other contenders rule the day.
- eikenberry 4y ago
  Yep... and it would have likely just fizzled out as all the existing toolchains have a terrible UX and that is one of Go's best points.
msbarnett 4y ago
> If O(3) people want to design a new language, how should they incorporate the "optimizations that other languages have had for 30 years" into that language that will satisfy the internet's peanut gallery? Generally this is done by building the language on an existing compiler backend, and the ability to do this is in fact why the backend/frontend distinction in compilers was created to begin with. > Go is the most successful language released in the last 20 to 30 years, so if this is meant as a critique I can't see how it's valid. False dichotomy. A language can both be popular and have left very obvious optimizations on the table for years.
- kjksf 4y ago
  > Generally this is done by building the language on an existing compiler backend, Go was implemented on top of existing compiler backend. It just wasn't LLVM. Go was based on a C compiler suite from Plan 9. See https://9p.io/sys/doc/compiler.html https://9p.io/sys/doc/compiler.html and https://github.com/huangguiyang/plan9-cc https://github.com/huangguiyang/plan9-cc Those compiler suite was very portable ("The compilers are relatively portable, requiring but a couple of weeks’ work to produce a compiler for a different computer.") which is a strength Go inherited from get go. Also 2/3 of Go designers (Pike, Thompson) were intimately familiar with that code base by the virtue of having written it in the first place. (some) people just get twisted that Go didn't pick LLVM because it had better optimizations as if in engineering you just look at one positive and ignore all the negatives. For LLVM the list of negatives is huge: slow compilation, gigantic code base that would take ages to learn and contribute changes, architecture that would preclude some of the optimizations in Go (Go has a very smart and fast linker where using LLVM would forced them to just use the LLVM linker, segmented stacks not possible, GC not possible) etc. Just to put things in perspective: just implementing segmented stacks LLVM would probably require more man hours than the all the compiler work in Go 1. And would realistically require forking LLVM because why would Apple devs with bonuses tied to shipping what Apple needed care about some new language from 3 guys from Google.
shakow 4y ago
> how should they incorporate the "optimizations that other languages have had for 30 years" Leverage an already existing compiler backend, typically GCC or LLVM – just like Julia, Rust, or Swift. Or, similarly, target an existing, battle-tested VM – like e.g. Elixir, Kotlin, Clojure, or F#. > Go is the most successful language released in the last 20 to 30 years Python? Ruby? Javascript? Java? C#? TypeScript? PHP? R? Visual Basic?
- preseinger 4y ago
  > Leverage an already existing compiler backend, typically GCC or LLVM – just like Julia, Rust, or Swift. > > Or, similarly, target an existing, battle-tested VM – like e.g. Elixir, Kotlin, Clojure, or F#. Each of these options come with enormous, unavoidable, and ultimately unnecessary baggage derived from their substantial histories. They simply don't, can't, represent the full spectrum of acceptable foundations for new language development.
- eikenberry 4y ago
  GCC and LLVM both have terrible UX with their ridiculous compilation times. Go wanted good developer UX so that ruled those out. None of those VMs would allow for the native compilation that was another design goal. They had specific design goals which nothing out there met.
  - shakow 4y ago
    > GCC and LLVM both have terrible UX with their ridiculous compilation times. And so will go if it implements the optimizations they implement. GCC and LLVM are not putting sleep(10) everywhere just for the sake of longer compilation times.
    - eikenberry 4y ago
      Then it won't do those optimizations. Fast compiler times are more important than being the fastest at runtime. It has to be "fast enough" and given the adoption I'd say the consensus is that it already is. More optimizations are all gravy at this point.
coliveira 4y ago
> most successful language released in the last 20 to 30 years You must be living in an alternate world...
- throwaway17_17 4y ago
  Can you explain why you think the claim is incorrect. I would think it at least plausible. A huge portion of the languages in common use are all over 20 years from introduction. So Go is certain to be in the top for language introduced after 2002. Or at least I would think.
  - eikenberry 4y ago
    If you had said 20 years you'd probably have been right. But going back 30 includes Python which is still WAY bigger than Go.
    - throwaway17_17 4y ago
      Python was released Feb. 20, 1991. I checked that before I posted. And I am not the original poster and did limit my comment to 20 years. But, I did forget Java in the 30 year category.
      - eikenberry 4y ago
        IMO when you say "20-30" that indicates an approximation for which 31 is still qualifying. But technically you are correct (the best kind).
  - coliveira 4y ago
    Even if you had said only the last 15 years, that would still include languages like Clojure, Rust, Typescript, Swift, and Julia. But from 20 to 30 years you start to get into the league of: C# and Java, R, Lua, PHP, Ruby... In other words, there is no way you can prove your assertion.
    - 4y ago

staticassertion 4y ago

Using existing compiler toolchains, obviously. In 11 years I think it's interesting to see how that has panned out. Go is very popular for a relatively new languages, yes.

pjmlp 4y ago
Meaning keeping C and C++ alive, if nothing else as the languages those compiler toolchains are written on.
- staticassertion 4y ago
  Does anyone think that C and C++ are going to die? Anyway, I'm actually glad that Go went down this path exactly because it allows us to look at the decision and see the costs. I'm very curious to see if we do hit that S curve, as another poster mentioned.
  - pjmlp 4y ago
    Not on our lifetime, but reducing the use cases that require their uses helps. This is also why I follow GraalVM since the days it used to be MaximeVM.
    - staticassertion 4y ago
      I personally have no issue with C++ being used for compilers, but to each their own.
      - pjmlp 4y ago
        Depends on how one stands in regards to secure code. I love C++, but secure like the ALGOL linage it will never be, no matter how many fixes we throw at it, because that C copy-paste compatibility layer is never going to be thrown away.
        staticassertion 4y ago
        I'm quite fond of secure code but attackers don't really exploit memory unsafety in compilers as they're not often in a position to or, if they are, there are much simpler ways to execute code.
        pjmlp 4y ago
        Except compilers aren't used in isolation, if one writes the compiler toolchain in C++, chances are other system critical components are also written in C++, if nothing else for the comfort of single language use. Security must be applied end to end, and not pontual.
  - Shorel 4y ago
    Ten years ago, that was the feeling. C++ was perceived as a dead end. Everything was going to be Java or C#. But it didn't die. And today there are more C++ jobs available than a decade ago. In contrast, today there are some new languages that can actually be good contenders for C++. My personal favourite is Dlang.
    - pjmlp 4y ago
      Kind of true, depends where you look at. Compilers, HPC, GPGPU, game engines, OS drivers, C++ is probaly the king of those domains. Distributed computing, GUI frameworks, mobile apps, CNCF, other contenders rule the day.
eikenberry 4y ago
Yep... and it would have likely just fizzled out as all the existing toolchains have a terrible UX and that is one of Go's best points.

msbarnett 4y ago

> If O(3) people want to design a new language, how should they incorporate the "optimizations that other languages have had for 30 years" into that language that will satisfy the internet's peanut gallery? Generally this is done by building the language on an existing compiler backend, and the ability to do this is in fact why the backend/frontend distinction in compilers was created to begin with. > Go is the most successful language released in the last 20 to 30 years, so if this is meant as a critique I can't see how it's valid. False dichotomy. A language can both be popular and have left very obvious optimizations on the table for years.

kjksf 4y ago
> Generally this is done by building the language on an existing compiler backend, Go was implemented on top of existing compiler backend. It just wasn't LLVM. Go was based on a C compiler suite from Plan 9. See https://9p.io/sys/doc/compiler.html https://9p.io/sys/doc/compiler.html and https://github.com/huangguiyang/plan9-cc https://github.com/huangguiyang/plan9-cc Those compiler suite was very portable ("The compilers are relatively portable, requiring but a couple of weeks’ work to produce a compiler for a different computer.") which is a strength Go inherited from get go. Also 2/3 of Go designers (Pike, Thompson) were intimately familiar with that code base by the virtue of having written it in the first place. (some) people just get twisted that Go didn't pick LLVM because it had better optimizations as if in engineering you just look at one positive and ignore all the negatives. For LLVM the list of negatives is huge: slow compilation, gigantic code base that would take ages to learn and contribute changes, architecture that would preclude some of the optimizations in Go (Go has a very smart and fast linker where using LLVM would forced them to just use the LLVM linker, segmented stacks not possible, GC not possible) etc. Just to put things in perspective: just implementing segmented stacks LLVM would probably require more man hours than the all the compiler work in Go 1. And would realistically require forking LLVM because why would Apple devs with bonuses tied to shipping what Apple needed care about some new language from 3 guys from Google.

shakow 4y ago

> how should they incorporate the "optimizations that other languages have had for 30 years" Leverage an already existing compiler backend, typically GCC or LLVM – just like Julia, Rust, or Swift. Or, similarly, target an existing, battle-tested VM – like e.g. Elixir, Kotlin, Clojure, or F#. > Go is the most successful language released in the last 20 to 30 years Python? Ruby? Javascript? Java? C#? TypeScript? PHP? R? Visual Basic?

preseinger 4y ago
> Leverage an already existing compiler backend, typically GCC or LLVM – just like Julia, Rust, or Swift. > > Or, similarly, target an existing, battle-tested VM – like e.g. Elixir, Kotlin, Clojure, or F#. Each of these options come with enormous, unavoidable, and ultimately unnecessary baggage derived from their substantial histories. They simply don't, can't, represent the full spectrum of acceptable foundations for new language development.
eikenberry 4y ago
GCC and LLVM both have terrible UX with their ridiculous compilation times. Go wanted good developer UX so that ruled those out. None of those VMs would allow for the native compilation that was another design goal. They had specific design goals which nothing out there met.
- shakow 4y ago
  > GCC and LLVM both have terrible UX with their ridiculous compilation times. And so will go if it implements the optimizations they implement. GCC and LLVM are not putting sleep(10) everywhere just for the sake of longer compilation times.
  - eikenberry 4y ago
    Then it won't do those optimizations. Fast compiler times are more important than being the fastest at runtime. It has to be "fast enough" and given the adoption I'd say the consensus is that it already is. More optimizations are all gravy at this point.

coliveira 4y ago

> most successful language released in the last 20 to 30 years You must be living in an alternate world...

throwaway17_17 4y ago
Can you explain why you think the claim is incorrect. I would think it at least plausible. A huge portion of the languages in common use are all over 20 years from introduction. So Go is certain to be in the top for language introduced after 2002. Or at least I would think.
- eikenberry 4y ago
  If you had said 20 years you'd probably have been right. But going back 30 includes Python which is still WAY bigger than Go.
  - throwaway17_17 4y ago
    Python was released Feb. 20, 1991. I checked that before I posted. And I am not the original poster and did limit my comment to 20 years. But, I did forget Java in the 30 year category.
    - eikenberry 4y ago
      IMO when you say "20-30" that indicates an approximation for which 31 is still qualifying. But technically you are correct (the best kind).
- coliveira 4y ago
  Even if you had said only the last 15 years, that would still include languages like Clojure, Rust, Typescript, Swift, and Julia. But from 20 to 30 years you start to get into the league of: C# and Java, R, Lua, PHP, Ruby... In other words, there is no way you can prove your assertion.
  - 4y ago