[enriquto]

> I am thrown back by how... "janky" the syntax is.

Well if you come from C++ it's a breath of fresh air! Rust is like a "cleaned-up" C++, that does not carry the historical baggage forced by backwards compatibility. It is well-thought out from the start. The syntax may appear a bit too synthetic; but that's just the first day of use. If you use it for a few days, you'll soon find that it's a great, beautiful language!

The main problem with rust is that the community around it has embraced all the toxic traditions of the js/node ecosystem, and then some. Cargo is a terrifying nightmare. If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.

Concerning TFA, adding rust to apt might be a step in the right direction. But it should be symmetric: apt depends on rust, that's great! But all the rust that it depends on needs to be installed by apt, and by apt alone!

[tcfhgj]

I am coming from C++ and think Cargo is a blessing.

I like that I can just add a dependency and be done instead of having to deal with dependencies which require downloading stuff from the internet and making them discoverable for the project specific tool chain - which works differently on every operating system.

Same goes for compiling other projects.

[jandrese]

While it kinda flies under the radar, most modern C projects do have a kind of package management solution in the form of pkg-config. Instead of the wild west of downloading and installing every dependency and figuring out how to integrate it properly with the OS and your project you can add a bit of syntactic sugar to your Makefile and have that mostly handled for you, save for the part where you will need to use your platform's native package manager to install the dependencies first. On a modern system using a package on a C project just requires a Makefile that looks something like this:

    CC=clang
    MODULES=glib-2.0 atk
    CFLAGS=-g -Wall -pedantic --std=c17 `pkg-config --cflags $(MODULES)`
    LDLIBS=`pkg-config --libs $(MODULES)`

    ALL: myapp

    myapp: myapp.c utils.c io.c

[adastra22]

Unless you are using nix or something, pkg-config is comparing apples to oranges.

[kataklasm]

But that is the kind of convenience and ease of use that brings us another npm malware incident every other month at this point.

[juliangmp]

This is a real problem but I wouldn't blame the existence of good tooling on it. Sure you don't have this issue with C or C++, but thats because adding even a single dependency to a C or C++ project sucks, the tooling sucks.

I wholly blame developers who are too eager to just pull new dependencies in when they could've just written 7 lines themselves.

[jandrese]

I remember hearing a few years ago about how developers considered every line of code the wrote as a failing and talked about how modern development was just gluing otherwise maintained modules together to avoid having to maintain their own project. I thought this sounded insane and I still do.

[r_lee]

And in a way I think AI can help here, where instead you get just the snippet vs having to add that dep that then becomes a long-term security liability

[krior]

On the other hand you don't have developers handrolling their own shitty versions of common things like hashmaps or json-serializers, just because the dependencies are to hard to integrate.

[steveklabnik]

Debian already builds Rust packages from apt, so it will satisfy that critera.

[JuniperMesos]

> The main problem with rust is that the community around it has embraced all the toxic traditions of the js/node ecosystem, and then some. Cargo is a terrifying nightmare. If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.

Something I didn't appreciate for a long time is that, the C/C++ ecosystem does have an npm-like package management ecosystem - it is just implemented at the level of Linux distro maintainers DDD deciding what to package and how. Which worked ok because C was the lingua franca of Unix systems.

But actually it's valuable for programmers to be able to specify their dependencies for their own projects and update them on a schedule unconnected and uncoordinated with the OS's releases. The cargo/npm model is closer to ideal.

Of course what is even better is NixOS-like declarative specification and hashing of all dependencies

[superxpro12]

As a c/c++ cmake user, cargo sounds like a utopia in comparison. It still amazes me that c/c++ package management is still spread between about 5 different solutions.

IMO, the biggest improvement to C/C++ would be ISO defining a package manager a.la pip or uv or cargo. I'm so tired of writing cmake. just... tired.

[hedora]

People that don't understand make are destined to recreate it poorly, and there's no better example than cmake, imho.

Here's my arc through C/C++ build systems:

- make (copy pasted examples)

- RTFM [1]

- recursive make for all sorts of non-build purposes - this is as good as hadoop up to about 16 machines

- autotools

- cmake

- read "recursive make considered harmful" [2]

- make + templates

Anyway, once you've understood [1] and [2], it's pretty hard to justify cmake over make + manual vendoring. If you need windows + linux builds (cmake's most-advertised feature), you'll pretty quickly realize the VS projects it produces are a hot mess, and wonder why you don't just maintain a separate build config for windows.

[1] https://www.gnu.org/software/make/manual/

[2] https://news.ycombinator.com/item?id=20014348

If I was going to try to improve on the state of the art, I'd clean up a few corner cases in make semantics where it misses productions in complicated corner cases (the problems are analogous to prolog vs datalog), and then fix the macro syntax.

If you want a good package manager for C/C++, check out Debian or its derivatives. (I'm serious -- if you're upset about the lack of packages, there's a pretty obvious solution. Now that docker exists, the packages run most places. Support for some sort of AppImage style installer would be nice for use with lesser distros.)

[duped]

cmake exists not because people didn't understand make, but because there was no one make to understand. The "c" is for "cross platform." It's a replacement for autoconf/automake, not a replacement for make.

> If I was going to try to improve on the state of the art

The state of the art is buck/bazel/nix/build2.

[NekkoDroid]

Do note that a (I think standardized) common package specification is being worked on called CPS (Common Package Specification). It doesn't specify how you get your dependencies, but it does specify how they should look like, so that your actual package manager does not need to care about the build system specific formats as it currently does.

[steveklabnik]

Worth reading, from a year ago: https://www.reddit.com/r/cpp/comments/1hgpz0y/wg21_aka_c_sta...

It seems CPS is still being worked on, but not under the standardization of the committee, due to the above.

[enriquto]

cmake is a self-inflicted problem of some C++ users, and an independent issue of the language itself (just like cargo for rust). If you want, you can use a makefile and distribution-provided dependencies, or vendored dependencies, and you don't need cmake.

[duped]

imo the biggest single problem with C++ that the simple act of building it is not (and it seems, cannot) be standardized.

This creates kind of geographic barriers that segregate populations of C++ users, and just like any language, that isolation begets dialects and idioms that are foreign to anyone from a different group.

But the stewards of the language seem to pretend these barriers don't exist, or at least don't understand them, and go on to make the mountain ranges separating our valleys even steeper.

So it's not that CMake is a self-inflicted wound. It's the natural evolution of a tool to fill in the gaps left under specified by the language developers.

[raincole]

> Cargo is a terrifying nightmare

Really? Why? I'm not a Rust guru, but Cargo is the only part of Rust that gave me a great first impression.

[freedomben]

GP mostly answered that in the comment already:

> If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.

[raincole]

I don't know, it doesn't explain how and why Cargo causes "continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole."

[adastra22]

They are conflating unrelated things. Cargo is a downstream result of the thing that annoys them, not the cause. What they don’t like is that rust is statically linked with strong versioned dependencies. There are pros and cons to that, but one outcome (which some list as pro and some list as con) is that you need to recompile world for every project. Hence, cargo.

[steveklabnik]

The problem, of course, is that "apt install" only works on platforms that use apt to manage their packages.

[pepa65]

Depending on the particular apt repo to be ready and have what you need would be so much more of a nightmare!

[newsoftheday]

> Rust is like a "cleaned-up" C++

Except they got the order of type and variable wrong. That alone is enough reason to never use Rust, Go, TypeScript or any other language that botches such a critical cornerstone of language syntax.