Comment by cmrdporcupine | Hacker News Reader

Comment by cmrdporcupine | Hacker News Reader

Parent Full thread

You may have a team of experienced C++ developers and libraries of C++ code to interface with.

I think one make a good argument for Rust, but you will also have a harder time sourcing developers and ramping up to speed. It's still novel, despite maturing rapidly.

There are many many many high quality C++ libraries out there, and the modern C++ language is, for me, decently pleasant to work with, once you pick your style and set of constraints.

Also, I really don't want to go around on this argument _again_, but I don't think Go is a serious competitor for C++ for the systems level programming where C++ dominates. Go is not the language for writing OS kernels, drivers, embedded code, etc. Nor do I think a garbage collected system is appropriate for hard real time systems of most kinds.

I think what we have here in this discussion is another classic case of HN having a bit of a blindspot for anything that isn't web / web services or mobile app development. For many embedded systems developers for example it's a challenge just to get them to consider C++ over C, let alone something like Rust.

The c++ library argument is funny to me because it’s so incredibly difficult to import external projects in c++. This is where Rust is going to eat their lunch.

Had C++ standed still, yes.

Except that now there is vcpkg, conan, prefab (on Android) and contrary to cargo,they support binary libraries, meaning I don't have to build the world every time I start a new project.

C++ has had ages to solve this problem, vcpkg and conan are still a ways away from the simplicity of cargo.

Doesn't support binary libraries? I don't really care considering everything else I get, I'm sure they'll support that in the future.

Cargo is only simple if one is doing FOSS with Rust only code.

Speaking of modern landscape where is a Rust IDE comparable with VS, C++ Builder, QtCreator?

Cargo supports non-public package repositories, not sure what you’re referring to here?

You got a similar response in another thread: https://news.ycombinator.com/item?id=24038376

They are complaining about no support for binary-only crates, which is not cargo's fault, but rather Rust's lack of stable ABI.

Ah. With decompilers these days, what’s the point? I only want that for the potential speed of overall compilation benefits.

Conan and vcpkg are not even remotely standardized on in the C++ community, and C++ teams I've worked on/with recently wouldn't use either of them, preferring raw CMake only. That said, if the whole community could really get behind one of them and throw immense support behind it for several years, it would probably be possible to largely solve this problem for C++.

Those on Microsoft world will need to get used to vcpkg, no matter what, because that is how Microsoft is now delivering some of their C++ libraries.

This keeps being repeated and repeated and it is just a myth.

Even without a package manager adding dependencies manually is quite easy for the vast majority of popular libraries. With a manager it is the same as cargo.

I assume you are talking about old, broken, unsupported, closed source, binary only libraries, but then it is not a meaningful comparison.

Its really not, even with current libraries, not when you come from languages that have a modern packaging system.

This is exemplary of why Rust will win out in the end. The c++ crowd can't acknowledge its shortcomings and fix them in a meaningful way

It is the same for cargo, npm, pip, C++ managers and other languages.

Usually a single line does it in all of them, either in the shell or in a config file.

I call FUD.

It was rarely a single line with C++ when I used it over the last year, moving to cargo it is literally always a single line and I was done.

Rust is going to make the C++ community actually look in the mirror for the first time in who knows how long.

So that project didn't use a package manager and you extrapolate that to an entire ecosystem.

Its sooo many projects, if the argument is that c++ has all these libraries, thats mute, but again the c++ devs just think everything is fine!

I think adding external projects to a C++ project is a major decision that should be taken very carefully and the amount of research you need to do to make such a decision pales in comparison with just how exactly you integrate it in your project so you can #include its headers and link against its libraries. Then once all that work has been done it's now part of the internal repository so using it with any number of internal projects should be quite easy.

In the modern world you should be able to grab things and quickly integrate them and see how they work as your prototyping projects.

C++ doesn't conform to this model.

You're defiantly missing the point and beating it to death.

The issue for you might be ease of configuration, but that's not the issue I was talking about. It's availability of libraries and toolkits, which C++ still dominates in the realms of mathematics, graphics & video, GPU programming, gaming, embedded, networking, etc. And if there's something not available for C++ chances are it's there for C and easily used or wrapped.

Configuration management has indeed been C and C++'s weak point, but in the last 5-10 years things have definitely improved since the world of autotools and the like, and while I appreciate Rust's module and package system for what it is... I can get by with CMake + Hunter or similar systems.

And besides, for my day job (Google) it's either C++ with GN/Ninja or C++ with Blaze/Bazel. And that is also quite excellent for what it is.

At this point my career being able to quickly try out a package or rapidly add a new dependency isn't my measure of quality engineering. In my past life I was a Java developer and a big Maven advocate (when it was pretty new); and the world of bottomless dependency trees that spawned is not something I'm eager to repeat. These days I try to keep my external dependencies ... strategic.

packaging == community

and community is the most important aspect of a language.

Yes c++ still dominates in accelerated computing but it won't for long. All these conversations I've had with c++ devs have just assured me of its demise.

Why would the next generation of developers ever use c++ over Rust?

Don't have a library? Great thats my chance to make my mark.

Reply on news.ycombinator.com