121–130 of 146 posts
Earlier quoted context omitted.
I said, I avoid, I don't love, I was talking about preference. And I'll state: Most of these are written mostly like I say. Please find serious counter-examples.
A cursory glance to the ones that are publicly available shows otherwise.
Earlier quoted context omitted.
A cursory glance to the ones that are publicly available shows otherwise.
You must be talking about Linux, the BSDs, sqlite, postgres, gcc, the mold linker, or let's take some new kids on the block: raddebugger, FilePilot, TaskSlinger?
Living in the past? GCC has long adopted C++, last time it compiled with a pure C compiler was back in 2011 thereabouts, not cross-checking the exact year.
A few trees don't make a forest.
Earlier quoted context omitted.
You must be talking about Linux, the BSDs, sqlite, postgres, gcc, the mold linker, or let's take some new kids on the block: raddebugger, FilePilot, TaskSlinger?
I am for example talking about LLVM and GCC, used to compile all those examples. Living in the past? GCC has long adopted C++, last time it compiled with a pure C compiler was back in 2011 thereabouts, not cross-checking the exact year. A few trees don't make a forest.
Earlier quoted context omitted.
I am for example talking about LLVM and GCC, used to compile all those examples. Living in the past? GCC has long adopted C++, last time it compiled with a pure C compiler was back in 2011 thereabouts, not cross-checking the exact year. A few trees don't make a forest.
Actually care to open GCC and see what I mean? Check the newest commits and see what they do. Maybe you're living in a dream world where some magic language features do the work for you. Meanwhile people out in the field do actual work by just pushing bytes at the low level.
> Necessary to bootstrap GCC. GCC 5.4 or newer has sufficient support for used C++14 features.
> Versions of GCC prior to 15 allow bootstrapping with an ISO C++11 compiler, versions prior to 10.5 allow bootstrapping with an ISO C++98 compiler, and versions prior to 4.8 allow bootstrapping with an ISO C89 compiler.
> If you need to build an intermediate version of GCC in order to bootstrap current GCC, consider GCC 9.5: it can build the current D compiler, and was also the version that declared C++17 support stable.
https://gcc.gnu.org/install/prerequisites.html
So yeah, if you want to enjoy GCC 4.8...
Now I can bother to show exactly each source file, but Github search is relatively easy to use on the mirror source code.
I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…
Julia is another contender. Julia code can be as performant as C++ code, but Julia code may be even more elegant than C++. Even without accounting for Julia's metaprogramming features, the compile-time expressiveness is top-notch. It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptim…
But not at the same time
Earlier quoted context omitted.
Actually care to open GCC and see what I mean? Check the newest commits and see what they do. Maybe you're living in a dream world where some magic language features do the work for you. Meanwhile people out in the field do actual work by just pushing bytes at the low level.
To use the developers own words, > Necessary to bootstrap GCC. GCC 5.4 or newer has sufficient support for used C++14 features. > Versions of GCC prior to 15 allow bootstrapping with an ISO C++11 compiler, versions prior to 10.5 allow bootstrapping with an ISO C++98 compiler, and versions prior to 4.8 allow bootstrapping with an ISO C89 compiler. > If you need to build an intermediate version of GCC in order to boots…
I'm saying that most of features like templates, constexpr, reflection etc. don't scale well to serious use, as a broad statement. I fully acknowledge this is not a black and white situation. But I encourage you to look at actual pedestrian code, it's mostly not abstracted fluffy magic template code at all. It's pushing individual bytes with totally basic means (mostly C code). Why? Because code using these fluffy features is terribly hard to maintain. Templates lock you in their own language world with incredibly bad syntax and bad ergonomics, in short: it's a pain!
Personally I think even C++ classes (i.e. 1980's C++) are unusable because they bifurcate syntax/semantics needlessly and add implicit invisible scope. But I acknowledge it's somewhat possible to program with classes, and some people like to lean on RAII heavily. I mostly do not like to use RAII, and I've tried many times, I think it sucks for non-toy programming, even though obviously the idea is intuitive.
I find the real issue with Rust is the compiler performance. I decided to use it for a project, and frankly I have huge regrets now that it's grown big enough. It literally takes over a minute to compile on my M1 laptop. I just don't understand how people find this sort of thing normal. If you implement a feature, and then you want to see it in action, the feedback loop for that is insanely slow. It's incredibly jarr…
See languages like D, Delphi, Ada, C++ (with modules/libraries, REPLs like CINT), Haskell (GHCi), OCaml (REPL) for similar complexity levels, and faster compile times. It is a matter of tooling, eventually they will get there I guess.
Earlier quoted context omitted.
See languages like D, Delphi, Ada, C++ (with modules/libraries, REPLs like CINT), Haskell (GHCi), OCaml (REPL) for similar complexity levels, and faster compile times. It is a matter of tooling, eventually they will get there I guess.
There's a tooling problem in the compiler with regards to parallelism, but the real problem is that the Rust ecosystem makes use of intense amounts of code generation features, like serdes, which generates a huge amount of invisible code so that you can serialize and deserialize JSON at speeds that may or may not be practically relevant, but whose impact on compile times is guaranteed.
However as language nerd, I still think there is a possible way out of it.
Earlier quoted context omitted.
>> The caveat is that modern C++ is notably more performant than C and by implication Rust. Please provide proof for this outrageous statement.
Is it outrageous because "performant" is kind of a vague term. Does it mean... Fast? GPU-friendly? Scalable? Energy-efficient? Reliable? User-friendly? Maintainable? For what kind of applications? Modern Fortran has a lot to offer for scientific and numeric computation - easier to learn than C++, and easier to optimize in many cases. Scales from small systems to supercomputers, and there is even CUDA Fortran.
Nobody uses "performant" to refer to any of those. It usually means either high throughput, or some aggregate of high throughput + low latency + low memory usage.
Earlier quoted context omitted.
> modern C++ is notably more performant than C and by implication Rust I don't think this holds. Rust has the same facilities which C++ has. Rust's metaprogramming capabilities are now on par with C++ (they weren't always). Rust has a similar generics implementation which allows it to do what C++ does in terms of method dispatch and generation. And now Rust has pretty much the same compile time constant generation ca…
Reflection, Rust community did a very good job driving away the person that cared to do that work, to the point he went back to C and C++ ISO comittees. Several features on C23 were done thanks to his work. Also compile time execution is much more rich in C++ than Rust, regardling language features and standard library that can be used at compile time. Naturally none of the languages is standing still, and they will…