3 ms·
Why does it need to be the best in one single metric when it can be great in many? It is an order of magnitude faster than Python. So it is well suited for per
by vimsee 3y ago
Why does it need to be the best in one single metric when it can be great in many?
It is an order of magnitude faster than Python.
So it is well suited for performance in many cases.
It is a lot easier to pick up than C/C++.
So it is well suited for smaller programs.
I can see Go as a very good middle-ground.
- benterix 3y ago> It is a lot easier to pick up than C/C++. I would say, "it is a lot easier to pick up than C++" as the language specification is much smaller. I wouldn't be so sure about the comparison to C, though.
- usrbinbash 3y agoThe fact that Go doesn't have C's macros alone already makes it a lot simpler. And please don't get me started on writing concurrent code in C.
- EnergyAmy 3y ago`//go:generate` is far worse than C's macros
- saturn_vk 3y agoThat's just a glorified make rule. There's nothing inherently hidden or complex that it generates, unlike macros
- majewsky 3y agoI have written Go professionally for close to 10 years. The only time I encountered go:generate is in yacc parsers deep within libraries. A regular Go developer might go for years without realizing that it even exists. Compare this to C macros.
- shrimp_emoji 3y ago> It is a lot easier to pick up than C/C++. That's why corporations like Google invent "middle-ground" languages. Go from Google Java from Oracle C# from Microsoft These companies need some performance, but they can't hire enough C/C++/Rust devs (not enough exist). They're flush with JS/Python devs, but those languages are too slow. So they invent these abominable "middle-level" languages, with their insane bloat. For myself, I'm not interested in mediocrity to serve corporate interests, so I don't touch them. :p Extremes only: Python and C; Ruby and Rust; JS and C++.
- hobos_delight 3y ago> Java from Oracle Oracle acquired Java with Sun Microsystems, it was originally designed for embedded systems and the dream of “write once, run everywhere”. The idea of a “hardware JVM” always fascinated me, I seem to recall some parallax microcontrollers that could run a subset of jvm bytecode back in the 90s, but never actually got to play with them.