No Zig definitely is special. You don't have to do any extra busy work to call C code - you can pretty much just #include the header and that's that. It's similar to calling C from C++.

In any other languages - including Rust - you have to do some work declaring functions, wrapping them and so on. It's not hard but it definitely is a non-zero amount of tedious work (especially before AI). There's absolutely no way you could describe it as "trivial", unless someone else has already done that work for you.

But I don't think it is a significant Zig advantage really. When I'm writing Rust, it's extremely rare that I want to call any C code that someone else hasn't already done the tedious wrapping for.

from rust docs:

Note: “Zero-cost” means zero runtime cost, not zero compile cost. The compiler does real work — monomorphization and inlining — to make abstractions disappear, and that work shows up as longer build times. See Reducing Compile Time for the trade-off.

most of the benefits come from a shared code base, one compiler (which is insanely fast with incremental rebuilds and can watch files for changes) means changes in the c code reflect in a single build step within seconds. the benefit is primarily for the developer as the compiler output should be relatively similar.

a c compiler not just using ffi.

Beyond what amounts to a packaging difference, what does that even mean?

How do you think zero-cost C ABI support (including fully working cross-lang LTO) works in lang implementations that have that? And how do you think that's different from what Zig gives you?

zig is a bit special in this regard though as it is a c compiler not just using ffi. this means you could swap out gcc, make autotools etc and drop in zig with a build.zig. mostly useful if you want to migrate large code bases as you can incrementally port the parts you want.

if you're picking it up for a new project then yeah this probably doesn't impact you much.

Saying that "memory safety is checked by tests" is basically saying "memory safety is not checked". Yes, you can write tests. How do you know the tests cover all cases? How do you know the tests aren't buggy?

Also, what about memory safety across threads? Are you testing multi-threaded scenarios? Are you ensuring you have no data races?

I also don't understand how this is an argument for Zig over C. You can also test memory safety of your C code via various means, but it's never a guarantee. Zig is the same. So again, it seems a bit more pointless to go from C to Zig. Going from C to Rust brings actual tangible guarantees of memory safety (outside of any unsafe usage, obviously).

rust does a great job, however there are some inconsistentcies where a lot of memory allocations can throw out of memory errors that will crash the app

That is not an "inconsistency". Crashing the application when you run out of memory is honestly in almost all cases the correct call and crashing is memory safe. Most applications can do absolutely nothing when running out of memory. "Handling" OOM is extremely complicated and most applications simply cannot handle it in any way.

Of course low level stuff needs to sometimes actually handle this, but it's mostly an operating system thing. And Rust still allows you that control, it's just not the default behavior of the collections and such in the standard library, because again, it almost never makes sense to try to handle OOM. But if you really need that behavior, you can have it.

and memory safety is checked through unit testing

🤣 🤣🤣🤣🤣🤣

You can trivially use C libraries in Rust, or any system language that supports the C ABI for that matter, and this includes many hobbyist languages. Zig is not special.

zig does have guard rails, they're just different approaches. zig defaults to optional types where null must be handled. and memory safety is checked through unit testing and exposing debugger memory allocators that check for different memory corruption bugs.

rust takes a shift left approach where all declarations drive safety whereas zig takes a more laid back shift right where it's expected you'll have written tests. rust will force all developers to conform to produce good code where zig requires a bit more though, i mean every dev writes test cases right?

i like the way zig interfaces with c. even though it's a "newer" (not 1.0) language you can import native c which means you have access to already really fast libraries. the build script and macros are the same language you write your code. the best part is you can interface with normal code (not unsafe) and can create boundaries where sure in the c side you can't enforce memory safety, but where you interface you can convert into memory safe types.

to talk more about memory safety i think rust does a great job, however there are some inconsistentcies where a lot of memory allocations can throw out of memory errors that will crash the app whereas zig you could gracefully handle it. this is probably more important for lower level things like kernel than an app where not recovering means everything goes down.

honestly i wish there was an opt in borrow checker as some patterns are easily expressed, but honestly i would opt out for async code as it just gets verbosely over-declarative imo. also the new async in zig is really really cool.

Yup. I'm an old fart who learned C as my first real language. Rust is just fun.

I mean, you can create a GPL fork of the Rust coreutils if you so please. Or you could do a rewrite in any programming language of your choice and license permissively.

In any case, I profoundly cannot bring myself to care about the fact that you can legally create a proprietary fork of permissively licensed FOSS. I don't think it's right to impose any restrictions on what people can do with software/code, which of course conflicts with the fact that other people can take your code and restrict what other people can do with it. So choosing between copyleft and permissive licensing is a balancing act of that contradiction. I don't think it's wrong to end up on the side of permissive licensing.

OP is postulating the driver behind rust rewrites is not for the language features but to allow coreutils functionality to be relicensed as closed source software.

And that postulation is extra laughable because non-GPL coreutils implementations always existed. And by always, I mean they actually predate the GNU implementation itself (which was a originally a "rewrite" btw 😉).

And yes, they don't target GNU compatibility, but some of them are perfectly serviceable as is (e.g. the freebsd ones), and adding GNU compat to them would have been infinitely easier than starting a Rust implementation from scratch anyway.

Another laughable aspect regarding the coreutils/uutils case in particular is that uutils didn't even start as a corpo-driven or corpo-backed project. It was literally a Mozilla employee having fun in his free time, especially during Covid, and community contributions in the same vein. Rewrites of non-GPL projects (e.g. sudo) were ironically much better backed.

From my experience here and elsewhere, the people who make such stipulations don't even know which licenses the core packages in their own systems adopt. Many of them don't even know what these licenses' provisions precisely entail. They just perpetuate some retarded circlejerk probably started by some clueless+malicious e-celeb that goes like:

linux distro -> C -> gpl -> not corpo -> good
rust -> not gpl -> corpo -> bad

You can write GPL rust code, you can also write non-gpl rust code. Gnu coreutils are gpl, if I choose to write functionality compatible with coreutils from scratch in rust I can relicense that as I please (ie not GPL) OP is postulating the driver behind rust rewrites is not for the language features but to allow coreutils functionality to be relicensed as closed source software.

Agreed that it makes the transition from C easier, but I'd also say it makes the transition from C more pointless. I don't really know that much about Zig but from what I've heard, I don't really get the benefits - if you want a fast systems-level language without guard rails, why aren't you just writing C (or C++, if that's your thing)?

Arguably Zig has a simpler approach to memory management (which can also lead to more errors, arguably) which makes the transition from C somewhat easier. Downside is that the language is still under heavy development and you definitely have to be up for the ride.

Do you seriously think that's how IP law works? If you weren't able to write GPL Rust code, Rust would not be free software. That would require the Rust project to issue software licences to programmers that stipulate that you must not create GPL-licensed software using Rust.

Rust is free and open-source, like most programming languages. That means you are allowed to make whatever software you want with it, including GPL software. There's nothing stipulating that you can't...

But consider, Rust being named what it is led to the project name ffmpreg

Yeah, I enjoyed when fish shell did their rewrite and people were arguing whether it makes sense technologically, like it's a mature codebase, so it's not likely to reduce the number of bugs and yadda yadda yadda.

None of this mattered, because fish is developed by a group of hobbyists. They didn't want to continue developing in C++, because it was a pain in the ass. And for sure, one of the reasons they wanted to switch to Rust is because it's new and exciting.
These reasons are perfectly valid, because they're volunteers. If they're not having fun, then they will just stop developing.

Since you seem to be in good faith: no, you’re wrong. Using a language cannot force you into adopting a licence, because automatically everything you produce will be all rights reserved unless otherwise specified. It’s then up to the developer to choose a license.

Rust doesn’t even populate the license metadata in your manifest, it’s up to you.

I think MIT dominance came about thanks to GitHub’s choose a license.

Eh, I've heard "foo is a great language" far too many times before, and we always end up seeing the disaster. Sometimes I miss C with POSIX.

My current solution is usually to just make a bunch of stupid match statements and fix whatever clippy complains about. Then if any remain be sure to “accidentally“ tag the friendliest rust expert I know on the PR and see if they say anything.

edit: They usually say something like, “you could replace those matches with a and_else, map_err, unwrap_or, and_then? and a filter_map.”

To learn rust, I just started writing all my personal projects in rust. I started with REST apis and basic CLIs.

sorry about that. it's hosted on a free server and they get overloaded from time to time :(

It was fun when knowing programming was almost a superpower that you had to learn by reading lots of books, etc. Now a computer can do much of the job. The computers are even solving long-open Erdos problems. We're all just mediocre meatbags.