>>107763272
lost

>>107763272
Syntax should be much closer to C, but at least it defaults to const.

>>107763284
Rust is not a C replacement THOUGH. Even though people try to use it as such.

File: fact.png (40 KB, 341x498)

40 KB PNG

>>107763272
Good language but no OOP or exceptions is trannypilled

File: image.png (195 KB, 640x500)

195 KB PNG

>>107763295
You lost. Get out of here!

>>107763284
C should be more closer to Rust

>>107763272
I'm still not convinced of the ergonomics of blocks being expressions even if, from a consistency standpoint, it makes sense. They should have picked a better name than "unsafe". The macro system in general is poorly documented and specified; I should not have to use some retard's library (syn) to have any hope in writing these things.

>>107763470
Everything being an expression is one of my favourite things with Rust.

>>107763491
Same. It's so.. expressive...

>>107763272
The truth about Rust is that it actually isn't that good for (relatively) low level programming. The closer you get to the metal, the more you have to fight the borrow checker. I don't know why years ago it was shilled as being good for low level but it just isn't, Zig is way better for that.

However, the further away you go from the metal, the better Rust becomes.

File: 1700399481399546.jpg (140 KB, 1024x1024)

140 KB JPG

transgenders

>>107763536
>The closer you get to the metal, the more you have to fight the borrow checker.
And how did you come to that conclusion?

>>107763536
Only true if you write your code like a retard anyways. Obviously if you don't want the safety guarantees that Rust provides, don't use it, but you will suffer for it later.

>>107763598
Experience. The borrow checker is hostile to low-level patterns

Low-level code often relies on:
>Alias-heavy data structures
>Self-referential memory
>In-place mutation across layers
>Pointer re-interpretation
>Cyclic graphs
>Partial initialization

Rust demands that you prove what your doing is safe at compile time or it won't let you do it.

So you end up with:
>unsafe blocks everywhere
>Lifetime gymnastics
>Phantom types
>Marker traits

Low-level code:
>This is a chunk of memory. I know what I’m doing.

Rust:
>This memory obeys these invariants, for all future refactors, under all generic instantiations.

That’s great for APIs, libraries, and mid-to-high level systems but like a giant black snake in your ass when writing:
>kernels
>allocators
>drivers
>runtimes
>hypervisors
>embedded HALs

Rust fucks after you leave raw pointers behind. The very second you start to wrap memory in safe abstractions, encapsulate unsafe behind invariants, move into async, concurrency, serves, ECS, simulation, networking, Rust becomes a kino language worthy of praise.

>>107763294
It can do anything c can.
Not that i'd always use it over c but for 95%+ of project it's a better pick than c or cpp imo.

>>107763295
>no oop
Traits are superior by very far.
>no exceptions
Brown.

>>107763667
never had these problems

>>107763667
>Alias-heavy data structures
>Self-referential memory
>Cyclic graphs
use arenas such as Bumpalo, Slab, or Slotmap
>Pointer re-interpretation
again, use arenas. stop allocating for individual elements, it's misuse of your allocator.
your "allocator" in Rust should be standard data structures, such as boxed slices (for a quite literal translation of malloc), Slab (for random removal with array access performance), Slotmap (for slabs with generational semantics), etc.

>>107763272
>write hello world
>compiler takes 10 GB of disk space and produces a 5 MB executable
Good language, would language again.

>>107764430
skill issue

>>107763272
it being pushed by so many govs and agencies while most code uses unsafe is enough to turn me off

>>107763272
dynamic linking, rusties?
compile times??? lol

cargo and the million of micro libraries is a supply chain attack waiting to happen
would rather keep cargo but have more some form of packages containing multiple libraries at the expense of duplication, but fine control over linking

something like you depend on the tokio package, but only link against the runtime/io/etc depending on your use case (and tokio is like a monolith instead of depending on other shit)

it's bad because it is too difficult to learn

there are two types of languages:
the ones everybody says is flawed
the others nobody uses

>>107764555

lack of a stable abi is good call too, but the language is still incomplete (async iirc still has some rough edges)

>>107764597
nobody forces you to use cargo

>>107764605
>lack of stable ABI
it's called "C" ABI and it is stable and fully supported, but why would you want this when you're already using Rust and not some slop that would need to depend on something to do with "dynamic linking"?

>>107764622

LGPL-compatible Rust libraries

>>107764622
>but why would you want this when you're already using Rust

To interop with Zig which I use for the low level stuff that Rust sucks at.

File: 1760293542259159.png (236 KB, 640x483)

236 KB PNG

>>107763272
C# is better.

>>107764841
No, I'm this guy: >>107763667

>>107763272
It's really good for the kinds of tasks it's good at, like web servers or CLI tools, but holy fuck does it suck at anything stateful.

The Rust UI library situation still is a disaster.
Also, everyone who has tried to make a game engine in it has failed. Everyone. Sometimes you just need fast iteration, even if it's unsound for the moment.

I generally like it, it creates fast, native cross platform programs that don't use much RAM and unlike C++, devs like it. I'm grateful to anyone who creates programs in it rather than fucking node.js.
I just wish its fans were more willing to accept that it has weaknesses and some of them are so systemic they might never be fixed.

>>107764893

The UI situation is a disaster in C++/etc, there are no good crossplatform native UI frameworks out there.

Unironically, GPUI that is written in Rust might be the one good one but still early days.

File: 1754950228548952.png (32 KB, 780x783)

32 KB PNG

>>107763995
Filtered by exceptions.

>>107763986
Agreed. I want to avoid see peepee.

>>107764893
yes, it should be language in your toolbox.
I do not use Rust to write most things. for some things, it makes plenty of sense (compiling to webassembly for doing things like crypto in a browser, high performance data structure exploration, etc.). otherwise you should be using a very high level language like Clojure.

>>107764893
>I just wish its fans were more willing to accept that it has weaknesses and some of them are so systemic they might never be fixed.
this is how i feel about it too. rust is a fine language, albeit one i don't really see myself using, and while i do think it has a place and purpose, it shouldn't be some kind of neo-techie religious conviction to be either for or against it. rust is seen as a political statement rather than a technical one because no one really wants to discuss the shortcomings of rust objectively, the community is only interested in the replacement of languages and paradigms and ideas that they don't control with languages and paradigms and ideas that they DO control, which is childish and self-defeating and reflects poorly on what should be a purely technical discussion.

>>107764893
UI sucks in general. The only good UI paradigm is a widget tree, which is what React has with hooks, what Qt and GTK do, and what Flutter/Jetpack Compose/SwiftUI do. On this front Dioxus does a decent job of replicating React, but there isn't an easy way to make an efficient widget DSL.

>>107765062
It's really a shame. I've been using Rust for about five years now and recently got into Zig but ugh, the Rust community. I don't know what's wrong with these people, they're cultish and abrasive. I just want to build. I hope they can be eventually pushed out by people who have work to do, not a religion to spread.

>>107765086
>>107765062
I haven't seen this phenomenon in languages other than Rust and Haskell, frankly
In the Rust User's world, the Rust way and the Correct way are synonyms. All the things that Rust enforces are good practices even outside of Rust, and everything that Rust doesn't do or does poorly is a code smell and/or something a good engineer shouldn't be doing anyway. It's dogmatic to a degree I haven't seen elsewhere.

But they're unwilling to acknowledge that it's a trend - OOP took over, and Java developed a specific style of OOP, and now everybody is on the pendulum swing against that style of OOP, and despite Rust being an OOP language by its core principles and paradigms (it's the logical endpoint of C++ lifetime/move semantics, statically enforced), they say it's not OOP because it's not cool to be OOP.

But all things came about for a reason, even if they were (and are) misused - inheritance has a use, even non-virtual inheritance has a use, common fields in parent classes have a use, arbitrary function overloading has a use... etc etc etc

There's a reason that Rust is primarily used for things where your 'state' is an external database, and your program can be reduced to a pure function, JSON in, JSON out, and it's because it's straight up not good at handling state.

>>107765193
Ehhh, I don’t really agree with the point about Rust and OOP. Rust supports encapsulation and polymorphism just fine but it avoids is inheritance-centric, class-hierarchy OOP.

Encapsulation in Rust is strong: modules, privacy, and visibility give you explicit control over boundaries. Polymorphism comes from traits, both through generics and dyn Trait, without forcing everything into inheritance trees.

Where Rust puts it's foot down though is shared base-class fields, deep hierarchies, and override chains. Those patterns interact poorly with move semantics and local reasoning about memory, so Rust pushes composition and explicit data ownership instead.

On the state point, Rust isn’t bad at handling state so much as it refuses casual shared mutable aliasing. You can model complex state, but you have to pick an ownership strategy explicitly (arenas, handles, ECS, message passing) rather than letting references float around implicitly. It's why Rust scales better as systems get larger and live longer.

So I don’t think the whole “Rust is secretly OOP and pretending otherwise” applies. It supports core OOP ideas without making inheritance the organizing principle, which puts it on a different axis than Java-style OOP.

>>107764984
Only browns want exceptions, monadic error types are better in every way. you are the one being filtered saar

File: unknown.png (181 KB, 1024x1024)

181 KB PNG

>>107766284
You are a gojeet who thinks spamming if err != nil everywhere is super idiomatic and high IQ, when it is clearly not

>>107766284
>monadic error types
use haskell then. rust doesn't have higher-kinded types, ergo it doesn't support monads or monadic error handling

>>107766451
NTA, and you're right that you can't define a concept of a monad in Rust, but the built-in support for the ? operator for the specific cases of Result<_, _> and Option<_> gets you what you need in 99% of cases. It's equivalent to do-notation and is definitely monadic error handling.

File: Screenshot_20251205_121706.png (313 KB, 1385x1578)

313 KB PNG

>>107766284
are you sure?

>>107766539
right, but with proper monadic error handling, you'd be able to say "actually, I want to handle exceptions by throwing and catching exceptions" and have the code be exactly the same except for the monad you're using

>>107763272
>such a joke of a language that damage control threads promoting the logo
> like it's an exercise in brand recognition because the mega corporations funding rust are discovering that nobody is actually using it for anything important

tranny language. and it took 10 years for microsoft to actually use it in windows despite sitting on the rust board for all that time? lmao. google only started using it in last few years after sitting on the rust board for just as long? embarrassing.

>>107765193
>>107765321
>chatgpt slop
you sad and embarrassing losers don't even realize just how sad and embarrassing you actually are.

>>107767261
i don't know why i keep going back to read /g/eet tardations and losing intelligence points

let stable_try_block_via_closure = || {
 // use ?, return Option<()> or Result<(), E>
};
if let Err(e) = stable_try_block_via_closure() { // or if let None
  // catch
}

>>107767382
Damn, lil bro, way to let that insecurity show.

File: 1746752489885708.jpg (242 KB, 600x600)

242 KB JPG

Rust enums are just so good that they make me not even bother anymore with any language that doesn't have an ergonomic equivalent

>>107763491
also this

>>107763272
Trademarks have serious freedom flaws, to the point where distros are removing or blacklisting rust.

>>107769666
>distros
It's more than one?

It devolves into cancer once you cross the threshold of 10k lines

>>107771477
That's all programs, regardless of language.

>>107771488
>>107771531
I guess, yeah

>>107763667
>Alias-heavy data structures
use case?
>Self-referential memory
use case?
>In-place mutation across layers
use case?
>Pointer re-interpretation
use case?
>Cyclic graphs
only retards use pointers for graphs
>Partial initialization
use case?

>kernels
https://rust-for-linux.com/
>drivers
https://rust-for-linux.com/nova-gpu-driver
https://rust-for-linux.com/tyr-gpu-driver
>embedded HALs
https://github.com/rust-embedded

>>107766659
holy shit, wtf is this? how retarded are you?

>>107766659
Anon you're retarded

File: Screenshot_20260105_131048.png (512 KB, 1568x1783)

512 KB PNG

>>107772497
>>107772623
point out retardation

>>107772684
literally everything of this is dumb and retarded to the max.
try using c#/java/go/python.

File: Screenshot_20260105_131441.png (165 KB, 587x1697)

165 KB PNG

>>107772702
I write Clojure now
btw, what is dumb and retarded? can you explain in plain English, so that I can verify you actually know what you are looking at?

>>107772726
just add a postgres error variant to the createaccounterror enum, dumb retard.
>&String
just use &str, that way you don't have to do &"".into() etc.

File: 1725683141935411.jpg (153 KB, 1080x1080)

153 KB JPG

>>107772767
>just add a postgres error variant to the createaccounterror enum, dumb retard.
no shit, now make this work with a transact function that takes a generic closure. oh look, the need for a trait!

>>107772789
>write shit code
>write more shit code to work around shit design decisions
>somehow come to the conclusion that it's the languages' fault

File: 1733042811230984.jpg (38 KB, 720x720)

38 KB JPG

>>107772865
offer solution
actually I don't care, I write Clojure now
get mogged by my editor's REPL, compile-fag
lmfao gottem

>>107764790
Unironically not needed since the Rust community uses pushover licenses everywhere.

>>107763272
It attempts to put at the center of the stage some of the most rarely needed and impractical solutions for memory management the default. While this makes the language "SAFE" it also makes every single person using the language to write needlessly complex programs. Modern C++ attempted to do the same over and over with different features, and most people hate C++ because of this. Rust developers pretend people hate C++ because of muh raw pointer unsafety and not because all the gobbledygook features that align in spirit to rust.

>>107773086
Rust feels like a modern c++ apologist throwing a tantrum after he wasn't allowed to make part of the project code style the idea that smart pointers should be mandatory.

>>107773170
Give me a good reason why they shouldn't be.

>>107773086
I use custom memory management scheme and data structures and Rust still werks.

>>107773222
There are several kinds of memory problems related to how long term and how well ownership is defined. Memory problems are very rarely about memory that will remain for most of the program and is hard to guess who will own it. Some instances of these problems exist, but in general, when you feel like you have a problem that needs to be treated as long term, complex ownership, you actually have a much simpler problem you didn't want to think about well enough, or worse, you have a much simpler problem that you are trying to "prematurely optimize" towards "future proofness", "scalability" or etc.

Now, these problems DO exist, and you might need to have some tools to do that. Smart pointers might be enough. However bending backwards and pretending all memory problems are of this elusive category where you just don't know for how long you will have it and you will have so much trouble tracking who has it and who frees it, and require these tools and that just passing a pointer is a sin because you couldn't possible know! (when in fact, most of the time you know), is silly. It's a waste of time and it makes for more complicated programs.

>>107765062
>C is seen as a political statement rather than a technical one because no one really wants to discuss the shortcomings of C objectively, the community is only interested in the replacement of languages and paradigms and ideas that they don't control with languages and paradigms and ideas that they DO control, which is childish and self-defeating and reflects poorly on what should be a purely technical discussion.
Rust is one of the few languages where users discuss the shortcomings of C, so C shills waged their war against Rust.

>>107765193
>I haven't seen this phenomenon in languages other than Rust and Haskell, frankly
>In the Rust User's world, the Rust way and the Correct way are synonyms. All the things that Rust enforces are good practices even outside of Rust, and everything that Rust doesn't do or does poorly is a code smell and/or something a good engineer shouldn't be doing anyway. It's dogmatic to a degree I haven't seen elsewhere.
C is worse. C shills defend null-terminated strings even though they were already obsolete and known to be bad before the original 8086.

>>107773851
where the hell have you been? cniles hate null terminated strings and curse several of the problems the language has. You are interpreting rejection of your rube goldberg machines as enjoying the language.

>>107772890
Clojure makes too many trade offs to be worth investing time into. Once you step outside making webshitter backend #129012919 then its a high chance you will be limited by what you can do by the speed of the language. Also the recommended "just use hashmaps in places where structs and enums would be used" is fucking retarded and just papers over the laziness of Rick - no other lisp does this and Clojure deserves the death it suffered because of this. If you are going to use a slow, slop lang then at least use a decent one like Scheme/Racket.

>>107767889
you realize that try/catch isn't just syntax sugar right? exceptions are implemented differently than option/result

>>107773825
I asked for a single good reason, not a wall of uninintelligible gibberish.

>>107773976
https://web.archive.org/web/20161125094132/http://benchmarksgame.alioth.debian.org/u64q/clojure.html

premature optimization is literally the devil. Clojure allows me to build the shit I want to build as easily as possible. it's not just for web shit, there are a lot of fintech applications doing data-science-esque shit with Clojure. Clojure can trivally interact with the entire JS ecosystem, JVM ecosystem, and much of the Python ecosystem (including Pandas and Numpy).

>>107774297
Your code style suggestion is still getting rejected, but now the code review has turned into your exit interview.

>>107769452
It's great compared to not having them at all, but they're extremely verbose for no reason. Why do I have to write everything twice?

struct Onething {}
struct Another {}
enum OneThingOrAnother {
    Onething(Onething),
    Another(Another),
}

>>107774139
an exceptions-tard doesn't know anything about underlying implementations, and would only retardedly (as always) use this argument post hoc ;);)
and my point was to show that the "exception workflow" is a subset of what's possible with proper errors-as-values implemented via sum types* (which can also retain or even add proper contexts for the errors). and this point still stands.
a person experienced in /g/eet tardations can immediately recognize that "FOO is good" is not in any way an informed statement/opinion about "FOO", but rather a trivial COPE stemmed from "i only know BAR which has/uses FOO".
*do note that exceptions-tards talk(ed) about "if err != nil" as if it's the only way, in response to mentions of monadic solutions no less. you can extrapolate how much they actually know from that.

>>107773086
>>107773170
This would ALMOST make sense if the language had special syntax sugar for putting things inside a Box<T>, which would be the equivalent of a c++ smart pointer, but there is no such thing. It's simply not true that smart pointers are especially important in Rust.
If you learn Rust the regular way there's really no moment where you are nudged into putting everything into individual smart pointers. You'd probably end up putting most things in vecs, hashmaps or similar.

>>107769666
This is what worries me the most. I'm not a Rust user, but the licencing worries me.
Which distros are blacklisting it? I haven't noticed Arch maintainers doing anything about it.

>>107774310
>premature optimization is literally the devil.
This quote was taken widely out of context. I means you do not optimize parts of the system that would yield next to no speedup and it doesn't mean you should just churn out slow shit and ship it to users because it's faster for you to do so. Also those slow downs compared to java are fucking wild given they should be compiling down to the same bytecode and are utilizing the same runtime.

>>107763272
Static typing zealotry is such a spiritually castrated activity. I also find its premise of "correctness of the program is in the types" pretty deficient --tests are what gives you confidence that your program is correct, not types. The compiler can be a tool, but it's not the holy grail or anything.

When push comes to shove, to do a lot of worthwhile things in the language you need unsafe calls, and that throws the whole premise of the language out the window as well.

Lastly, the politics in the Rust community are pretty kooky and cultish and no reasonable person should associate with those types.

>>107774855
I've used Rust to build very highly-performant, niche data structures (a trie-based concurrent data access transactor/message broker, hash table that outperforms Google's Swiss Table often (while maintaining DOS resistance), custom encoding algorithms, etc.).
>I means you do not optimize parts of the system that would yield next to no speedup and it doesn't mean you should just churn out slow shit and ship it to users because it's faster for you to do so
- speeding up hot code in Clojure is trivial. just use transients. not fast enough? add type hints. not fast enough? use Java's imperative data structures. not fast enough (lmao, are you sure)? port to Java. not fast enough (are you spending your time on this planet wisely)? port to Rust and use JNI.
- users want a working solution. if you think that writing good code in Clojure and wisely using data structures (the most important characteristic in performant code) is difficult, you are wildly incorrect.
>slow downs compared to java
you dramatic ass motherfucker. if your production system cares about minute differences like that (optimized Clojure is FAR faster than Python, Racket, Lua, Perl, Elixir, etc.), then just pay someone to fix those problems for you. I am a one-man team (as of now) trying to build cool shit. I do not give a single fucking shit about absolutely perfect performance. you want me to write Rust loops, doing SIMD and shit? that's a waste of my time on Earth. programming, the computer itself, they exist as tools for me, a human, to conjure into existence that which I want. Clojure makes this as easy as possible, out of the wide array of languages I have used.

>>107775122
what an odd way to say you are unemployed but will do anything for a few shekels

>>107775218
I remember trying to optimize some minor algorithm (Python) in a previous job I had working with a product in use across 11 hospitals/cancer research institutes. my manager told me it was a waste of time.

>>107775122
You sound like a vibecoder. Do you vibecode, anon?

>>107775334
no, I only converse with AI to get ideas/clarify things. I write my own code.

>>107774610
This is being worked on alongside variadic generics so that you can just write something like `OneOf<Foo, Bar, Baz, Fab>`

Until that's resolved, there's crates like `either` or `frunk` that do this.

>>107775441
>I use AI, a bullshitting algorithm, to confirm if I am right or wrong and to give me ideas.
That's a creative way of admitting that you're retarded.

>>107775122
It looks like Hans Peter Luhn himself has risen from the grave. How long before your novel hash table finds itself in every stdlib?

File: I'm kinda a big dill.jpg (67 KB, 555x669)

67 KB JPG

shemale thread for a shemale language

What was the problem Rust was created to solve?

>>107776016
Turning GNU licensed software into MIT licensed software.

>>107776016
Random memory bugs crashing your application.

>>107776016
To fix common bugs that occur in C and C++ programs. What problems were C and C++ created to solve?

>>107766366
I literally hate go, go doesn't have monadic errors retard.

>>107774464
No, I accept yours first.

>>107776098
What do you think of Rust's type system?

File: 1748381237928959.png (118 KB, 336x308)

118 KB PNG

>>107763272
It suffers from what i like to call the Freecad problem. If a newbie asks a question i have a very hard time giving an answer without jumping through three different things along the way. An worse, if they ask how i knew i don't even have an answer when or where i learned about it.
That said, i'm getting paid decently for using it.

>>107773170
Smart pointers are not mandatory. Core Rust doesn't even have any dynamic memory allocation by default.

>>107763272
Genuine criticism from a guy with a job: prototyping in Rust kind of sucks. Often times I just want my program to run, spit out a result, and then crash. Rust requires that throw-away code has the memory safety of production code. The borrow checker should be warn by default on debug builds.

>>107776313
I think it's one of its strength, traits also allow to write libraries you typically couldn't write as well without them because their implementation is separate from type definition.
That means you can implement a library trait for your own type / library or implementation your own trait for a library type.

This is what allows serde to be that powerful for example as you can now write libraries that expect types implementing their traits.
And you can then have third party libs implementing it ie serde json.

>>107775240
Indeed it is, because cancer research isn't real. The chemicals they use here remind me of morons searching for elixir of eternal life and consuning toxic shit that only drives them insane and kills them faster than if they did nothing at all, same goes for cancer "treatment".

>>107763986
>do anything c can.
make an executable that fits on a tiny microprocessor? compile on an ancient computer?

>>107779268
Usecase for ancient computers?

>>107763272
Unneeded and astroturfed political language. 13 years old still no one cares.

>>107764893
Bevy is a decent “game engine”. I have a sim with shallow but broad AI agents and can get 20k agents moving at 140fps on a 2015 thinkpad. But it is not very fun. I think I’m going to try doing something less causal in Love2D or some shit

>>107767382
unless they made a model work overtime to emulate the grammatical shorthand peculiarities of the 4chan userbase those are human posts. LLMs can do it but the instruction tuned chatbots generally won't want to

File: 1750547809930463.png (24 KB, 1248x82)

24 KB PNG

>>107779326
>no one cares
You no one in your circle of losers? Rust is gaining traction just fine.

>>107779409
You mean*

>>107774945
you won't know you've written a correct program until you test it, and even then it's just a probabilistic belief.

add all the tools you want, if someone uses them wrong the program still won't do what it's supposed to.

>>107779303
usecase for buying a new computer?

>>107779409
Bro it's been a decade and a half. It's going no where. Why are you are a sycophant for a programing language lmao. 2 more weeks!

>>107779439
Flexing on poors.

>>107763272
wtf this tranny language is STILL being shilled?

>>107779446
>It's going no where.
Literally every corpo is using it.

>>107763295
>no exceptions
how do you handle exceptions then?
>inb4 write better code faggot
no

It embraces dependency hell. I don't like that because of it

>>107779466
>yea I know that cniles love early access and making millions of people test their buggy slop, what else is new
>tfw rust trannies don't test their slop

>>107782613
people that say shit like this don't even understand the problem domain that is dependency handling
you're like a child saying "what if the gravity stopped existing" or some other nonsensical shit

>>107776638
> .unwrap()
> .clone()
> todo!()

You don't need more.

>>107763667
Another funny thing is I must've read dozens of 'I fixed the borrow checker for graphs' type blog post, where they always come up with the genius solution of putting everything in an array, and using indices for references. And when you point out that they've literally bypassed lifetimes and the borrow checker, they will vehemently deny it, or claim the code is still safe because you can't index out of the array.

>>107764053
Yes use some shitty library that's full of unsafe code and is probably broken and dangerous in a dozen fundamental ways.

It's no problem since in a years time the Rust people will realize this, build a rewrite and smugly dismiss all criticism of the language with 'oh you are using the old thing, only idiots do that'.

I swear they are like Js devs.

>>107765321
anon, the good thing about C++ and other languages is that they don't force your hand. Deep inheritance and overridden method chains is very rare even in the OOP world, most people don't write code like this. The only places I can think of this is used, and is a good practice, are some frameworks where you have to inherit from some base class (for something like an endpoint controller).

There's not one true Java or C++ way, you can write code however you want.

>>107785181
>use some shitty library
have fun reinventing wheels and working on problems with solutions outlined in existing computer science literature.
>claim the code is still safe because you can't index out of the array.
correct, this is still safe when using the standardized definition of safety in the context of the Rust programming language. why are you fucking about with the definition of words?
this problem is purely one regarding your business logic of keeping various data assets in sync. you have to do the same shit in Python.

you are completely ignoring the massive performance benefit of not constantly allocating btw.

>>107785610
I love when I present an issue that allows for both mutable aliasing and use-after-free you simply redefine what safety means. But what this actually means that for large subsets of C programs, there exist equivalent Rust programs that borrow check perfectly yet suffer from the same potential memory related bugs as the C one does.
.
Did you know that when you malloc something you're not getting memory from thin air, but you're essentially manipulating a data structure, that assigns you a memory address to use? The only difference being that the language and the compiler is not aware of said structure. That's why malloc is a function in C, not a language feature.

If you think that this is acceptable then why do we bother with the cumbersome borrow checker at all? After all, you pointed out, this is still safe, and faster too. You could write C++ with bounds checked STL enabled, or write Zig, which also has this level of safety built in.