Remix.run Logo
▲ bjackman 18 hours ago

It's beautiful to see this perspective! The fact that we are at "whoa, C is fucked up compared to my expectations" instead of "look at Rust's fancy safety stuff" shows that as a field we've started lifting the baseline.

Nowadays I actually believe I'll likely see a world without memory corruption within my lifetime.

▲the__alchemist 17 hours ago | parent | next [-]

My take too. (Aside from this being a well-written, clear article, that I think highlighted a fair selection of relevant points; especially the "always use uint8_t instead if int" part).

I don't see rust a "memory safe" language, or a niche one. I have complaints about it etc, but it's overall a fair baseline of reasonable decisions. When I look at C or other languages rust has learned from, I have more "Yikes, that's rough" takes. So... rust as the language of least "fucked up", to use your phrase? Ownership/safety are one part of the picture, but not what defines it for me.

▲cohani 17 hours ago | parent [-]

[flagged]

▲the__alchemist 15 hours ago | parent | next [-]

Is this the sort of thing you only need to know about if building/maintaining compilers? I ask because I don't know what that means from a practical perspective. I'm familiar with Ferrous systems from their work on probe-rs, defmt, and flip-link, which are exquisite libraries / tools.

edit: I think this is a bot or troll account.

▲Ygg2 16 hours ago | parent | prev [-]

Rust never had a goal of having well defined spec. It all depends on what ecosystem wants.

In lieu of that it didn't fuck up.

▲kingforaday 18 hours ago | parent | prev | next [-]

It’s definitely great that memory safety is becoming more pervasive. Though I’ll believe “a world without memory corruption” right up until another <insert your relevant hacker hero name> comes along and finds a way through an unsafe block, an FFI boundary, or the hardware itself (Rowhammer says hi).

▲bjackman 18 hours ago | parent [-]

> Rowhammer says hi

Yeah I was thinking of prefixing my "memory corruption" with "software-bug induced"! I don't see a credible solution to Rowhammer. ("DDR[n+1] fixes it" - lol)

> an unsafe block, an FFI boundary

Honestly these feel solvable to me at this point! I think we'll see:

- unsafe code shrink as languages get more powerful

- amount of analysis we can apply to each unsafe line shoot up exponentially as AI gets cheaper

- amount of FFI we actually need shrink as it gets easier to just click "rewrite it in $lang" on the decision card when your coding agent says "I found a library for that but it's in a different language"

(Having said all of that, people seem to be adopting Zig for some bizarre reason... So maybe I'm naive to expect unsafe lines to shrink)

(But also, maybe AI gets so good and so cheap that we can just type "go fidn all the bugs andfi xthenm" into an LLM, between sips of a Piña Colada)

▲smj-edison 15 hours ago | parent [-]

I'm one of those people who's adopting Zig :) But I don't think it's best for every project. For context, I've used Rust before for probably two years writing a realtime audio synthesis engine, so I'm fairly familiar with Rust vs Zig for handling low level details.

The biggest reason I use Zig is it's a very explicit language. The creators made a very intentional decision to avoid too many "high level" designs. This doesn't mean there's no capabilities for abstraction (comptime is great for that), but when you see array indexing, you can think "ptr + index * size with bounds check". There's lots of other things like that where the language does exactly one thing, and that thing is a low level operation.

This is terrible when you want to create high level abstractions that hide details from the programmer, but it's what I need when doing realtime audio synthesis or what I'm doing now which is writing an interpreter. I know exactly what allocates, I know what calls IO and can block (both operations explicitly take in an allocator or IO parameter), no data structures have private fields so I can always poke around at the insides. I know what types of errors a function returns, and creating errors is cheap with Zig's error union design.

So I don't use Zig because I think it's the safer language, I know it has sharp edges because of the number of times I've caused a panic on a poisoned pointer or use-after-free. But because it gives me such a transparent view into what is happening I find it liberating.

▲cohani 17 hours ago | parent | prev [-]

Focusing narrowly on memory safety is frequently a distraction that incompetent developers use to excuse their buggy code. "Sure, my Rust code might cause deaths and cause millions of dollars lost; and my code might be unsafe, insecure and incorrect; but at least my code is memory safe and easy to debug when I fuck it up!". And then it often turns out that Rust is not memory safe in practice. https://news.ycombinator.com/item?id=49697392

The real value of Rust is likely pattern matching and tagged unions. Apart from modules/packages that are not a disaster, like Gabriel Dos Reis the saboteur's disaster with modules in C++.

▲nilslindemann 16 hours ago | parent | next [-]

Were you intentionally rude with your first sentence or just unaware?

▲cohani 15 hours ago | parent [-]

[flagged]

▲TripolitianFish 15 hours ago | parent [-]

Jesus Christ you suck.

▲aw1621107 13 hours ago | parent | prev | next [-]

> And then it often turns out that Rust is not memory safe in practice. https://news.ycombinator.com/item?id=49697392

For what it's worth, in that specific instance there's no memory safety issue since Rust is guaranteed to crash on stack overflow on Ubuntu (and probably other supported Linux distros)

▲afdbcreid 7 hours ago | parent [-]

For what it's worth, this is not only that specific instance. Rust might not be memory safe in theory, but when talking about "in practice" - there is profound evidence that Rust's memory safety works.

▲slopinthebag 8 hours ago | parent | prev | next [-]

this argument is so stupid, yes rust doesn't prevent all bugs but eliminating a large proportion of them is very obviously a good thing.

▲wannabe44 14 hours ago | parent | prev [-]

Indeed! They shrug it off when you ask them about supply chain safety or compiler complexity. I opine that post 1.0 they wasted precious engineering time trying to placate nodejs webshits over building the best systems language.

    There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

        — C.A.R. Hoare, The 1980 ACM Turing Award Lecture
▲aw1621107 13 hours ago | parent | next [-]

What would you have preferred the devs work on instead?

▲slopinthebag 7 hours ago | parent | prev [-]

i suppose a supply chain that doesn't exist is pretty secure.