Rust is now 13 years old.
So, has it accomplished its goal or will we stick with C for the next 100 years?

Jai will destroy Rust.

>>105880542 (OP)
too old and I would say it's accomplished a lot, but a lot of work needs to be done to win people over

>>105880542 (OP)
>Rust is great, if we pretend the only competition is a pre-internet language from 60 years ago.
Pathetic. This is why Rust will lose to non-dgshit languages.

>>105880585
>>105880683
you will never be a real programming language

>>105880728
i'm not cnile

>Rust is 13 years old
are there any known programs written in Rust, anything famous? I think I have never used a program made in Rust

>>105880874
The Linux kernel and the formerly GNU coreutils.

>>105880859
yes i know you idiot lamao

>>105880728
Not an argument.

>>105880925
That was impossible for you to know without me indicating or stating it explicitly in some way.

>>105880542 (OP)
>Rust is now 13 years old
gross, it's a hag now

>>105880932
99.9% sure if youre in need for anal autism

>>105880932
>>105880961
oh
you meant i cant it deduce from your post?
are you fucking retarded (autistic) ?

>>105880542 (OP)
this is funny. because ~13 years ago is the exact period when C effectively stopped being self-hosted, with GCC's move to a subset of (not-modern) C++.
no one is "sticking with C", if given the choice, except /g/eet sophomores and their fellow nocoders. you know, the type of person who would retort by mentioning a meme "small" C compiler upon reading this.
some of us are just glad rust came to exist, instead of being forced to pick a supposedly sane(ish) C++ subset we can agree (or rather not agree) on using.

>>105880542 (OP)
are you a tranny yet? if yes then it has accomplished its goal for you

>>105880542 (OP)
still needs piggyback rides from C
give it another decade

>>105881063
at this pace the whole rust projects bears the signs of a grift
rust is actually 18 years old if you take into account its whole development time (before it became a project on its own)

thats 1/3 of the age of c
thats 1/2 of the age of c++
and theyre still not at a proper version 1
its a grift or the devs are retarded
either way that smells bad

>>105881093
not a grift, it's a psyop to turn everyone into tranny pedo faggot

>>105880972
>>105880961
I think this discussion is getting a little heated. I recommend calming down.

>>105881119
lmao
one thing is certain
seemingly they give 0 fucks about their own project

>>105881124
>>105881138
yeah, remember the whole debian debacle?
instead of writing a cs101-tier tool they went
"nuuuuh u chuuuds"
its like they actively try to sabotage the whole enterprise

Rolling for C++/Rust successor.

>>105880882
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://bpb-us-e1.wpmucdn.com/sites.gatech.edu/dist/a/2878/files/2022/10/OSSI-Final-Report-3.pdf
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292

>>105880542 (OP)
It's becoming rusty

>>105880874
firefox

>>105880542 (OP)
if you are a glowfag or zogbot, they will force you to use this ugly unfun language and you will live in misery till you off yourself

>>105881587
Only a part of the dev tools are written in Rust.
Mozilla doesn't dare to put Rust into any actual user-facing component yet.

>>105880542 (OP)
Rust ain't a C replacement.

>>105881624
I thought that their rendering engine (servo) is written in rust? Which should be the main part of browser?

>>105881697
They are still on Gecko.
Servo never took off.
In fact, Mozilla got rid of it and transfered it to the Linux Foundation. The project factually dead now with barely any contributions.

>>105881624
Servo?

Are you a rustacean doing tricks?

>>105880542 (OP)
Rust evangelists love lying. And the inflation of Github stars on many Rust projects seem gamed. Fake Github stars, fake reddit and HN accounts, just too much that is fake with Rust.

>>105881742
Sad if true. I thought they use it because during every gentoo update, half of the time is spent on emerging firefox and I see that rustc is compiling something, not g++.

trannylang

>>105881742
https://4e6.github.io/firefox-lang-stats/

>>105881809
yeah, i know, i package firefox myself as well and rustc is such a slow pain. But that is really mostly dev tools and the crash reporter.
In fact, finishing to rewrite the crash reporter into Rust was their largest success:
https://www.phoronix.com/news/Mozilla-Rust-Crash-Reporter

Servo was dropped in 2020, when Mozilla laid of 250 people, the Servo team was part of that. It was then gifted to the Linux Foundation and was dormant.
Three years later, they got some new funding coming in and currently they are doing busywork (comparable to OpenOffice under Apache), but no actual tangible progress.

When the CREATOR of Rust has to dump and cancel its Rust projects, because it's going nowhere, you really know just how bad his is...

>>105881859
Thanks for confirming that only a small part of Firefox is written in Rust, and its an unimportant part that isn't user facing in normal operations - i guess the user will see the Crash reporter when Firefox crashes, so i concede that this is user facing.

>>105880549
kill all indians

>>105881624
>>105881697
>>105881742
perfect retarded /g/eet chain, where everyone manages to be wrong in a different way

>>105881936
ya, it's kinda stupid when you get the details wrong.

>Only a part of the dev tools are written in Rust.
oh well chud, but what about the Crash Reporter! BTFO!
>The project factually dead now with barely any contributions
oh really chud? While Mozilla DID abandon it and it IS going nowhere, they DO have busywork commits right now, where the commit text is larger than the code changes! Liar liar, pants on fire!

I WILL do better in the future!

>>105882047
>i'll double down since i'm a certified retard anyway

>>105880549
Jonathan Blowjob
Jai sri ram

>>105880542 (OP)
rust is also anal aids

>>105882047
>>105882204
Is this a monologue?

I hate rust so much the japaneese fought it almost 1k years ago

>>105881063
keep it out of my shit, go make your own kernel with black jack and hookers

linus is veik man eh should just go fuck off, we don't need you trannies. go make something new!

>>105881875
>>105881891
cloc that has been run on Firefox source code:
>C++: ~5.55M LOC
>C: ~2.79M LOC
>C/C++ headers: ~3.23M LOC
>Rust: ~3.8M LOC

But, there is a twist. If third_party/rust/ is deleted:

>Rust: ~0.365M LOC

Less than 10% of Rust LOC in Firefox is outside third_party/rust/ .

What Rust source code is hiding in there?
Some of the folders with the most Rust LOC might be:
>windows-sys
>linux-raw-sys
>winapi
>tokio

None of these Rust crates are specific to Mozilla or Firefox or (as far as I can tell) developed by them.

So it is a reasonable guess that Rust code in the Firefox codebase, if one excludes vendored non-Mozilla Rust projects, might have LOC count at most 5%-10% of the C/C++ LOC count.

Also, when I looked at the recent commits in Firefox, I saw a bunch of C++ commits, but not any Rust commits. Though maybe I just overlooked them.

>>105881697
>>105881809
servo was a full web engine project, not just a renderer. but it was also the umbrella under which ALL browser-related Mozilla Rust code was developed.
mozilla did incorporate major Rust components into Firefox. This includes the CSS engine (stylo) and the renderer (actually called webrender). This is why you see a lot of Rust code getting compiled. It's not just "devtools" and the crash reporter like the other retard was saying. But going by lines of code, Firefox is still mostly C++.
Mozilla did fire the servo team in ~2020 (working on the web engine), and did indeed give the project to the Linux Foundation. But Igalia picked up the development in ~2023 and hired a team to work on it full time, unlike what the other retard was saying. servo is finally making some good-if-slow progress.

>>105882403
As someone who has to build firefox from source, this really explains a lot.
I never saw Rust in any important component ever, yet felt half of the compilation time is rust bullshit.

>>105880542 (OP)
>2006 was 13 years ago
time flies

>>105882432
>This is why you see a lot of Rust code getting compiled.
Judging from >>105882403 , most, maybe 80%-95%, of the compiled Rust code, is probably just non-Mozilla vendored Rust dependencies.

>>105882432

If servo/ is the folder that contains stylo (is stylo vendored or not?), then I can find 119K Rust LOC in there.

If gfx/wr/ is the Rust webrender subproject, then I can find 105K Rust LOC in there.

That might account for approximately 2/3 of all Rust code that is not vendored from possibly mostly non-Mozilla Rust projects.

>>105882432
>servo was a full web engine project
This "full web engine" doesn't include a JavaScript engine btw. That one is SpiderMonkey.
And spider monkey alone has 781 source files of pure C++ with 708,380 LOC.
Meanwhile whole servo has 336,268 LOC.

So even if Servo would have been successful and implemented - and wouldn't have been dropped five years ago - in the best possible universe for them, the majority of code, and the most important code, would still be C++.

But we do not live in that universe, we live in the timeline where it died in the year 2020.

The goal was to make trannies the norm in software development, and in that regard Rust has succeeded magnificently.

WTF is this?

This commit has both C++ and Rust changes.

https://github.com/mozilla-firefox/firefox/commit/941d6cabb0e49e8f60e45359bc50943ce95b8138

In order to develop Firefox, now you have to master both C++ and also Rust?

I wonder - was or is Hellwig a Firefox contributor?

>>105880542 (OP)
I doubt it. How are you supposed to create a shit first implementation of a new feature in a language that forces you to always write 'good' code? You have to start somewhere, after all.

>>105882432
I do not understand this one thing.

If my guess is correct that this is the folder for stylo/style in Firefox https://github.com/mozilla-firefox/firefox/tree/main/servo/components

And this is the main Github repository for stylo https://github.com/servo/stylo

Why are there more recent commits for the style folder in the Firefox repository than in the Github servo/stylo repository? Is stylo a fork, or the other way around?

>>105882727 (Me)
btw. looking at the servo code, the majority of their code is tests.
I mean... congrats on being memory safe and having good test coverage.. but HOLY SHIT it must SUCK to work for them.
Rust is already a very unfun language. Rewriting something that already exists is also less fun than developing something new. And then you also get bombarded with a high test coverage requirement.... i would kill myself.
No wonder that nobody developed on it between Mozilla dropping it (2020) and new funding coming in (2023). Without a very good wage, nobody is going to touch that, nobody voluntarily contributes to this.

Every rust dev I've spoken to knows more about C/C++ than the average C/C++ dev I speak to.

>>105881119
>>105882749
I'd love to run a survey and find out what people like you do for a living. If you're not already disabled I promise you qualify.

>>105882775
nah, the C++ code there is bindings, it is still all rust related.

>>105882872
Well of course, they spend the majority looking at C/C++ code to copy it.
The life of a Rust developer is to look at C code on one monitor and rewrite it into Rust on the other monitor.

Now imaging how pathetic such a life must be.

>>105882872
>Every rust dev I've spoken to knows more about C/C++ than the average C/C++ dev I speak to.
Yet some of those Rust enthuasists make shit Rust code with crashing bugs that I, a programmer that does not prefer Rust, end up fixing for them when they can't figure it out themselves. I don't like that I write better Rust code than some people who actively prefer Rust.

I'm in such a weird spot with rust. I love and hate it. It just werks but is so fucking annoying sometimes. My program just screams syntactical noise.
I've never written Go. But I've seen its infamous error handling.

>>105882855
>>105882775
How do we safe those poor developers at Mozilla, bros?
We must do something.
Those guys are living in hell and are getting tortured. What did they do in their previous life to deserve such a horrible fate?

>>105882872
>"C/C++"
>"Rust devs are the secret cool C++ coders from yesteryear that totally learnt to hate their language. Don't look into their past, sisters"

GPT bros, how do we respond without sounding like a string of generic prefab responses constructed by a weighted transformation table of midwit reddit or hn takes?

>>105882949
>It just werks
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
Memory safe segfaults - it just werks

>>105882953
>[...]string of generic prefab responses constructed by a weighted transformation table[...]
I know you think this makes you sound smart, but I promise it just makes you come across as a total midwit retard that has never met someone really intelligent.

People like you worship abstractions of yesterday while senselessly hating abstractions of tomorrow. Had you been born 20 years later, you would be here shilling for Rust at the expense of whatever comes next.

>>105882887
But, unless the bindings are 100% autogenerated and never have any bugs and thus do not require manual validation, then it may require an even higher level of expertise of both Rust, C++, and Rust-C++-interaction than otherwise, since Rust's memory (un)safety goes out the window when FFI is involved, and often requires a lot of "unsafe". And, lo and behold, one of the Rust files in that commit has 97 text occurrences of "unsafe". Look for instance at this

unsafe {
if array.is_null() {
return &[];
}

let elements: &[*mut RawGeckoElement] = &**array;

// NOTE(emilio): We rely on the in-memory representation of
// GeckoElement<'ld> and *mut RawGeckoElement being the same.
#[allow(dead_code)]
unsafe fn static_assert() {
mem::transmute::<*mut RawGeckoElement, GeckoElement<'static>>(0xbadc0de as *mut _);
}

mem::transmute(elements)
}


Why did they let this unsafe-block span this many lines? Not that many comments either.

And some of the changes in the commit touches "unsafe" code.

It is even worse than I first thought.

>>105882781
>in a language that forces you to always write 'good' code
Forces you so much that the Rust standard lib devs cannot avoid segfaults https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>105882855
>>105882951
>>105882872
Monologue?

>>105883088
You retards need someone to explain basic logical fallacies to you realllyyy slowly.

>>105883047
In that specific example, I guess some of the lines are just dead code for a static assertion. Still way too much unsafe.

>>105883146
-> >>105881489
Dude, please describe yourself in more gentle terms.

>>105880874
If there is, it's just a re-write. I've never seen something good that's written in Rust that wasn't a re-write.

>>105881489
this seriously

>>105883172
To be fair, Rust does have pattern matching. Though it might get added for C++29. The C++ proposals for pattern matching seem more and more mature.

>>105880874
>>105883177
https://github.com/ItsEthra/yclass

>>105883177
https://github.com/zed-industries/zed

>>105883198
don't know what that is. don't care.

>13 years
By 13 years, C had:
Unix
Its own compilers written in itself (rust relies on C++)
text editors like vi and emacs that are still used today
the coreutils
Oracle database systems

If we're going by standardisation/stable, ANSI C is from 1989, rust 1.0 is 10 years old.
By 10 years, C had:
Linux
Early windows
GCC
Python interpreter
Apache HTTP server
GIMP
OpenSSL
Early Photoshop
Early MS Office
90% of AAA 3D games

Rust is a baby gate for bad programmers, perfect for tinkerers and jeets.

>>105881587
rust is somewhere in Other, isn't it?

>>105883275
Can you tell me an instance where a std::shared_ptr exiting its scope will still cause a memory leak?

>>105883248
will we ever be able to write software ever again

>>105883281
>Can you tell me how to avoid a pitfall that every CS grad monkey should know
Are rhetorical questions your typical way of debate?

>>105880542 (OP)
Nah.

>C++ specifically C++23 has more memory safety features now and will only get better in C++26 while having the legacy code.
>Zig is faster AND safer than Rust and just added a ton of new features, just got a pretty good package manager and is close to having it's own compiler away from LLVM
>Carbon 1 is coming out at the end of next year and will have all the safety features of Rust but be 100% compatible with C++ as C++'s successor
>Rust still has zero game engines
>You can blow the fuck out of Rust's best web servers with fucking Javascript now using UWS.js which is just using a C++ webserver, web dev in Rust was dead before it started

Rust had a good run but it's days are numbered. Solana will be the only thing it is still used for soon.

more like Gaydon Whore, am I right lads?

>>105880874
webGPU, which is what the browser standard will be pretty soon for graphics rendering. It's way better than webGL and uses Vulkan and actually performs on par with non-browser renderers.

>>105880542 (OP)
Nah. I'm all for innovation but Rust hasn't changed anything yet. They could've written a decent OS in it at least, but all I see is toy UNIX clones

>>105883417
>webGPU
only firefox uses wgpu and it has <2% market share

>>105880874
well known? no
i like ruffle though

>>105883340
It's a rhetorical question because I know these retards can't answer it, yet feel qualified to make dipshit statements.

>>105883357
>zig
buy an ad nigger

sheeiiiittt, NASA uses Rust too
https://techport.nasa.gov/projects/96767

>>105883198
C++ still does not have pattern matching, std::net, std::process, and still puts names on snake_case. Disgusting

>>105882432
>>105882727
Rust does not need as much code as C++.

>>105883248
The times were different

>>105883600
it needs more

>>105883461
Retard. I'm using it in Brave and Chrome rn.

>>105883357
I believe C++ would benefit a lot from a profile for "modern" C++. And pattern matching, of course. C++ is, as everyone acknowledges, a large language, and such a profile might help with handling that size, since modern C++ has a lot of useful features relative to older styles. A profile should enable people to opt-in and refactor at their own pace.
Memory safety checks, whether at compile-time or runtime, are interesting, but they are not generally free in many different regards, both in the different experiments and proposals for C++, and also in Rust. Also in terms of ensuring correctness of code.

Zig, I am not sure about, I know very little about it. It has not reached 1.0 yet, and it does not have backwards compatibility yet. Its approach to compile-time execution is both praised and criticized. For instance, this Rust article criticizes Zig https://poignardazur.github.io/2025/07/09/variadic-generics-dead-ends/ . But the language is definitely interesting, it is ahead in terms of compile-time execution of both C++ and Rust.

Carbon encourages Rust, and I don't know if they have a public compiler prototype yet that can compile code.

I don't know much about UWS.js.

>>105883417
>webGPU, which is what the browser standard will be pretty soon for graphics rendering. It's way better than webGL

>>105883623
>Brave and Chrome
chromium implements webgpu support in C++

>>105883384
He has discussed things that could have been done differently in Rust.

https://graydon2.dreamwidth.org/307291.html

https://reddit.com/r/rust/comments/1gaihlw/rust_vs_c_with_steve_klabnik_and_herb_sutter/luakun9/

>>105880542 (OP)
idk man I switched to ARK a long time ago

>>105883649
>I believe C++ would benefit a lot from a profile for "modern" C++
From my understanding they're pretty much evolving the language now because of Rust instead of just telling everyone "GIT GUD" when they talk about safety stuff

>Carbon encourages Rust
It was more along the lines of "if you're already using it that's great, no need to switch" because Carbon is meant to be a successor to C++

>Zig, I am not sure about, I know very little about it
Not a big Zigger myself. I used it once. Bun.js was written in it and brags "faster than rust speeds in Javascript!"

>I don't know much about UWS.js.
Remember how I mentioned Bun? It turns out their "faster than rust speeds!" was just because their HTTP server uses uws.js, one of the fastest standard libraries out there. It uses the C++ library uWebsockets under the hood which is the real secret to it's speed. It's both an http and websocket server and is insanely fast, it was based on express.js.

Here's the kicker. Uws.js was made for node.js and is 80% faster on Node, so the bun replacing node thing is a meme. You can just use it on Node. All the fastest http/websocket servers in both node and bun now just use uws.js under the hood. Basically bun was snake oil.

>>105883281
>>105883340
>>105883550
Not the one you asked, but doesn't C++'s shared_pointer, and Rust's Rc and Arc, share similar problems regarding this? In that, they all use reference counting (the "rc" in Arc and Rc), and if there is a cycle, memory will not be released?

>>105883569
>std::net
Why not have it as an external library, and then improve the ecosystem, and let third party libraries handle the issue? Or, have a basic, simple, slow implementation in the standard library, and encourage users to select third party libraries? Maybe there are drawbacks to that, I am not sure.

>>105882600

non-vendored, yes. non-mozilla is not accurate. some are (directly) maintained by mozilla. some are not.

also, one shouldn't take their info from jeet-logiced nocoders who continue to move their own goal posts. especially when it's such a shallow "analysis".

slightly less shallow "analysis" is in picrel, where you see the ratio of Rust vs. C/C++ before and after running `cargo vendor`. but this is of course still shallow, since it doesn't even cover conditional compilation (DEFINEs in C/C++, cfg in Rust) for starters, or tests et al. not to mention the fact that any LoC-based "analysis" is retarded to begin with.

but one can at least deduce that that no, the rust code you see getting compiled is not just for some "devtools" and the crash reported. and if you would take /g/eet claims at face value, you would think that amount of rust code would take a week to compile, but it doesn't.

running `cargo vendor` would also give you an idea about other areas (other than stylo and wr) where Rust is used in Firefox.

>noooo reddit spacing

>>105883600
Yes and no, because lifetimes and satisfying the borrow checker does have drawbacks in several different ways.

>>105883023
>"GPT bros, [...]"
>takes a low quality subset of a phrase within a greater point
>proceeds to shit out some generic, our team vs their team, strawman slop
>checkmate chud, you should be shilling rust in my headcanon

Zoomzooms and tranoids hate pattern cognition

>>105883830
If you run `cargo vendor` into the folder third_party/rust2/, and compare that to third_party/rust/, what are the differences between the two, if any?

And of the code, the guess is (relative to C/C++ LOC):

80%-95%: Vendored non-Mozilla code.
5%-20%: Non-vendored Mozilla code + vendored Mozilla-specific code from external projects.

>windows-sys
>linux-raw-sys
>winapi
>tokio

Are the largest vendored Rust dependencies, and none of them are Mozilla-specific.

>encoding_rs

Is probably the biggest Mozilla-specific dependency, and it is not that big relative to the ones mentioned above.

And you really should describe yourself in more gentle terms.

>>105884010
>Are the largest
Are probably the largest

>>105884010
>If you run `cargo vendor` into the folder third_party/rust2/
>the other nocoders will probably not realize how retarded i am

>>105884010
>(relative to C/C++ LOC)
Not relative to C/C++.

>>105884112
Are you scared of trying it out? I don't use `cargo vendor`, but I can skim its documentation superficially and guess at what it does.

And an example given is:

cargo vendor third-party/vendor


How is or was third_party/rust/ created in the first place?

Please be more gentle to yourself.

>>105884148
>i asked an LLM but will say i skimmed documentation
>should pass

>>105884148
if you do this command it runs actual rust code on your computer

>>105884208
I'm not using LLMs, but for whatever reason, you seem obsessed with them.

Why not answer the questions? Your image in >>105883830 would be really foolish in case it turns out that you effectively duplicated third_party/rust/ , and then counted LOC. It might fit well with the numbers that you get. But I am not sure what `cargo vendor` would do in the Firefox repository.

>>105880542 (OP)
The future is obviously rust. Wayland, systemd, the linux kernel, and git are all 97% rust. Even glibc, gcc, and clang/llvm are now primarily rust (around 80%). Within probably 5 years, chromium will surpass 50% rust. The biggest things rust did was stabilize their ABI for easy interop, compile faster than C, and freeze and standardize the language itself (which is now supported by three major independently developed toolchains, but let's not forget Fabrice Bellard's tiny-rust, trust).

>>105884293
>would be really foolish in case it turns out that you effectively duplicated third_party/rust/
yes. i committed a big retardation, and should hide in shame for a while.
it turns out, >>105883600 was right after all.

>>105884439
It took me some time and effort to research and analyze. And you may have noticed that I have tried to be careful about what claims I made.

>it turns out, >>105883600 was right after all.
Though, Rust, despite being a newer language that (I believe) has a cleaner syntax than C++, C++ does have issues on that topic, Rust also has lifetimes that hinders ergonomics and makes the syntax more verbose. I do hope for more experimentation (even though such experimentation might be unpaid and unrewarded outside of hobby or university research) into Rust-inspired languages.

>>105883825
Every language except for C++ has networking in the standard library. It's insane how much committee bullshit C++ people tolerate

>>105884626
There are not many systems programming languages.

C does not have networking in its standard library.
Does Swift?
Does Zig?
Does Objective-C?

Does Rust primarily offer networking libraries through its ecosystem, instead of its standard library? Or not?

>>105884439
>>105884608
I am often tired about being correct about things.

>>105883248
Lisp, Fortran, Pascal, PL/I, Algol, and Ada had a lot more than C in less time, but C shills took everything over and replaced everything.

>>105884626
What in the world?
Not even lua has networking in its standard library.

>>105885014
cool, but this makes Rust look even more pathetic now, so that doesn't work in your favor

>>105885034
C shills took over by preventing other people from getting ahead.

>>105883417
>WebGPU
>web API spec
>specified in IDL
>somehow rust is involved
retard

>>105885090
if other languages were really better than c they would succeed despite the roadblocks

>>105885180
maybe the anon got confused by the rust-like syntax, which is clearly something not a single /g/eet is aware of. otherwise, they would have created seethe threads about it, pretending syntax matters most.

>>105885090
>C shills took over by preventing other people from getting ahead.
Lore?

>>105884439
Are you a sore loser?

>>105885014
>but C shills took everything over and replaced everything
Yeah, but it doesn't mean it's a good language.

>>105885826
Just because C. A. R. Hoare invented rust doesn't mean he's right about everything,

>>105882872
Rust as a language
>borrowing
Classic verbage of the banking systems debt based diat currency
>memory safety
Classic verbage of the ministry of truths censorship brigade
>no globals
Classic verbage of the cias tactic in compartementalization and divide and conquor

Rust as a lingusitic construct came from the same halls as DEI

>>105880542 (OP)
C was widely used by many industries by 5
rust is dead

>>105885826
>we should make it easy to write correct programs
>invents null pointer

Is Rc<RefCell<T>> truly the best way to share mutable data between two structs?

>>105884734
>>105885023
Java/Kotlin, C#, Rust, D, Python, Haskell, Go, etc.
Basically all mainstream languages.
Even JeetScript and Flash.
>Does C?
We already established C++ does not, so why would C? Stupid question really.
>but muh Unix sockets
Not standard.
>Does Zig?
Memelangs need not apply.

>>105884734
Also, for your information, Zig does have networking
https://ziglang.org/documentation/master/std/#std.net

>>105886835
>share mutable data between two structs
..and they ask why the borrow checker was needed lol

>>105886636
Null pointers are fine. Just stop writing incorrect code.

>>105886835
In C you just share it. Simple as. No midwit mental gymnastics required.

>>105880874
>are there any known programs written in Rust, anything famous?
nothing.

>>105884361
>wayland
written in c
>the linux kernel
written in c, assembly and has support for rust
>systemd
written in c
>git
written in c
why do rust trannies need to just lie about things that are documented on the internet? it's just embarrassing.

>>105883569
dont forget no std::sql either
at least java has java.sql and c# Microsoft.Data.SqlClient

>>105880874
This is the only relevant thing i can think off
https://docs.astral.sh/uv/
And that's because is the cuck retards managing Python ecosystem whom we're measuring that bar against.
We're yet to see if Typst goes anywhere or is a meme, but that could be a second candidate. Personally fzf is a good third.

>>105887649
typst is really nice
much better than latex in my experience

>>105880874
https://github.com/buttplugio

>>105887649
>fzf
that's written in go

>>105885826
>skill issue in 1994
kek

>>105887834
>in my experience
Which is what? Tinkertrannying?

>>105885826
>Later, Brian Kernighan, who popularized the C language, outlined his criticisms of Pascal in 1981 in his article "Why Pascal is Not My Favorite Programming Language".[46] The most serious problem Kernighan described was that array sizes and string lengths were part of the type, so it was not possible to write a function that would accept variable-length arrays or even strings as parameters. This made it unfeasible to write, for example, a sorting library. Kernighan also criticized the unpredictable order of evaluation of Boolean expressions, poor library support, and lack of static variables, and raised a number of smaller issues. Also, he stated that the language did not provide any simple constructs to "escape" (knowingly and forcibly ignore) restrictions and limitations. More general complaints from other sources[28][47] noted that the scope of declarations was not clearly defined in the original language definition, which sometimes had serious consequences when using forward declarations to define pointer types, or when record declarations led to mutual recursion, or when an identifier may or may not have been used in an enumeration list. Another difficulty was that, like ALGOL 60, the language did not allow procedures or functions passed as parameters to predefine the expected type of their parameters.

>>105880542 (OP)
>Rust is now 13 years old
I expect Rust users will be moving onto a younger language soon then

>>105885826
>make significant concessions
I think this is irresponsible. It is a bit as if he encourages taking the easy path in programming language design, justifying sacrificing important requirements to make other requirements easier to satisfy. I think that approach can be fine in programming language research some of the time, since it can help enable discovering and establishing different abstractions, paradigms, exploration, etc. But a practical general-purpose programming language has to be responsible. And that generally means satisfying a lot of requirements that together can be really, really difficult to satisfy when they have to hold at the same time. Consider for instance C++. One of its main innovations is arguably the culture, formulation and principles of "(runtime) zero-cost abstractions". As if one wants both high-level abstractions, and also performance, all at the same time, not just one or the other at different times, but both simultaneously. This makes it harder to design both the language and libraries. That Rust to a significant degree tried to genuinely follow that principle, is in my opinion a large part of the reason why Rust has been able to get some popularity, and why it was taken seriously as a potential "C++ killer".

[Continued]

>>105885826
>>105888775
C++ is in some ways an annoyingly ad-hoc language, with backwards compatibility and a practical focus. Doing formal proofs for it is not easy AFAIK. But, and this is an understandable-but-large missed opportunity in my opinion, Rust also ended up with significant type systems faults. This was probably a consequence of the experimentation, extreme ambition and early in-practice careless attitude of Rust without initial formalization or proofs. In some ways much like C and C++, except the Rust designers were way more willing to have a complex type system that requires complex solvers, and they had less "responsibility" in those regards. Bjarne Stroustrup was always wary of requiring complex solvers. Maybe he was apprehensive about language designers and compiler developers potentially messing it up royally. Though, if Rust had required formalization and proofs early in its development, it might never have taken off.

[Continued]

>>105885826
>>105888780
https://github.com/rust-lang/rust/issues/31844

600+ comments, lots of blog posts, including some on mental health. https://aturon.github.io/tech/2019/06/25/back-in-the-saddle/ . They also recently locked the issue for discussion.

https://github.com/rust-lang/rust/issues/25860

Another issue with lots of comments, and locked for discussion.

https://github.com/rust-lang/rust/issues/31844#issuecomment-275828169

>We've made some possibly troubling discoveries today, you can read the IRC logs here: https://botbot.me/mozilla/rust-lang/
>I'm not 100% confident about all of the conclusions we reached, especially since Niko's comments after the fact seem uplifting. For a little while it seemed a bit apocalyptic to me.

https://github.com/rust-lang/rust/issues/31844#issuecomment-549028901

>In such a situation, overlapping marker traits are the only hack we can use now, but I think it would be nice to allow in the future some kind of easier solution to express opaque types (as described in my previous post: #31844 (comment)).

https://lcnr.de/blog/2022/02/05/diving-deep-implied-bounds-and-variance.html

>while Rust is a great language and tends to be sound in most cases, its complex trait system together with its fairly organic growth results in some unsoundness and unintended behavior. fixing or even just understanding these can often be non-trivial, which is why I am looking through them to summarize the issues for myself and discuss some potential fixes. any unsoundness discussed here is pretty much impossible to trigger unintentionally and were mostly found by explicitly searching for them

(That last sentence may be completely wrong)

[Continued]

>>105885826
>>105888784
https://github.com/rust-lang/rust/issues/25860#issuecomment-1455898550

https://github.com/rust-lang/rust/issues/25860#issuecomment-1579067138

>Publicized as a language design flaw at https://counterexamples.org/nearly-universal.html?highlight=Rust#nearly-universal-quantification

https://counterexamples.org/nearly-universal.html?highlight=Rust#nearly-universal-quantification

https://github.com/lcnr/solver-woes/issues

>>105887003
>Java/Kotlin, C#, [omitted] Python, Haskell, Go, etc.
>Even JeetScript and Flash.
Are these systems programming languages suitable for writing embedded systems or operating systems?
You didn't answer about Swift or Objective-C.
And C is a valid counter-example.

How complex is the networking in Rust stdlib?

D did not become a widespread systems programming language. I know very little about it. As far as I know, it had some neat features in some regards, that also inspired other languages.

>>105887013
Interesting, I was not sure about that.

>>105884361
>>105887274
I assume it was an obvious troll. The lies of Rust evangelists are generally really different from that kind of obvious trolling.

>>105881758
Rust evangelists are basically reddit programmers

>>105888828
you absolutely can use Python to make embedded systems, granted you use python as a "front-end"
>That's exactly the opposite of what I'm saying
If you have a general purpose embedded systems library, I think you absolutely can use Python to write any system nowdays.

>>105888842
Clearly they do both kinds.

>>105884361
you sound exactly like vegans
>The future is obviously vegan. Vegans tend to live longer, healthier, less obese, less diseases, and make the planet greener. A lot of leading superpowers promote environmental healing and vegan food options are widespread in like 90% of restaurants. The biggest things vegans did was create organic foods that use plant based ingredients to recreate animal products, bla bla bla, bla bla bla...

>>105889209
But the obvious trolling arguably is not really an issue.

>>105889199
I would guess that such a use case is atypical for Python, and that it would have some constraints or drawbacks. But I do not know much about it.

>>105888788
>Publicized as a [Rust] language design flaw at

>>105880542 (OP)
Nim is the cooler rust. Rust is for trannies. Nim is for legends.

>>105890086
>Nim is the cooler rust.
How does being "cool" help with programming? Both are memelangs anyway.

>>105890086
does it still get flagged as a virus by just about every single antivirus package?

>>105887274
>why do rust trannies need to just lie about things that are documented on the internet? it's just embarrassing.
That was a C programmer pretending to be a Rust programmer, which should be obvious to anyone with more than a single-digit IQ. But C programmers actually do lie about things that are documented on the internet, like when they say "C is the first programming language after assembly" and "C is how the computer works" and all their other lies.

>>105891138
Or a Rustacean pretending to be a C fan (do those exist?), pretending to be a Rustacean.

>>105888784
>>while Rust is a great language and tends to be sound in most cases, its complex trait system together with its fairly organic growth results in some unsoundness and unintended behavior

>>105891138
wth is this thing with the "C programmer" persecutory object, are rustoids seriously pushing this? it's so retarded but I don't put it beyond them(/they)...

>>105888187
typesetting all my assignments, retard

>>105888828
>Are these systems programming languages suitable for writing embedded systems or operating systems?
"muh low level language for writing embedded/operating systems" is not an excuse for having a barren standard library and expecting everyone to use a third party library instead. This is just a shitty justification for nocoder trannies on the committee to justify their laziness and inability to add/enrich the language in a timely and appropriate manner.
>Swift and Objective-C
Don't care for Apple iToddler memelangs, but as a matter of fact Swift does have networking capabilities:
https://developer.apple.com/documentation/foundation/urlsession
>How complex is the networking in Rust stdlib?
Existent, unlike C++.
>C
Once again if C++ doesn't then why would C? Not the gotcha you think it is.
>D
It is a pretty great language, and quite a shame it never became popular while shitjeet languages like Go became popular instead.

We need something like in between C++ and Rust. Basically C++ with Cargo + better standard library + not a retard committee that only makes changes that benefit their finance overlords.

>>105892507
>We need something like in between C++ and Rust. Basically C++ with Cargo + better standard library + not a retard committee that only makes changes that benefit their finance overlords.

>>105892366
>shitjeet languages like Go became popular instead.
Go has green threads, which is rare, Erlang and Haskell comes to mind as other languages that have them. Rust used to have some support for green threads, but they were removed AFAIK. Green threads have their advantages and disadvantages. One disadvantage is that it might make FFI and language interop more challenging.

Do you like or dislike green threads?

On the topic of networking in the stdlib of a language, one issue I see is that it can become obsolete. And in a language like C++, which has a large focus on backwards compatibility, a networking library in the stdlib would stick to C++ forever. There is also the question of whether the network library should be minimalistic or not, as well as various other design decisions and goals, architecture, etc.

Does D have a good backwards compatibility story? Was D2 backwards compatible with D1?

>>105888788
What would hinder C++ from getting pattern matching like what Rust has?

>>105894343
c++ doesn't have sum types. so just like std::variant, whatever "pattern matching" they could potentially add would be a special kind of tard, which would be on brand for the bureaucratic committee lead by the glorious nocoder.
but this doesn't matter anyway, because c++ is dead as an evolving language. even the rollingly defined "modern c++" meme is dead now, since there are no "believers" left opting to use the latest c++ version for new non-trivial projects.
c++ usage will live on for a while because of the C+classes subset, plus the few who believed in the "modern c++" meme circa c++11 to c++17.

>>105889391
if obvious trolls troll by supporting something then the actual supporters are the same as the obvious trolls

>>105894944
Troll is you.

>>105894885
Couldn't they add sum types or tagged unions? Or let users generate them through reflection? Or add pattern matching support for std::variant? Or some combination of that?

>>105895902
they could but it would be garbage compared to other languages, even if they don't fuck it up as hard as they usually do (they will). it'll just be another item on the laundry list of "modern C++" features no one uses because there's just not a lot you can do to improve the language without changing fundamental aspects of it.

>>105887137
I'm not sure what your implication is. Mutable shared data is very frequently a requirement (by way of pointers etc). My post around Rc<RefCell<T>> was more a "why is so much verbosity required for something so common"? C++ has the safer "shared_ptr" which is also verbose, but it's not a requirement.

I am genuinely asking if I am missing something here about Rust, because although all the safety is great, it seems like there's a lot of additional complexity/syntax you have to throw in on top to perform common techniques.

>>105896364
>Mutable shared data is very frequently a requirement (by way of pointers etc).
>requirement
>pointers

If you have a problem that cannot be expressed in safe Rust (no macros) then your problem isn't worth expressing. The borrow checker has depreciated all unsafe programs. Cniles are mad that their disgusting memory unsafe, full of vulnerabilities software is now being phased out. Rust won, trans rights are human rights, trans women are women.

>>105892507
>with Cargo
if you actually enjoy this brain damage then D is for you

>>105896674
As opposed to the great solution in C++ that is the great clusterfuck of system provided libraries + manually vendored dependencies + vcpkg + CMake ContentFetch garbage?

>>105896546
Yes? You're just green-texting things I've said, explain what you mean.

>>105896364
use arenas and store keys (indexes) rather than references.

>>105896674
I'm very critical of Rust but to act like Cargo isn't one of the most attractive aspects of it is peak retardation. I think C++ at its core is a superior language in nearly every regard, but As >>105896717 said, the entire ecosystem around it is just a complete fucking mess.

>>105895979
>it'll just be another item on the laundry list of "modern C++" features no one uses because there's just not a lot you can do to improve the language without changing fundamental aspects of it.
What fundamental aspects would hinder or require changes, for the sake of having a good pattern matching feature in C++, in case you know off the top of your head? Or is it more intuition, or experience, or expert opinion, or difficult to explain, or something?

>>105896674
Outside the orphan rule, and some criticism that I am not sure about like https://blog.weiznich.de/blog/cargo-instablity/ , as well as possible in-practice abuse of the Cargo ecosystem where having hundreds of dependencies is typical, is Cargo really that bad? Is your criticism specific to Cargo, or more generally the approach of Cargo, and how do you feel about it relative to C++'s vcpkg/Conan 2, and relative to tools and ecosystems like NPM, Maven, Pip, etc.?

>>105896583
Are the Wayland team Cniles?

>>105896674
I was less hinting at adopting Cargo verbatim, and more like suggesting that there ought to be a tool that let's me specify the compiler, the version of the compiler, the list of the libraries that my project depends on, and a bunch of other configurations, that can be all created in a single file, that seamlessly works on any system that lets me build my project with a single command; Go, Rust and Swift (as far as lower level languages go) have all solved it, meanwhile C and C++ solutions are either half-assed or incomplete.

>>105897158
for starters, you are confusing one of the solutions for a requirement. or in logical terms, you're confusing sufficiency for necessity.
and beyond being this bad at basic logic, you clearly also lack what is basic programming knowledge in the space you're asking about.
but let me be nice and ask you about a precise use-case, and why you thought "share mutable data between two structs" is a "requirement" for it. from there we will see if it is actually a "requirement", then we may ask about how do you want to do "synchronization", which would be the keyword to where that discussion might go.

>>105897452
>https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src?ref_type=heads
Yes.

>>105898119
NTA, but
>and beyond being this bad at basic logic,
Are you the author of >>105883830 ?

>>105898119
>but let me be nice and ask you about a precise use-case, and why you thought "share mutable data between two structs" is a "requirement" for it. from there we will see if it is actually a "requirement", then we may ask about how do you want to do "synchronization", which would be the keyword to where that discussion might go.
NTA, but if one is implementing a high-level concurrency abstraction using low-level features for the sake of performance, is it unreasonable that shared mutable state might end up being involved in the internal implementation?
Does compare-and-swap (CAS) fit the definition of shared mutable state?

>>105898296
that's still too generic a description.
what is the high-level concurrency abstraction?
what low-level features?
shared how?
what are the access patterns and the synchronization requirements? are race conditions okay?
----
fyi, your generic description what Rust does, but maybe not in the way you think.
high-level concurrency abstractions (like Mutex and RwLock) using low-level features (atomics).

>>105897484
C++ should just have a single compiler and single distribution. We should just make Clang the official C++ compiler and maybe polish the compiler output a bit better to produce cleaner error messages like rustc. Fuck the committee, bunch of nocoders coming up with awful ideas that are impossible to implement. At least with Rust new ideas are grounded in realistic implementations and new releases have are backed by actual material usage rather than in C++ where they boast about modules being added in 2020 (literally 30 years after Java and all these other languages had modularized translation units upon release) and modules were unusable until maybe now.

>>105898394
Why did you not answer whether CAS is considered shared mutable state?
>fyi, your generic description what Rust does, but maybe not in the way you think.
>high-level concurrency abstractions (like Mutex and RwLock) using low-level features (atomics).
Lots of languages do it that way.
Aside, some consider locks to be a fairly low-level concurrency primitive.

>>105898296
Retarded post by a retarded poster.
You can only CAS your state if it fits in a size your CPU can do atomic operations on and rust has abstractions for atomics that behave like the C++ memory model anyways.

>>105898507
>Retarded post by a retarded poster.
Are you the author of >>105883830 ? Changing writing style?
Describe yourself in a more gentle way.

>CAS
Yes, CAS has constraints, yet it is still possibly a valid example.
Also, Rust has generally a memory model very close to C++20.

https://doc.rust-lang.org/nomicon/atomics.html

>Rust pretty blatantly just inherits the memory model for atomics from C++20.

Even though it is not fully official.

https://doc.rust-lang.org/reference/memory-model.html

>The memory model of Rust is incomplete and not fully decided.

>>105892787
I personally think green threads are pretty nice. Go is a jeet language, don't get me wrong, but I think goroutines are pretty fantastic to use. Executors are also pretty nice and I guess I'm glad C++ is starting to invest into them.
I get the concerns with networking, since constant evolution is always the complaint that is brought up when it comes to this proposal. But I still feel like a majority of it is quite static, like any IP class or TCP/UDP, even making HTTP requests. This also is a different issue than std::regex where you had a poor implementation rather than rapidly developing ideas, so I think it would be reasonable to want networking.
D2 broke a lot of compatibility in migrating to it from D1, but personally I think C++ ought to do something similar, even if it becomes widely unpopular; the language has collected far too much poor design and I think it warrants re-engineering if it wants to not die a death from a thousand cuts. Backwards compatibility could always be possible using a preprocessor macro for backporting or transitioning.

>>105896674
>cargo le bad
Give one good reason to continue using vcpkg which never even works, verbose 2000 line CMake setups split across 10 files and using FetchContent, or manually installing all the libraries to your system through your OS package manager, or going back to writing 5000 line Makefiles (compiles slower than Ninja which requires CMake because Ninja is never manually written).
Meanwhile
>cargo build
>cargo run

China is going to win so bad while retarded nocoders are falling for Russian anti-Rust psyops and jeets screeching at anything requiring >90iq

>>105898119
>>105898394
>Be an unclear, smarmy greentexting fucking moron
>"Uhh but let me be nice, sweetie :) can you please provide a contrived example of WHY you would want to do this?"

Peak Reddit. I can't tell if you're being obtuse for the sake of defending Rust conventions, or because you're just an actual autist. In either case, you're a fucking retard. Just to be clear, are you saying there is NO use case for more than one part of a program to manipulate the same piece of data directly? Yes or no answer, leave your faggot hang ups about the definition of "requirement" at the door.

>>105898630
>D2 broke a lot of compatibility in migrating to it from D1, but personally I think C++ ought to do something similar, even if it becomes widely unpopular; the language has collected far too much poor design and I think it warrants re-engineering if it wants to not die a death from a thousand cuts. Backwards compatibility could always be possible using a preprocessor macro for backporting or transitioning.
I am personally way, way, way more in favor of something like modernity-checking profiles, which would be suitable when upgrading and refactoring an existing codebase, or when starting a greenfield project.
I do not agree at all with breaking backwards compatibility, at least not for C++.

One could imagine languages like Carbon doing something interesting while having compatibility of some kind. Can modules be used or abused for this? On the JVM and .NET, different languages have interop, like Java, Kotlin, Scala and Clojure, and C# and F#.

I have not heard much from Carbon. I do not know whether Carbon has a working, public compiler. It has been some time, and research is research, but I would expect something that can be run, eventually. Yes, a language like Carbon is necessarily realy ambitious. At least Carruth is learning something, I guess. https://youtube.com/watch?v=8SGMy9ENGz8

>>105898630
>>105898851
Circle was never open-sourced, which confuses me. I am also not sure if the author had been made aware of the risks of programming language research/development outside universities, as https://youtube.com/watch?v=XZ3w_jec1v8 talks about. There can be a lot of work without any kind of payoff or reward in programming language research, which is not something everyone appears to be aware of or appears to have been made aware of. I think it would be very good if there was more awareness of that, even though we each are responsible for ourselves. I hope Sean Baxter knew what he was going into when he started the project years ago, but I could fear that is not the case. Do share the above video link, to help raise awareness.

>>105898730
What a web of delusion you've spun, lmao. Touch grass my dude.

>>105898630
>This also is a different issue than std::regex where you had a poor implementation rather than rapidly developing ideas, so I think it would be reasonable to want networking.
I think different language design features should in C++ have different evolution and testing phases and processes. Some features are suitable for one kind of practical testing, other features are suitable for other kinds.
C++ may also have ISO whitepapers going forward. Before that, TS? And implementations in specific compilers? Maybe with pattern matching, gcc and Clang (the compiler codebases themselves) will be easier to develop on.

Rust has unstable, where users can opt into unstable features, and some features end up being stabilized. Not without drawbacks, and some users for instance complain about Rust features being stuck in unstable for years. Not sure what the most significant drawbacks are. Rust also has editions, which is not a silver bullet, and the results of which may take more years to really reveal themselves. Though it is interesting. Rust also has a lot of language design communication on Github, Zulip, and its own forums. Less on Github and more on Zulip, the last few years, I reckon.

Java has JEP and a number of preview stages. I do not know much about them.

>>105898730
>Russian
What?
>anti-Rust
Generally nothing wrong with being able to openly and honestly criticize topics without fear of censorship.
Also, what about those rolling for a C++-Rust successor?

>>105898394
>>105898764
Monologue?

>>105881093
>and theyre still not at a proper version 1

>>105899063
He said proper version you fool

>>105899088
it is a proper version thoughbeit

>>105898971
>he thought all the "rust is 100% pazzed trust me bra" content is organic
lol

>>105889402
I remember playing around with korean robots, that had a very specific python library used to program them and upload like in an arduino chip.

>>105880542 (OP)
>Rust is 13 years old
When it becomes legal age will the trannies stop being interested in it?

>>105880549
Lmao good one.

>>105880874
Tons, influxdb, ripgrep, you can look at an awesome rust github if you want.

There are hundreds of good software written with it.

>>105880874
https://github.com/rust-unofficial/awesome-rust?tab=readme-ov-file#applications

>>105900949
>not 1 (one) useful novel application
damn

>>105900969
https://typst.app/

Get fucked.

>>105899063
>>105899088
>>105899120
Monologue.

>>105899274
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292

>>105898651
>manually installing all the libraries to your system through your OS package manager
Because cargo is a bad package manager and in my os I have the best package manager in the world. Why should I have 2 package managers in my system if one is enough?
>vcpkg
Is it something from windows? Bro... I'm deeply sorry for you... Programming language is not the problem here.

>>105901426
>and in my os I have the best package manager in the world
Not portable
>muh muh le skill issue or something
Go back to rèddit then

>>105901458
>Not portable
What?

>>105888784
>>105888788
>Rust type system
>apocalyptic
>hack
>Publicized as a language design flaw at

>>105880549
Maybe Jon Blow should watch >>105898860

>>105888187
it can do everything latex can but 10x simpler, and more

>>105888138
i really hate go but you can build good software with most resonable software.

fzf is nice software.

other rust software is great.

i don't care what it's been written on, as long as it's good.

i do have a preference for rust software as i like using rust and thus it's nicer to contribute changes if i want to change something but appart from that i don't care.

>>105903768
I thought it still missed a lot of functionality relative to what is available in the Latex ecosystem.

>>105880549
Jai hoe saar

>>105898465
Be careful. If they made one official compiler that works everywhere with standardized ABI and it always up to date with the newest changes, they might accidentally make a sane, useful language. It could even allow them to do such a drastic, controversial thing like testing new features before putting them into the language!