The Go Compiler Needs to Be Smarter
lemire.me
The Go Compiler Needs to Be Smarter
1–10 of 119 posts
Re: The Go Compiler Needs to Be Smarter
#2This[0] PR should fix some of it is my understanding but will have to wait and see -- not playing with /tip!
[0] https://github.com/golang/go/commit/fff7509d472778cae5e652db...
Re: The Go Compiler Needs to Be Smarter
#3Sure, if your goal is to build a compiler that outputs the fastest possible code.
If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation.
Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't existed among actual C implementations (outside of maybe Plan 9) for decades now. It's yet more suckless idiocy: sacrifice everything, including utility and friendliness to end users, to buy "simplicity" for hackers. No wonder the suckless folks love Go so much.
Re: The Go Compiler Needs to Be Smarter
#4Sure, if your goal is to build a compiler that outputs the fastest possible code. If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation. Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't exist…
That seems rather unwarranted attempt at vilification of the language, worded in an odd way: if something sucks, it's bad, so suckless would actually be positive?
But why? What's Go done to you? A few if err != nil { ... } statements too many?
Re: The Go Compiler Needs to Be Smarter
#5Sure, if your goal is to build a compiler that outputs the fastest possible code. If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation. Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't exist…
That seems rather unwarranted attempt at vilification of the language, worded in an odd way: if something sucks, it's bad, so suckless would actually be positive? But why? What's Go done to you? A few if err != nil { ... } statements too many?
Look up suckless. It has a specific meaning and history.
Re: The Go Compiler Needs to Be Smarter
#6Earlier quoted context omitted.
That seems rather unwarranted attempt at vilification of the language, worded in an odd way: if something sucks, it's bad, so suckless would actually be positive? But why? What's Go done to you? A few if err != nil { ... } statements too many?
Look up suckless. It has a specific meaning and history.
Indeed. suckless refers to https://suckless.org/philosophy/
Re: The Go Compiler Needs to Be Smarter
#7It will be a whole lot smarter on June 8th at 7am pacific, https://www.youtube.com/watch?v=Dq0WFigax_c
Re: The Go Compiler Needs to Be Smarter
#8Sure, if your goal is to build a compiler that outputs the fastest possible code. If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation. Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't exist…
Suckless is promoting C99 and disregards anything with a GC.
Re: The Go Compiler Needs to Be Smarter
#9This is a very interesting at a time when we're seeing what we can replace C++ with.
(yes, rusticles, I know rust exists)
Re: The Go Compiler Needs to Be Smarter
#10It will be a whole lot smarter on June 8th at 7am pacific, https://www.youtube.com/watch?v=Dq0WFigax_c
I skimmed over the paper once. I could not get all of it but whatever I understood seemed nice. Hopefully it can be implemented to full(not subset) golang and I hope it can be implemented soon. I started learning golang recently. I already have few places of `interface{}`. Having done lot of Java and a little Rust, I appreciate the simplicity and quick compile of golang, but I do feel it much more verbose than both. If generics can be implemented nicely, it would be a huge boon to golang's usability.