[abenedic]

As a meta comment, I really like how active Stepha(e?)n is on internet forums. And the energy around Rust is pretty intense. I feel like in there, people are unwilling to try to embrace some of the nuance in the arguments that some people make against Rust.

A person should understand that no language(programming or otherwise) is perfect. Therefore there is some criticism of any language that is valid. Therefore some criticism should be taken seriously as there may be a real point to the criticism.

There are many posts like this, where there are comparisons of Rust to C. Realistically they are all a little biased towards Rust as Rust is a C++ replacement really. A more proper comparison would be Zig or D as a better C against C.

Just understand that a person defending C is not always an idiot, and maybe they have point. Consider the excessive memory use of any working Rust compiler. That will probably not be remedied anytime soon and is a legitimate complaint. The ideal of how something could be is not how something is. The reality is that C works pretty well most of the time, Rust works well most of the time. They both fail at some things.

[vvanders]

I don't think I've seen anyone claiming that Rust is a perfect language without flaws. Heck I'd hold up all of the huge strides that have been made in errors, usability and constant feedback as a counter example of that.

You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice.

What Rust offers is another option in the native, non-GC'd language space. A space that has very few languages and even fewer yet that are shipped at scale. Rusts inclusion w/ FF means that the have to address the robustness, security, performance and usability of the language to a degree that you don't commonly see.

Having just blown 4+ hours today dealing with the linker on a mixed C/C++ project I don't really miss a lot of the baggage that comes with native development these days. Rust gives you the option of dropping down to that level while still preserving a set of sane, opinionated defaults that are pretty well thought out.

[kxyvr]

Since you made a mention of CMake, does Rust really provide an alternative for building multilanguage projects? When I went to look for examples on how this is managed, it seemed horrendous. For example, some projects manage this by writing a program to download, unzip, and build the source:

https://github.com/elrnv/ipopt-rs/blob/master/ipopt-sys/buil...

Others just assume that the libraries are there, but they still require a program to compile them:

https://github.com/cmr/openblas-src/blob/master/build.rs

As long as all of the dependencies are in Rust, things appear nice. At the same time, unless I'm missing something, it seems like crates manages multilanguage projects poorly. Though I have some major gripes with CMake, I've managed multilanguage projects mostly well.

Is there a sane way outside of CMake to manage a multilanguage project with Rust?

[blakesmith]

Check out Bazel: http://bazel.build. I've been using it a lot to build several multi lingual projects that include Java, C++, embedded C, Javascript, CSS, and even Docker images. There are community Rust rules, that I haven't tried yet, but am planning on investigating soon: https://github.com/bazelbuild/rules_rust

[digitaLandscape]

Is there a non-Google alternative for those of us who don’t want our builds spied on?

[OtterCoder]

Not so much with Rust in the driver's seat. Cargo, Rust's primary toolchain, only has weak support for pre/post build scripts. It's solely concerned with Rust's own dependencies and compilation. In the couple of projects where I've added Rust to a larger project, it's always been bash or node that coordinates the overall build.

[oever]

You can call a compiler for C/C++ from build.rs. That tooling is currently not very advanced. As far as I know there is no crate to write compile recipes that as easily as a Makefile or CMakeLists.txt.

When I tried this in build.rs, I had to check modification times myself.

There is an opening for a ninja-type crate in Rust.

[AceJohnny2]

Indeed. Rust is the only new contender in the field of systems programming, where C++ has to contend with decades of negative mindshare (C++11: "I've changed! I promise!"), and D, well, never really took off (because it started off in the early Internet era as a commercial compiler?).

[lasagnaphil]

There is also Zig, which seems nice as a C replacement but still highly unstable, and Jai, which is also a nice C replacement but currently has no publicly available compiler yet... So for the time Rust is the only new systems programming language (And please don’t say Go/Nim is a contender, they’re good languages in their own ways but having a garbage collector disqualifies it fron that categorization)

[geezerjay]

> Jai, which is also a nice C replacement but currently has no publicly available compiler yet...

If there is no compiler then there is no programming language.

[timClicks]

Well, there are videos of code being compiled. But nothing verifiable outside of the Jai team.

[geezerjay]

> Well, there are videos of code being compiled.

There are videos of nazi bases on the moon.

[majewsky]

If that counts as existing, then cold fusion exists.

[pjmlp]

No language that drops C compatibility while having the same manual memory management is an actual contender.

Yes having a GC is a contender, because not all GCs are implemented the same way, and C did not eliminate Assembly as well.

So if a systems language, with GC, covers 95% of use cases. We can happily use something else for those remaining 5%, while enjoying better productivity and safety.

Companies like Astrobe manage to have enough customers to keep their Oberon compiler for bare metal deployments business alive, just as one possible example.

[kiriakasis]

Midori looked really interesting https://en.wikipedia.org/wiki/Midori_(operating_system)

[vmchale]

ATS is in a better state than Zig/Jai lol

[vmchale]

> You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice.

Ironically, cargo is one of the areas the rust ecosystem falls down completely. Not to mention, there's no ABI...

> What Rust offers is another option in the native, non-GC'd language space.

True, and while this is great in principle for embedded development, not using a GC is overrated.

> Rust gives you the option of dropping down to that level

Well, if you're not dealing with the linker, you're not at "that level"

[gnulinux]

Very strongly disagree that Rust is a C++ replacement and D is a C replacement. If anything, it's the exact opposite, Rust is a C replacement and D is a C++ replacement. If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust. There is already a huge osdev community built around Rust, I know kernels written in Rust. Rust is the perfect language to reliably write drivers, embedded systems or system tools. I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome.

[jcelerier]

> Rust is a C replacement

well, which language of C and C++ has the possibility of having traits, structs with function definitions, generics which work through monomorphism, variants, optional, reference-counted pointer and pointer ownership semantics ?

> If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust.

yeah... like C++ ?

[vmchale]

> I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome.

ATS is far closer and indeed compiles to C. Rust's type system is still less expressive than that of ATS.

[hcs]

Never heard of it, link?

[zeptomu]

"Applied Type System" - a language built for correct low-level programming inspired by functional programming and theorem proving.

http://lmgtfy.com/?q=ats+language

If I remember correctly there were plans to implement GNU Hurd (the Half-Life 3 of kernels) in ATS, but that probably went nowhere. But there is a small osdev community messing with kernels and ATS.

[blub]

Actually Rust is clearly both a C and C++ replacement, but C programmers tend to become quite fanatical and for some inexplicable reason C also has a quite decent reputation, so the Rust community is focusing their efforts on the much more controversial C++ instead of attacking the holy cow of C.

I think they've also figured out that with time C will be squeezed into smaller and smaller areas of use, as is already happening.

Writing robust code hasn't really found a space to live in the mental model of C programmers. Using C outside a kernel or existing C project today is professional negligence.

[vmchale]

> some inexplicable reason C also has a quite decent reputation

if you think like this, you will never replace C...

> Using C outside a kernel or existing C project today is professional negligence.

or embedded development lol

[blub]

C has been in the process of being replaced for decades. I specifically mentioned kernels and legacy projects, because these are its last retreats; even embedded has lost a large chunk to C++.

Here's a silly prediction: in the next 10 years a significant number of C programmers will retire without replacement. The new generations will rather learn Go, C++ and Rust for low-level stuff and will banish C to pure legacy projects.

[creatornator]

I disagree about replacement programmers--at the moment, practically every graduating electrical engineer and computer engineer will have a working knowledge of C. Embedded C has lost some ground to C++, but primarily in ARM and x86 architectures, since for more memory constrained AVR/PIC/etc. microcontrollers, you absolutely avoid template inheritance because vtables are untenable, there often isn't an available STL for the chip toolchain anyways, templates balloon the program space, and you are still constrained to using just stack allocation. That right there pretty much means there will always be a space where C is more pragmatic.

I see this pattern a lot on HN. Many aren't aware that there are fields alive and well that require the use of unsafe, deterministic C that can compile to programs on the order of kb.

[pjmlp]

Fully agree with you.

Although not politically correct, that is the only way to overcome religious resistance against new technologies.

[brentsamwele]

> Actually Rust is clearly both a C and C++ replacement, but C programmers tend to become quite fanatical.

Every body whole who creates a new language would like to see it more and more used thus replacing others.