That would be good but it’s not a magic solution to this problem. They would just move the exploit to runtime. Yeay you don’t get hacked if you compile and never run your program.

You can counter that there are some situations where the program is run sandboxed, e.g. if you’re compiling to WASI or microcontroller firmware or whatever. But those are a tiny minority of cases.

Slop. And yeah I hate it. Rust already has plenty of concurrency features.

Me too, but obviously there is a point at which I would say “this language isn’t so great that I’m willing to tolerate these compile times”.

Yes they do. I don’t think it’s totally unreasonable. Slow compile time is a big productivity drain. But it’s not as bad as people often make out for Rust - in large part because compilation speed has at least doubled since Rust 1.0, but its reputation is still based on the 1.0 compile times.

And some specific projects do have substantially bad compile times. When your incremental compilation time is 20 seconds where in other languages it’s instant… That’s notably worse.

But I don’t think it should be a deal breaker. C++ has dealt with similarly bad compile times for decades and people don’t like it but it’s never been enough for most of them to switch to another language.

I am now pursuing opportunities to return to paid work on the Rust compiler. Wish me luck!

Someone (Rust Foundation?) pay this man! Compilation speed is one of the few weaknesses of Rust and even though I think that in 95% of cases it’s actually not that bad and people are just looking for an excuse to not use Rust, it would be great to remove that excuse. (And faster compilation is always nicer anyway!)

Vibe port the Zig compiler to Rust? 😄

I think your intent sounds reasonable. I expect other people have done this, they probably just didn’t wrap it up in a nice crate.

Also no idea why I was downvoted. Maybe because I mentioned the forbidden word.

I could use two &mut [T] values, built with split_at_mut, but this is unwieldy.

This is likely to be the best option. You could wrap it in a nice interface that provides normal indexing but panics if you index the forbidden element. AI will be able to easily write that code for you.

Well I guess not everyone learns at the same rate.

Yes. It’s not as easy and reliable as Zig.

There are definitely some cases where memory safety isn’t especially important:

• Single player games
• Apps that don’t process external data (e.g. a simple calculator).
• Lots of things running on microcontrollers, where the form of input could never possibly cause any security issues. E.g. a motor controller or a basic syringe pump or a (non-smart) washing machine or something.
• Tests, e.g. I’ve considered writing RISC-V tests in Zig. They’re traditionally written in C or assembly.

In cases like those, memory unsafety mainly leads to non-security bugs and annoying debugging sessions. But I wouldn’t say it’s as much of a deal breaker compared to e.g. writing a video codec or font renderer or web browser or DNS server or whatever.

I still think Rust is a better choice than Zig in most cases anyway, even ignoring memory safety. But in these cases it’s at least a defensible choice.

C won’t surprise you…

Lol… I’m sure there’s a meme or graph for where you are in learning C to believe this.

then translates to assembly code with a very predictable pattern.

Even this is a stretch. Modern C compilers can do some wild transformations. I assume you’ve seen the classic one where UB makes it jump to a function that you never actually call.

bash scripting is well-defined

Yeah I mean Bash’s problem isn’t that it’s poorly defined - it’s that the definition is awful!

C is firmly in the “not fun” camp with PHP, JavaScript and Bash. I’d say even assembly is more fun, in a puzzle challenge sort of way.

The most fun language I’ve used is QuakeC, because the only thing you can do with it is write Quake mods. It was a pretty neat language too from what I remember. It even automatically detected infinite loops!

Zig is way better than C in many other respects, so if you want a modern sane language and you’re either a Rust luddite or working on a project where memory safety isn’t that important, it might be attractive.

Like, if the choice is C or Zig, then Zig is pretty much a no-brainer (or it will be when it hits 1.0). It just fixes so many insane things about C that have been broken for literal decades.

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.

Maybe in the 90s when Bill Gates was running the show. These days they’re mid tier evil. Barely even maintaining a monopoly.

If it was Oracle, or Broadcom, or Meta then sure, but Microsoft aren’t in their league any more.

GitHub. You’re hosting public stuff so there’s no more risk of your data being sold on GitHub than anywhere else public. GitHub is what recruiters understand and expect.

I’ll get downvoted by extremists but this is the best option if you want a job and aren’t also an extremist.

I would consider Codeberg or maybe even Tangled for actual projects you’re working on, but for just showing stuff of there’s no advantage to not using GitHub.

Basic human decency, hopefully.

Yeah also people get into a mess and don’t understand the state of the repo. Like they’re organising files without ever running ls. If you ask these CLI fanatics for the solution they’ll say “you don’t need a GUI, just run git log --tree --oneline --decorate --all”… which is just a poor man’s GUI.

That’s a lot of words. I think the reasons are pretty simple:

1. Some people just don’t care.
2. The Git CLI is poorly designed e.g. the many different ways to delete something.
3. Some Git concepts are very poorly named, e.g. the “index”, “ours/theirs”. This adds to the confusion.
4. There are many Git GUIs but only a very small number of actually decent ones (if you’re wondering: GitX, SourceGit, Git Extensions, and the Git Graph VSCode extension).
5. There are a lot of idiots out there telling people not to use Git GUIs, when they are clearly the best way to learn how to use Git. Its easy to get into a mess if you can’t see what you’re doing.
6. Git isn’t actually as simple as us pros would like to think. The underlying model and even the implementation isn’t too complex (I’ve written a Git client form scratch; not too hard apart from the lack of specs/docs). But you can easily get into a state where you’re pulling from a remote and someone else has pushed to the same branch so you need to resolve that (oh btw don’t do what Git tells you to!), and maybe it involves submodules too, and you basically need to fully understand Git’s model and be pretty good at the awful CLI too to resolve it.