4 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 th

> 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.

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.