Hey rust people
Why not just release a new version of c that automatically deallocates unused variables that are out of scope unless somehow marked to be preserved in a point in ram and their location published in some form of reference table ?

Why were people in the kernel having fake arguments over stupid bs related to being expected to add your new language?

That‘s what C++ does via shared_ptr, afaik.

Also, because Rust's memory model is more than just "deallocate stuff when variable gets out of scope".
And Rust is more than just its memory model.

@retoor C3 looks pretty cool

@retoor not my favorite musical note, but it’s alright.

That would've been the bare minimum 30 years ago. Rust does a lot more than that.

By the way, C can't have destructors because there's no way to track, statically or dynamically, whether the value physically held in a field actually corresponds to a meaningful object. This is why for the longest time C was the only language in its niche, because to do this correctly you need to establish a lot of abstractions which, even if you have an excellent optimizer like C++ and ML, leave you with essentially two different languages for performant and easy code which interoperate well but require different skills to write.

The unique feature of Rust that makes things a lot easier is that because lifetimes are compile-time, performant code ends up working very similarly to easy code.

That's literally not how it works. Like at all

It's fine if you have no clue about how memory safety works or why it's hard, but then at least don't talk shit about something you don't understand

@retoor Shorter statements are neither more accurate nor more useful, not even in a statistical sense.

@lorentz Not to mention that a non trivial program in C isn't even shorter or easier to read than an equivalent Rust version. If anything it's a whole lot longer

Try using a BTree in C... In Rust it's literally 1 line of code

Here are a few other options :

Zig

Odin

D

But C3 looks pretty sexy.

@retoor for every complicated question, there is a simple but wrong answer.

I've realized that for almost all questions this applies: Our world is not simple, don't expect answers to be. Simple answers usually don't tell everything.

This is because well... we as humans kinda suck with thinking and need things simplified because it's usually "good enough".

@retoor
That quote is often attributed to Albert Einstein, although there is some debate over its exact origin.

@retoor C doesn't have generics so it's pretty hard to build good reusable stuff

@retoor Generics aren't overhead when they're monomorphized like in Rust or C++

And yeah you *can* make generic-ish things in C, but that's my original point: Generics can greatly *reduce* code complexity. Because in Rust you don't have to be a preprocessor wizard and write a bunch of code (just a borrow checker wizard :P)

And it's always easier to reuse somebody elses stuff instead writing your own. A good BTree or HashMap implementation are *really* complex. I don't want to write them myself!

@retoor Not saying your's doesn't work, but just leaving this here: https://youtube.com/watch/...

:P

@retoor that is a trie, not a BTree. Trie is a fairly specific datastructure that is only generic on data it doesn't interact with, so it's C's strong suit, whereas an arbitrary map which needs to use a keytype-specific comparison function is both vastly more common and absolutely disgusting in C.

I'll grant you that's a very pretty trie and the Rust version would probably be similar to what you have, as I already said when you wrote it.

edit: actually nevermind, why in the nine hells is the continuation set a linked list and not an array? That is so many unnecessary cache misses

A Rust Trie would be something like
struct Trie<T> {
value: Option<T>,
cont: HashMap<char, Trie<T>>,
}
values inline, continuations in a map and inline in the map.

I guess you can put the value in a box since most nodes would not have one and lookups don't read it on any node except the last.

@retoor the government and media don't use a lot of words. propaganda is more effective if you use less words, and repeat keywords a lot. you want to program into people's brains extremely strong associations. if you keep changing your words you won't burn them into their heads. this is why you need slogans.

complicated explanations also break brainwashing instead of enforce it. people would have to think to understand and if they enter thinking mode then they will suppress their emotions; and propaganda only works through emotions. as soon as people critically think they might accidentally break the spell, even if they've previously been adequately brainwashed

edit: corporate buzzwords are the job version of COVID propaganda

@12bitfloat thats pretty much what my reading said the main argument for it was.

My point is why develop a system critical component in a new language instead of just clean up the old ?

It's like saying "hey Chuck this metric system is pretty good but I'd like to base my length measurements off of Ron Jeremies penis we could call it rock lengths because it's Ron's cock length get it chuck ?"
"My friend Charles that is a good idea !"

@12bitfloat and another thing

MOST software is written in some way in c or c++ even if it's compiler and interpreter or it's libs are what's written in it

We need more people who understand that language set not less

Until we have some magic language porter that actually works

@12bitfloat I like that the kernel works as expected without adding a new language to the mix

@AvatarOfKaine Actual answer: You can't patch C to be as safe as Rust because at that point you don't have C anymore, you'll just have a slightly different version of Rust

None of your old C code would be compatible. And at that point, why not just use a modern language like Rust which is also just a lot nicer to use

@AvatarOfKaine The linux kernel works and is stable, that's true. But that's not *because* of C, but honestly *despite* it!

It took a LOT of work and time to make the kernel as stable as it is

Sure, you *can* write safe software in C. But you have to put in (a lot) more work to achieve that compared to a language like Rust

@AvatarOfKaine The Linux kernel gets tested to hell and back on every release to catch the slew of bugs, and every patch is reviewed by a council of domain experts. It would be stable if it was written in Befunge.

@lorentz but what do you foresee ? It would be a massive rewrite to convert the code base. Or maybe they'd just scrap the drivers that let you run legacy hardware.

I haven't used c much but it seems like good developers make it work.

Which is kind of another point.

And I'm not very familiar with rust except the Last time I looked at it when when was on here it didnt seem to have that robust of set of libs etc

@AvatarOfKaine "good devs make it work" kind of applies to all languages I think. The excellent devs at another branch of my company managed to make Fortran 77 work in 2010, but it took them so long that the automation department got scaled down in the end, it's practically impossible to hire anyone to work on it, and the fact that it "works" is about the best thing that can be said about the product.

Functionality doesn't exist in a vacuum, and on all other metrics C is failing. It hasn't been entirely replaced yet because it does, in fact, work, so there's no specific isolated momentary problem that could not be fixed cheaper through changing the C code than through switching to a language where that problem could not have happened.

@AvatarOfKaine I forgot to answer your question. I don't think most of the kernel needs to be rewritten. We can cover 99% of the risks by writing Rust abstractions for every core API and writing all _new_ modules in Rust and rewriting only orphaned ones so that the expectations of skill and effort from new module authors can be lower. Rust has excellent C interop, there is minimal additional effort in a safe wrapper beyond directly describing how the C API can be safely used.

@12bitfloat I don't mean it in a condescending way, but I wouldn't say a HashMap is really complex to write, and I'm not really good at C

@SoldierOfCode I also don't mean it in a mean way, but if you say that you have no idea how to write a decent hash map

They are really not trivial at all

@SoldierOfCode Which reminds me of this blog post (https://harelang.org/blog/... ) of a very C guy talking about his own language and how simple everything can be. Who needs generics anyways? Just a write a quick map!

To which then this guy responded (https://ayende.com/blog/197185-B/... ) explaining how the hashmap sucks, is buggy, and how this just isn't that easy, which is why you should have generics so you can reuse an actually good map somebody else wrote

@12bitfloat I have written hashmaps though. Of varrying degrees of Complexity, and in multiple languages, C included.

@12bitfloat Also since you mentioned specifically DECENT, the K&R book has a hashtable implementation that is EXTREMELY simple (like, stupidly simple), and it's pretty decent, the string hashing function could be better but it's easy to replace with a better performing one, and it's still decent enough to work well.

@SoldierOfCode Yeah but then.... why do you say "they aren't that hard to write" in the context of "in C you have to write them yourself but it's not that big a deal"

It *is* that big of a deal. And if you've written some you should surely know that it's a lot harder than writing HashMap::new()

C has generics?

Thought that was a c# thing

I just wanna hump pretty women exercise right code and cook Italian

@AvatarOfKaine

This sentence way too coherent. Let me fix it.

I just wanna hump right Italians exercise pretty code and cook women

There you go.

@Lensflare why must you always make me want to cry ?

@AvatarOfKaine I think it’s only fair because you always make me want to bang my head against the wall ^^