Go programs compile in less than a second, or several seconds for huge projects, where idiomatic Go gets you within the same order of magnitude to that of C(++), with some memory overhead. Concurrency is first class, GC pauses exist but are seldom an issue.
Idiomatic Ruby runs several orders of magnitude slower, with a huge memory overhead, and is rife with runtime gymnastics. Concurrency is an expensive hack, with stop-the-world GC.
Also, I've never heard of anyone using assembly for performance optimisations. It would never happen where Go in commonly used (server programming), maybe if you're doing graphics or something nonstandard?
It's in the standard library. It's also how you write parsers and formatters with acceptable performance if you don't have SIMD intrinsics.
It's a lang to ship MVPs quickly without much thought & cheaper devs - not a high perf one.
Past that, you either call out to C via FFI or give up and rewrite in C/C++/Rust. Nobody really bothers with the asm.
This is purely an optimization issue and the article compares apples to oranges for clicks.
I really would get onboard with an alternative ISA that was more in line with actual architectural features of modern processors and I often wonder why we could not have an extra compilation (jit or aot) step from x86 to some other format. But the trend seems to be going the opposite direction for all the large scale processor manufacturer/designers toward a more abstracted interface at the lowest level.
I’ve seen various comments that basically boil down to “you can’t change the ISA because then C/C++/Rust programs would loose performance in benchmarks in the short term”, and this resistance only reinforces maintaining current trends. So… what are you assuming happens that prompts the shift toward a better way to harness computing power?
I am not particularly qualified to try and design a better ISA, I just know there are some things I would like the option to control at some times (or at least I imagine I would). A lot of the list above is about exposing more of the architecture to user control as a general principle. However, I’d rather see some areas of hardware design change to facilitate something other than coding paradigms and practices that stretch back nearly 40 years. Chisnall’s ‘C is not a Low Level Language’ article discusses several architectural directions I would like to see happen, but also talks about how as long as the ISA remains the same moving to new programming styles/philosophies continues to be a difficult proposition.
The world has mostly not adopted existing tools for writing 10-100x faster software (simd, huge pages, computing both branches then using a blend or cmov when this is sufficiently cheap, software prefetching, collection APIs that support bulk updates so that they can use all of these things instead of adding totally unnecessary dependency chains to the resulting program, etc.) so i'm not optimistic about things getting better if CPUs grow a thousand times more memory bandwidth and cores and begin to support very wide scatter/gather like GPUs.
Other than that they are very similar
Golang has a GC and gives you much less control over memory layout than any of the other languages you mentioned. It also has a very different concurrency model, which will vastly change the performance characteristics of multithreaded code.
Rust is limited to llvm, while C can be compiled with many other compilers - some of which produce better code in many cases. (Eg icc)
Rust has much better noalias analysis - which allows the compiler to make optimizations that aren’t available in general purpose C or C++ code. (Since nobody adds noalias to all their variables in C, for a variety of reasons).
Unlike the others, C doesn’t support monomorphization (without disgusting macro tricks). Monomorphization cuts both ways with performance - since it bloats executables (and thus hurts the branch predictor and cache) while generating more efficient code.
These languages aren’t the same. There’s lots of reasons they will perform differently both at the limits of what we can optimize and in the average case of everyday code. It’s wild that you would consider them to all be the same.
There's a rust front-end for gcc as well.
Doesn’t the borrow checker also track when things fall out of scope, and thus control when Drop is called?
The drop is there for stuff that you can't just release the memory for, such as closing files and connections.
Find the scope you can refer to the variable in, i.e. the curly brackets it is contained in. That variable is dropped right before the closing curly bracket. Things are dropped in reverse order of creation.
(Similar rules apply to dropping temporaries)
Only if the code design in C/C++/Rust/Golang is bad.