[flagged]
I don't buy this. Rust is a lot easier to make more performant than C++ and doesn't really trail behind C in anything but .text size last time I looked. Considering you can easily write C-like Rust that ends up in the same LLVM stack as Clang (more or less) I just don't think this is true outside of some very specific contexts.
I have never seen evidence of this in the wild. C++ is still significantly faster than Rust in practice when doing performance-sensitive parallel development in the two languages.
The reason for the performance gap is mostly understood. Rust's codegen is currently somewhat worse for a variety of reasons. Rust's much weaker compile-time metaprogramming features make some optimizations impractical in the language that are easy in C++. Culturally, "unsafe" minimization in Rust pessimizes code architecture.
Rust can get pretty close to C++ but it often requires writing some very ugly Rust.
anyway this is especially funny because C++ without compiler-specific pragmas/flags is also a bit mechanistically unsympathetic to the hardware, the whole strict-aliasing saga, you turn it on then you'll suffer with UB and has completely different semantics than hw, you turn it off and you have to manually SSA your code to avoid completely unnecessary loads when accessing fields more than once, the STL is slow, idiomatic C++ often allocates like crazy...
then people saw that and decided that we want more of that, so Rust was born;) (yes I'm being sarcastic here)
I guess the reason C++ fares better traditionally is because even though the actual specification is bonkers, you can mostly coax the compiler into "doing the right thing" as long as you don't mind losing portability and ugly stuff...
But, Rust does indeed embedded extra code for much of the functionality that it adds ontop of what C/C++ has.
This obviously has a performance hit. Might not be observable on a desktop application but it will be evident on server applications.
I don’t think you share the same understanding of functional as TFA uses.
Not functional as in “working”/functioning. Functional is meant here as in functional programming, the paradigm.
And, if all you're doing is taking material from real life and uploading into computers, then you're not modifying state at all.
I think many equate FP with referential transparency, garbage collection, first class functions/closures. But usually it’s a sort of mix of all the above or opt-in. Standard ML makes it easy to mutate state for instance.
C is by no means a functional language. It is perhaps the definition of imperative; the poster child.
Regardless of the language used!
> C in indeed a functional language […]
… which it isn’t, it’s imperative ¯\_(ツ)_/¯
Probably depends on at what level you see things. If you visit and probably live in Japan, then you develop the concept of 'cryptocurrency'. You then subsequently develop intellectual property around the 'concept' of 'cryptocurrency'.
Is this really 'imperative' programming? I'd say not but depending on at what level you see things, then it could be.
At project level, then it's purely functional.
Calling C a functional language because you’re able to manually emulate one feature that functional languages give you automatically, is like claiming C is a garbage collected language because ‘at the project level’ you remember to call free().
I can’t follow or understand your japan/crypto analogy, I’m sorry.