My (Herb Sutter's) C++ Now 2023 talk is online: “A TypeScript for C++”
herbsutter.com
herbsutter.com
For whatever reason, Herb Sutter decided to ignore this language on the presentation.
This is the only one with the syntax based on C++, incrementally changing the features via #pragma settings.
"Circle Fixes Defects, Makes C++ Language Safer & More Productive"
https://www.youtube.com/watch?v=x7fxeNqSK2k
"Circle Evolves C++"
The best outcome the Circle author can hope for (and this is likely the purpose of the project) is that some company either buys it, or hires him to work on Circle full time. Circle benefits only one guy, it doesn't benefit the C++ community.
As a life long C++ native Software Engineer, cppfront/cpp2 is one of the few efforts in c++ that interest me these days.
I am also the hiring manager for our teams, and it's shocking that applicants that proudly include c++20 on their resumes but can not answer the intentionally open-ended question: Tell me about std::move().
IMO: If c++ is to thrive, it is in desperate need of the "10x simpler and safer" vision that is at the core of cppfront.
std::move is nothing but a cast - but it means that means that for every new class, we should be actively considering if a move constructor is appropriate for that class. The consequences of a missing move constructor would be calling the copy constructor... pretty dry stuff I agree. about as exciting as discussing pass by value or pass by reference... but for certain domains of programming (embedded), just as critical. Nicolai M. Josuttis , a 20 year veteran of the standards committee, can be quoted as saying "Move semantics, introduced with C++11, has become a hallmark of modern C++ programming." [1]
But if we take a step back and consider the broader picture I think of "the average language proficiency of the team" as being a very real pressure. If the complexity of the code base creeps above the average proficiency of the team, the health of the code base struggles.
So, here's the thing. As a hiring manager for embedded products, If I can't get applicants that know about std::move(), then the scope of the c++ language has outpaced it's own talent pool, and something like cppfront becomes all the more critical.
This is a result of backwards compatibility. Features can only be added, not removed (or at least only removed if nobody is using them, like export templates and GC).
As a result C++ hoovered many different types of users over the years who all had their own idea of what they wanted from the language.
For a C++ programmer, navigating this by learning and adapting your skill set for a new project is simply a part of the job. You’ll always be able to find missing spots in even the most grizzled C++ vet’s knowledge.
C++ has been gradually back-porting Rust features, but it provides help only for carefully written new code. You can still get raw pointers out, which breaks safety. To make forward progress with the C++ model, you have to throw stuff out of the language. That breaks too much old code. So they're stuck.
Many, many people, including me, have tried to make C/C++ safer without breaking backwards compatibility too much. It doesn't seem to be possible to do both. You have to disallow some things or the exercise is pointless.
Did this new proposal include array slices for C++? If you have slices, most of the need for pointer arithmetic goes away. But you need either a garbage collector, as in Go, a borrow checker, as in Rust, or restrictive scope rules to track when the underlying array goes away.
I would hardly say that move semantics, or reusing temporary objects instead of deep copying them, is something invented by Rust.
Also, move semantics were introduced in C++ with C++11, which was in the works since the early 2000s. Rust first appeared in 2015. Are you actually trying to claim that C++ in 2011 specified in an international standard features that it back ported from a language that only saw the light of day in 2015?
> To make forward progress with the C++ model, you have to throw stuff out of the language.
No, not really. Mindlessly removing features only breaks backward compatibility with no reason. We have progress by offering improvements. It's up to the developer to manage how he manages their projects. Mindlessly breaking compatibility prevents that same developer from benefitting from improvements for no reason whatsoever.
> Many, many people, including me, have tried to make C/C++ safer without breaking backwards compatibility too much. It doesn't seem to be possible to do both. You have to disallow some things or the exercise is pointless.
This is an absurdly silly thing to say. It's a kin to complaining that making Rust safe is pointless because Rust still supports unsafe.
The C++ people you want to hire are not applying to C++ anymore.
Naturally they are free to make Cranelift as good as LLVM, and fully bootstrap Rust instead.
go build
Not my case. I have simple CMake files for my projects and have no problems building on Linux and Windows (I do not do Mac). I do use few libraries (Postgres, network - http/tcp/udp and some others). So far no troubles. I do remember it was way more complicated though. So I am not really missing "Rust eating C++'s lunch". I do understand there are some real life huge insanely complex projects with basillion options. Luckily I do not havbe to deal with that part.
I've cloned 5 year old C++ repos that use cmake and it's quite an effort to build them, mostly due to finding all the dependencies correctly versioed.
That’s a little too harsh. You can certainly make it do that via a combination of git tags (to build from source) and CMake modules/Find*, but yes, it’s much more cumbersome than cargo/npm/go
This is why other C++ build systems like Bazel and Meson added Rust support, since Cargo/build.rs itself isn't sufficient enough for all use cases (especially when using it alongside with other systems languages.) And it's not too wild for something to think of adding Rust support for CMake as well...
And if it's not that big, say, a single C file, you can just invoke the C compiler. An example: https://crates.io/crates/cc
The community hasn't standed still, conan and vcpkg + cmake are already quite good.
In that case I would just use the rust toolchain which I'm sure can handle this stew.
Toolchains should never be language specific. That is an antipattern of large projects
I read about a C++ package manager written by Microsoft few years ago, maybe it's now somewhat usable?
Its too complex of a problem to be solved by a committee with competing interests.
So far the best thing that I've seen in wildlife for c/c++ code is just outsourcing everything into docker container with build tools, that you have with qmk: https://docs.qmk.fm/#/getting_started_docker. It has it's downsides, but it's just 2 commands to have built binary, one of which is to clone git repository.
I really had high hopes for Bazel, that they will either package or reuse some standard build tools configurations and just let use them by referencing them in single place in workspace, and the rest is going to handled by build system, but it doesn't seems like this is how it does work now and will work in observable future. If you want it this hermetic, you need to do it on your own.
Dependencies can mostly be managed with vcpkg and its CMake integration. The only real problem is when you need something that's not in vcpkg and have to write your own port overlay.
It's not perfect, but the situation is vastly better than it was ten years ago.
Would love to try it out though when that happens, I do hope that modules will eventually get mainstream enough to make cppfront viable.
The CppCon talk: https://www.youtube.com/watch?v=ws-Z8xKbP4w
Maybe I should give up and try Rust. Does Rust give you _maximum_ control over performance the way C and C++ do? I need that and that's I why I used C++ in the first place.
Yes, with a small asterisk. In general, this is true. In practice, with the way optimizations go, sometimes one or the other may be faster. Or people playing with definitions. But the answer to your question in spirit is "yes."
I suspect Visual Studio on Windows works better than what I've been using – VS Code or Emacs with clangd, which sometimes runs amok, takes 20GB of RAM, and kills my laptop.
In general yes.
What do you mean, exactly?
Rust doesn't have hidden things going on in your programs--and the culture is very much "if it's slow it should be visible in the source code".
I had some Swift code a while back. It was optimized, but when I rewrote it in C++ it got a lot faster. Something bad was happening that wasn't "visible in the code", as you said. The code was pretty complex algorithm and data structure stuff related to computational geometry and computer graphics. I suspect if I tried it in Rust I'd be fighting with the borrow checker and that is not appealing.
https://github.com/carbon-language/carbon-lang
https://compiler-explorer.com/ (pick Carbon)