>C++ is unsafe!!!!
Um... just use smart pointers?

Reference counting is slow.

Doesn't solve the problems.

>>105681089 (OP)
enjoy your use after moves

>>105681103
Then use unique or weak pointers

>>105681089 (OP)
why do you need pointers anyway?

>>105681204
You are ESL

>another rust vs cniles topic

Lel. Learn lisp.

>>105681242
Because large data structures require allocating memory on the heap

>>105681254
lmao, its a non-issue
just use a deque or vector and emplace that shit

>>105681249
"C is not C++" I say as everybody in the audience jumps up in excitement, drowning the room with the thunderous noise of cheering and clapping.

>>105681272
Youre retarded

>>105681089 (OP)
for me the point of rust is entirely besides the safety bullshit. in fact, i think the safety detracts from what is otherwise a really nice systems language.
c++ for better or worse is still just "c with classes" with a 2nd language tacked onto it. the problem is that neither "c with classes" nor templates are particularly nice to use, and they are full of deficiencies and shitty ergonomics.
rust has plenty of problems with ergonomics

also smart pointers are slow. rust lifetimes are calculated entirely at compile-time. that's the point, it's like compile-time garbage collection.

>>105681324
Why hasnt someone made a rust like compiler for C that checks for memory safety at compile time

>>105681235
>unique
Runtime error. Half baked and nowhere near as powerful as Rust mutables. No way to force their exclusive use, there is no safe code in C++.
>weak pointers
Also slow.

>>105681424
Cyclone was Rust's predecessor ... but cniles weren't interested.

>>105681424
that was one of the proposals for the c++ comitee. you could turn it on or off to just get your shit done if you need to. of course they didn't approve it but the code exists

>>105681089 (OP)
the problem with rust is it tries to do too many things at once. instead of working from c to functional programming it goes the opoosite direction which ends up being annoying for the people the language is for. it wants absolute safety with no undefinedness whatsoever. this means the parts of rust that work and the parts of it that failed in practice are fatally intertwined.
nim's answer is better anyway

>>105681089 (OP)
shared_ptr is pure bloat

>>105681553
>the people the language is for
The language is for people who think C/C++ is irredeemable. Rust just ignoring C programmers was part of its success.

Projects like Cyclone/SaferCplusplus/Safe-C++ fail to get traction because they try to appeal to people who by and large simply don't believe compiler enforced safety is necessary for them ... they will never compromise.

>>105681694
no, rust's success came from the massive corporate backing it had because the syntactic and semantic paradigm of the language was distinct enough from c to convincingly launder copyleft code into permissive clones.
autists being ever susceptible to propaganda happily did their bidding for them. it is open source's final form

>>105681089 (OP)
std::shared_ptr<std::mutex> my_mutex = std::make_shared<std::mutex>();
std::lock_guard my_guard(*my_mutex);
my_mutex.reset();
But I used a smart pointer?

>>105681089 (OP)
segfault with smart pointers

example1
#include <iostream>
#include <memory>

struct B; // Forward declaration

struct A {
std::shared_ptr<B> b_ptr;
~A() { std::cout << "A destroyed\n"; }
};

struct B {
std::shared_ptr<A> a_ptr;
~B() { std::cout << "B destroyed\n"; }
};

int main() {
auto a = std::make_shared<A>();
auto b = std::make_shared<B>();

a->b_ptr = b;
b->a_ptr = a;

// Manual attempt to dereference potentially invalid pointers (not needed for leak, but for crash demonstration)
a.reset(); // Normally would destroy A, but A is held by B
b.reset(); // Normally would destroy B, but B is held by A

std::cout << "Done\n";

// At this point, A and B are not destroyed due to circular reference
// Now simulate later use-after-free or memory pressure causing crash
// (Not guaranteed here, but common in real-world circular reference misuse)

return 0;
}


example 2
#include <iostream>
#include <memory>

struct Test {
void say_hello() { std::cout << "Hello from Test\n"; }
~Test() { std::cout << "Test destroyed\n"; }
};

int main() {
std::unique_ptr<Test> ptr1 = std::make_unique<Test>();

// Transfer ownership to ptr2
std::unique_ptr<Test> ptr2 = std::move(ptr1);

// Now ptr1 is null; dereferencing it causes a segmentation fault
ptr1->say_hello(); // Segfault: ptr1 is nullptr

return 0;
}

>>105681424
because it requires a substructural type system, which is fundamentally incompatible with any pre-existing c code, and would probably look like complete shit in c's grammar.

>>105681858
make it inferenced

>>105681235
Weak pointers are deprecated

>>105681424
>Why hasnt someone made a rust like compiler for C that checks for memory safety at compile time
Because you can't. C has no concept of memory safety, so you can't check for memory safety.

>>105681694
>The language is for people who think C/C++ is irredeemable. Rust just ignoring C programmers was part of its success.
Rust didn't ignore C programmers enough. They still copied the retarded C/C++ syntax which lets C shills say "C invented everything in Rust" instead of making a normal syntax which would show that C didn't invent anything.

>>105681103
no, it isn't

>>105681103
95% of Rust programs (serious programs, not cmdline utils and immediate mode GUIs) use Rc<> anyway. And the Rc<>'s implementation is 5-6x slower than std::shared_ptr

>>105684452
shared_ptr doesn't have the same safety characteristics of Rc. It's not thread safe by default and you can do use after free.
Also see >>105681741

>>105681254
That doesn't necessarily mean you need pointers in the language. You could design the system to allocate memory in fixed-size pages or arenas and use indices (or handles) instead. The key is whether the language needs explicit memory references or if abstraction over memory (like indexing or handles) is sufficient.

Keep in mind that your pointers are already virtualized by the OS/MMU so we're already dealing with an abstract interface.

>>105681840
These type of toy examples do demonstrate a problem with programming, but it's a problem that exists in almost every language - in the time domain of performing actions out-of-order.

The solution is to always represent your programs in stack order so that disassembly is the reverse of assembly and dependencies flow from that natural order. If you don't rig up your program that way, it's really your fault for implementing a fragile program in general.

>>105681089 (OP)
Rust's borrow checkers run at compile time so it's zero cost abstraction.
Smart pointers do the check at runtime which is slow.

>>105685707
In this case if A and B have a dependency between them, one should be a parent struct and the other should be a child. Of course then you'd find your ordinary destructors are good enough and you don't even need the smart pointers.

>>105681103
Compared to what exactly?
What's faster than a couple of atomic instructions when dealing with object ownership?

>inb4 rust's burrows
nigga those are very limited.

>>105681089 (OP)
What happens if I free(T)?
What happens if I pass T through a FFI but then it goes out of scope in my program?

>>105681324
you're dumb

>>105685707
You are literally describing lifetimes.

>>105681089 (OP)
Why is it a wide pointer? Why isn't the control block prefixed to the T object?
It would improve cache locality and prevent wasting registers with wide pointers.

>>105681089 (OP)
In C++
Smart pointers have no invariant of holding a value. You can not initialize, or reset() them, then still use operator* no problem. Rust's Box always holds a value, having or not having a value is another structure's abstraction. Even if you remove the default ctor and reset, in C++ the moves are also non-destructive, so everything is forced to double as optional anyway because it needs to be valid in a moved-from, valueless state.
Then there's the issue of enforcement. There is absolutely nothing stopping you from calling operator* on a smart pointer, whether it's valid or not. You could use get() to handle some possible invalid states, but then you have an exception interrupting your flow. Rust has conditional scope-based access. Constructs like if let, let else or match arms only give you access to a nested value inside a scope that's only evaluated if your desired state variant is the one that's present. You could replicate this with something like a unique_ptr::run_if_valid that would take a delegate to run in case it holds a value. But that breaks normal flow of code into callbacks unnecessairly.
And at the end of the day, C++ has raw pointers and references. You WILL use them to refer to objects held by smart pointers while not owning them. The rug can simply be pulled from under those at sny moment by changing the smart pointer.

>>105685755
Atomic instructions are like 6 ns each on Intel CPUs. Half of that on AMDs.
>>105686737
>Why isn't the control block prefixed to the T object?
It can be if you create object using make_shared. But shared pointers are supposed to support taking ownership of externally created objects too.

>>105683982
Of course you can. If you can run static analysis tools on C you could build a rust style borrow checker/lifetime tool for it.

>>105681089 (OP)
We should change the name of pointers according to the rapist-victim paradigm.

>>105681089 (OP)
Because rust is trying to inject it's npm/pip like package management cancer and introduce dependency hell into everything.
>inb4 you can just reference packages manually
Yeah, try that without some rust faggot having a tranny tantrum.

As soon as you use a smart pointers you're admitting you should have used a language with garbage collection.

>>105687141
but unique pointers have no overhead

>>105681089 (OP)
"smart" is an ableist term, that should be reason enough not to use raCist++

>>105687224
Raw pointers or garbage collection. Everything else is akin to natty cope you see on /fit/

>>105687141
>what are layers
when you represent a problem domain without use of garbage collection, you have removed a layer of computational complexity. you move up in the chain of complexity as needed.

>>105686625
Yes. Your point? Just structure your program correctly and the lifetime will flow from the structure. One way to accomplish that in C++ is to use inverted inheritance/mixin style programming to build up a chain of templated structs and then use a variadic function to chain them together, allowing you to use namespaces as your selectors so you can insert/replace anything in the chain. Then your using statements will refer to the actual struct or class they require a function or member from which enforces, at compile time, an order to the production of a program. The "stack effect" or lifetime flows from the constructors/destructors.

Do this and things will always be called in the correct order, created in the correct order, destroyed in the correct order... and because it uses inheritance it naturally prevents you from creating cycles.

No rust needed.

>>105687862
>Just structure your program correctly
Segmentation fault (core dumped)

>>105687829
Ok but I don't get your point. You are adding back a version of garbage collection. Why not use a decent one instead of the shitty ones Rust and C++ offer?

>>105687877
I used this method to wrap Vulkan where other people were having lifetime issues with smart pointers. I had no issues at all with segfaults.

Because if class B needs a member from class A the using statement within class B referring to class A will force you to place class A before class B. This gives you comptime assurances that everything was done in the correct order.

In fact you can force other libraries into this same structure and create dummy references to stuff you may not actually use in that class just to tell the user that they should have created X before Y... whereas the original code would create a runtime error.

>>105687884
btw it's not garbage collection. garbage collection is classified by 3 distinct parts:
- periodic scanning of all memory. all memory must be checked. reference counting does not require checking all memory, nor does it require periodic scanning, because it is only triggered upon the counter hitting zero.
- defragmentation of memory.
- updating of existing references upon the referenced memory moving to a new address due to defragmentation.

>>105681089 (OP)
It's always amusing when you try to explain to rustfags the small changes you can make to the way you program in C or C++ to avoid lifetime issues whereas their "sell" is to just switch languages entirely to one that adds all sorts of unnecessary complications and syntax/semantic adjustments.

They don't want to solve the problem, they want you to join their cult.

>>105688162
picrel

>>105688162
post code

>>105688217
Create a lifetime issue while remaining within this chain that doesn't look absolutely contrived.

// Forward declaration
template <typename T, template <typename> class... Ts>
struct ProgramList;

// Base case: no more templates to apply
template <typename T>
struct ProgramList<T> {
using Type = T;
};

// Recursive case: apply the first template to the result of applying the rest
template <typename T, template <typename> class T1, template <typename> class... Ts>
struct ProgramList<T, T1, Ts...> {
using Type = typename ProgramList<T1<T>, Ts...>::Type;
};

template <typename T, template <typename> class... Ts>
using Module = typename Default::ProgramList<T, Ts...>::Type;

struct Startup {
static const ARENA_SIZE = 1_MB;

Startup() {
// or could be loaded from a config file
}

~Startup() {
}
};

template <typename Import>
struct Whatever : Import {
using Import::Startup::ARENA_SIZE;

Arena a(ARENA_SIZE);

Span<char*> someData {};

Whatever() {
a.Create(someData, 100);
// exit on failure
}

~Whatever() {
}
};

template <typename Import>
struct Whatever2 : Import {
using Import::Whatever::someData;

auto SomeFunc() -> void {
for(auto& c : someData) {
c = 'N';
}
}

Whatever2() {
SomeFunc();
}
};


using MyProgram = Module <
Startup,
Whatever,
Whatever2
>;

auto main(void) -> int {
MyProgram();
return 0;
}

>>105688442
>cniles think this is acceptable code

>>105684452
You are talking out of your ass. Rc is faster than std::shared_ptr since it doesn't deal with atomic operations by default. If you want concurrency you use Arc instead.

>>105688442
you cannot represent all programs in this manner.
you do not have the ability to represent safe APIs (such as the progression of a contract from being a draft, to sent, to signed) with a guarantee that reversal of state cannot occur.
also, there is absolutely nothing preventing you from using arenas with Rust and entirely avoiding the need to write lifetime annotations. see `slotmap` and `slab`.

>>105688162
I can change the way I program and how I write programs. I can not change the ecosystem at large. C++ programmers are notoriously bad, and that's not changing anytime soon, if ever, since the language itself refuses to do anything but grow larger and more convoluted.
It makes sense to abandon ship into a language that has a much higher floor of quality, than stick with one that requires the programmer to arbitrarily carve out a subset of the language to utilize since parts of the language are supposed to be avoided but must still be included. Even a bad Rust programmer is going to produce a program or library that at least builds and executes, I can't say the same for even professional C++ programmers. Let alone anything beyond that first step.

>>105688517
It's very acceptable. The use of using statements creates a contract that ensures order of construction is followed, otherwise you get a compiler error. You know because order of construction is followed you can count on data being valid when you access it anywhere down the chain. You know it will all be cleaned up at the end.

You don't end up with these free functions that have unstated dependencies on other free functions being called.

>>105688554
>you cannot represent all programs in this manner.

and by all you mean bad programs

>you do not have the ability to represent safe APIs (such as the progression of a contract from being a draft, to sent, to signed) with a guarantee that reversal of state cannot occur.

I'm not sure exactly what you're talking about here but you can apply using statements as private to lock their use out of anything after some transition. (let's say you go from UEFI allocations to your own allocator and you need to make sure they aren't used after you leave boot services)

>>105688580
The "ecosystem at large" is always going to incorporate things beyond your control including languages other than the dreaded ceeples. You think you're trying to grab C or C++ by the balls and fix it with a new language, people structuring their code the way I do are just trying to grab C++ by the balls *within* C++... But no one can really grab everything by the balls, we can just do so within our own small domains that we control.

I'm not saying everyone should structure their code the way I do or that it actually can solve all problems, but I've noticed that if I do structure it this way then I don't really have segfaults.

Philosophically it's a form of anti-communism. If you force hierarchy, order and structure on your program from the beginning then it means there's only a limited number of ways to write a program. It's why you have these egalitard notions that all things are equal (a function is just a function bruv, call them in any order) that shit breaks down - like the example of creating cycles someone else posted.

>>105688531
It literally is slower ...

holy shit, stop yapping. nobody cares.

>>105688656
>Philosophically it's a form of anti-communism. If you force hierarchy, order and structure on your program from the beginning then it means there's only a limited number of ways to write a program

You mean anti-anarchy? communism has hierarchies, they just operate within the party structure, Leninist structure of vanguard party (inspired by the way Catholic Church operates actually)

>>105688554
I should also add that with this module list approach you can also have a kind of poor man's VCS. You just keep the struct and its signature the same and you put it in another namespace, then make your own modifications. The namespace becomes a "selector" for the new behavior.

Ex. one could be Sdl::Draw, another could be Sdl2::Draw. Or you could attach a programmer's name to it - then make your own chain to test your changes without causing problems for the normal, default program.

>>105688656
>I'm not saying everyone should structure their code the way I do or that it actually can solve all problems, but I've noticed that if I do structure it this way then I don't really have segfaults.
I am of the opinion we should have cohesion and that these guidlines you're making yourself, should be enforced as the standard, hence why it makes more sense to jump to languages that have them. This is not even unique to Rust and Rust wasn't even on my mind when I wrote the other post.
The fact that C++ programmers can't read+write the same language is evidence of a language that is too large to be of benefit to anyone in a practical sense. The exceptions are far and few between and worse, require this same level of forcing your own standards to a whole team of people on top of the language, which renders it no longer just C++, in the same sense that MISRA isn't just C.

>>105688748
Yeah I probably shouldn't have mentioned communism directly because it does take the form you describe in actual reality though Marx defined it more like anarchy at the final stage.

But the point is if state is not "contained" then you can't enforce order. Being able to call malloc/free anywhere is an example of that. It's too free and it has side effects. But if it's contained within the scope of some hierarchy, locked into constructors/destructors/arenas, etc and you never leave the hierarchy it works just fine.

Now stuff that doesn't have side effects or dependencies doesn't need to be captured - but in that case you could just keep it within the hierarchy and make it static instead.

>>105688785
No language has some of the thing I want though. I haven't given considerable thought to it but I did experimentally consider the idea of exposing compound types/unions as a typemask instead of the way it's done currently:

typemask x = u64 | i64 ;
var myvar: x;


It just explicitly exposes types as the way they are actually represented in the compiler so you can control what types x will support and do unions at the same time without all of the template typename crap.

I also thought it might be interesting to be able to have fused functions.

So if you have two functions in a hierarchy that bear the same name you could refer to them generically:

using funcNameWhatever;

and that would create an array of function pointers you can iterate through and call all of them if you want - or if you wanted to pick out a particular one then a struct name would be exposed as an enum:

funcNameWhatever[someClass]();

I might even be tempted to get rid of the this keyword because it would no longer be a pointer but an enum/index.

But those are just experimental ideas, I haven't actually tried to create some kind of compiler to test them out.

>>105688965
Fused functions sound interesting to me simply because they are more natural when you think about it. If you call out "John!" in class and three kids stand up and say "here!", then that's not really an error, but most compilers force specificity on you and treat a lack of specificity as an error.

I think it could come in handy for doing a kind of multicast or multicast groups for propagating changes back up the hierarchy - you get asynchronous behavior without any new keywords, simply by changing the classification of what would otherwise be an error.

>>105688442
Aren't you just jacking off over dependency injection and circumventing C's declaration order nonsense? You can probably do the same thing in Rust with parametrized types, except more readable.

>>105689058
I don't find it unreadable; the opposite, in fact. I can read every struct created, look at its explicitly stated dependencies and then know where the calls it is making came from. Those using statements become a form of documentation.

And as for the chain of types, how is it any worse than, say, a makefile? It essentially almost replaces the build system. Namespaces allow you to centralize every facet of cross-platform programs in one place and the module list gives you the flexibility to move things around as you discover you hadn't modeled the program correctly.

>>105689126
I think you're hacking together templates to get features that any sane language would give you out of the box.

>>105681089 (OP)
>forget to copy pointer (refcount increment)
>pass it incorrectly to caller
it still is. I still see segfaults for leaking shared_ptr because the dev was a dumb nigger bitch like (You).

>>105686818
>And at the end of the day, C++ has raw pointers and references. You WILL use them to refer to objects held by smart pointers while not owning them
What's wrong with using raw pointers as observers? There's literally no risk unless you're doing multithreaded procedures, if you have a unique ptr or a shared one and it's valid and you produce a scoped raw pointer the pointer is going to be valid.

>>105688554
>you do not have the ability to represent safe APIs
so?"???

>>105689326
you can just take my word that making bad states impossible to represent is good, or you can be burned in a few years from now by a bug where you created a bad state
I really do not get what is so fucking difficult to grasp about it being good to use the automation of a compiler to automatically discover/prevent bugs
like, we write software to automate shit. that is the entire fucking point of programming. and all of a sudden automating bug discovery is bad? it's a fucking retarded ethos to have

>>105688661
Then show proof

>>105681089 (OP)
C++ is designed by a faggot committee that circle jerks instead of passing new features while Rust is just directly implemented top down.

>>105689583
>making bad states impossible to represent is good,
actually its impossible a bit flip can happen

>>105689583
ya, but it's tranny so it's bad. simple as.

>>105691906
>actually its impossible a bit flip can happen
not in the abstract machine defined by every programming language ever defined.

>>105686818
no offense, but that sounds like some fucking tranny gobbledygook

>>105688162
>one that adds all sorts of unnecessary complications and syntax/semantic adjustments
but enough about C++ and its 50 revisions

>>105692126
in c you dont use bool you use 0x55555555 for false and 0xAAAAAAAA for true and do a checksum every time you read the variables because there can be bit flips comsic rays hit your cpu this is basic embedded programming

>>105692378
C does not define cosmic rays and their interactions.
I don't care what retarded shit you do.

>>105692391
you may not like it but this is what professional programming looks like

>>105692399
no, it's what retardation and cargo cult programming looks like. you shouldn't be using an abstract language for this use case. software should not be handling SEUs, no matter how hard you cope. It literally makes zero sense to anyone with a basic understanding of C and computers in general.

>>105692271
and on that continuum rust becomes complete revision 50 + 500 more, then 670 deprecations, 400 complete replacements.

>>105681254
Use memory arenas.

>>105689234
Show me another programming language where I can join a bunch of subprograms into a program in one centralized location instead of having to explore N files and change every dependency without the faintest idea where to start and how long the job will take.

>>105692848
Java if you use Guice. Probably Rust with liberal use of parametrized and dependent types.

>>105692824
nice projection C++nile

No thanks, I am sticking to Rust, honestly.

>>105693289
Missing the point. My question is why should I start over completely on some new language that's going to go through the same upheavals when I've already found a path through what I have?

It would have to be a complete paradigm shift to be worth it.

>>105681249
Whenever you see the word "cnile", you know someone's taking good aim at a strawman living rent free in their head.

>>105686818
>match arms
why don't someone add pattern matching to c++?

>>105687877
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>105688580
>I can not change the ecosystem at large. C++ programmers are notoriously bad,
>a language that has a much higher floor of quality
Then why did I end up fixing a bunch of bugs in a Rust repository, that the Rust developers of that repository apparently were too incompetent or careless to avoid/fix?

All the Ruby-to-Rust devs, or the "democratizing systems development", or "systems development for everyone", doesn't help either. Sure, making programming easier is good in isolation, but making it easier at any cost, like lying about quality, is not necessarily good.

I've often been disappointed in the works of Rust developers. Some Rust developers were early movers, innovators, interested developers, liked ML/FP, etc., and those can be competent in some cases. But others just choose Rust because C or C++ were too difficult for them, and when Rust turns out to be too difficult for them as well, they often become cultists and start hustling. I'm not interested in fixing the bugs of Rust developers for them. Rust developers running Miri, shouting "Memory Safety!", and hoping for the best or for others to find and fix their bugs, without understanding what they're doing, isn't competent nor responsible.
This isn't limited to obscure or small Rust projects. Both larger Rust projects and the Rust standard library has many times suffered from UB. And having no UB is less than the bare minimum in regards to requirements for most projects.

C++ is also easier than Rust in some cases, for instance in some usages of the unsafe superset of Rust. You can dispute this if you want, though I request that you personally master and can explain tree borrows and pinning.

Rust cultists will never admit these problems, however, making the problems 100000x worse. And I haven't even touched on all of Rust's major problems.

At least pattern matching in Rust is nice.

>>105681089 (OP)
If I'm using reference counting I might as we use Vala, which also means the syntax isn't ass.

>>105696329
I use languages that have libraries

>>105695917
unsafe was used by Crossbeam. this is not a failing of Rust's compile-time safety, but of manual memory management, which C/C++ force into every single aspect of your codebase.

>>105696339
>unsafe was used by Crossbeam
And by Rust stdlib developers, since the UB double-free bug was present in the Rust stdlib as well. Whether they merged the bug or wrote it themselves matters not, since they failed to detect that UB bug. And the Rust stdlib has had lots of other UB.

Sorry, you can't escape
>Rust
>Segmentation fault (core dumped)

The authors of that blog post recommend using ASAN, Valgrind and Miri with Rust.

Try again.

>>105697963
>The authors of that blog post recommend using ASAN, Valgrind and Miri with Rust.
rust fails at its only reason to exist and the devs still can't recommend C++ over it with a good conscience. o i am laffin

>>105681089 (OP)
yup this is a good thread thanks for the thread this is a very constructive thread

>>105689326
Trannies are obsessed with anal where it's important to be safe or you can get a life-threatening infection. They apply this to everything.

>>105698024
>dereferencing pointers is anal sex
interesting analogy

>>105698031
That's not an "anal"ogy. I'm describing a general principle of tranny psychology. I call it TAP (Total Anal Projection)

>>105698039
>says trannies are projecting
>makes an analogy about how dereferencing pointers is anal sex

>>105698048
Clap it out with me sister
>THAT
*CLAP*
>WAS
*CLAP*
>NOT
*CLAP*
>AN
*CLAP*
>ANALOGY

>>105681424
there is fil-c but that's more in the run time.
There are static analyzers for C.

>>105698069
>mostly upper case
Why does it bother you so much? I think you anal sex analogy is interesting btw.

>>105697979
Pattern matching and (properly functional) modules/crates are cool, after all. Despite all the issues with orphan types.

>>105698081
I'm mentally insane

>>105698089
>can't stop thinking about trannies and anal sex
>admits to being mentally insane
interesting

>>105698096
I only think about them in certain 4chan threads and several times a day when I see tranny flags plastered on shop windows etc

>>105698104
sounds like an unhealthy obsession to me considering sane people (like me) don't immediately think about anal sex upon seeing a rainbow

>>105698116
I know I'm not Allowed to think about them, but it's going to happen anyway I'm afraid

>>105698116
>>105698150
Also rainbows are one thing, but I see the poo/pink/blue flag multiple times a day and its meaning is unmistakable.

>>105681424
There are different approaches, with different benefits and drawbacks.

Rust's approach and concrete language design has its drawbacks, like
- Difficult-to-reason-about escape hatch in the form of its unsafe keyword. Look up tree borrows and pinning and the aliasing model of Rust not yet being specified, as well as the UB occurrences that Rust libraries and applications have in practice. Instead of trying to understand Rust's semantics for unsafe, many Rust developers rely on Miri. And there is a lot of UB that Miri has no chance of catching in practice.
- Difficult-to-fix fundamental bugs in its type system. Polonius as I understand it only mitigates some of these fundamental type system bugs, doesn't fix them, due to backwards compatibility.
- Rust's borrow checker severely constrains some types of designs and architectures. The consequences of this ranges from mild annoyances with easy work-arounds, to making Rust as a whole not a viable contender.

Expanding on the last bullet item:
- Typescript compiler is being ported to Go, not Rust, because it fits the existing architecture better https://github.com/microsoft/typescript-go/discussions/411 https://www.youtube.com/watch?t=760&v=10qowKUW82U https://old.reddit.com/r/rust/comments/1jbsxel/what_would_be_the_performance_difference_of/
- Memory handling through arenas is a popular approach in Zig and C. Due to Rust-the-language and Rust-the-ecosyste/-libraries, this is not always as easy in Rust https://old.reddit.com/r/rust/comments/1jlopns/turns_out_using_custom_allocators_makes_using/ https://old.reddit.com/r/rust/comments/1km2vej/bump_allocators_in_rust/
- Game engine architecture options are possibly limited by the borrow checker, and the ECS architecture of Bevy (the main Rust game engine) has not necessarily proved its trade-offs are worth it a lot of the time, with many game developers abandoning Rust. https://old.reddit.com/r/rust/comments/1k83suv/do_people_who_use_rust_as_their_main_language/

>>105681424
>>105698458
https://old.reddit.com/r/rust/comments/1km2vej/bump_allocators_in_rust/ms7nn35/
>One maybe not so obvious benefit of using arenas in Rust is that it trivializes lifetimes, because the arena IS a chunk of lifetime. That's why we use it, because prior to that we had this fleet of different buffers pre allocated and attached to other data structures, and we regularly ran into problems with the borrow checker. Now we just chuck those buffers into the arena and don't have to worry.

Could one imagine a successor language to Rust that has as good or better memory safety, is way more ergonomic, is easier to reason about also in the worst cases (ie. esoteric unsafe code), does not have fundamental type system bugs, is way more flexible regarding program designs and architectures that the language is good at enabling, and has better compile times? Maybe, but the Rust language developers aren't honest about Rust's actual strengths and shortcomings, making it harder for the global programming language development ecosystem to learn from and improve upon Rust and make good successors to Rust.

>>105698492
>t. seething cnile

>>105698507
Nope, try again. I prefer FP languages, at least when they're a good fit for the task at hand.

>>105693475
>why should I start over completely on some new language
that's pretty much every single C++ revision since C++11 in a nutshell

>>105698024
what a strange thing to say

>>105689297
There is still no guarantee you wont get your shit invalidated.
>>105695902
Because it took waiting till C++20 to get a fucking contains in map. It also doesn't have tagged unions in the language layer, so it would need to use a hack like tuple_element is for structured bindings

>>105698492
sounds like nim

>>105688580
whats funny is that because of all the "people" tranisitioning to rust, the average skill of C++ programmers increased significantly. thanks for that I guess

>>105687946
>periodic scanning of all memory
used (also some memory can excluded but that's nitpick)
>defragmentation of memory.
garbage collection don't have to be generational
(or movable for that matter)

>>105696329
>Vala_Logo_New
How did a dead language get a new logo?

>>105701076
collective IQ increased from 60 to 70

>>105681089 (OP)
RUST -> TSUR -> TS UR -> UR TS
Rust is the "You're tranny" language.

>>105699832
OK now try to imagine that Rust is a C++ revision. That's what these people are trying to sell, a complete reset for some marginal benefits. No C++ revision has ever come close to the type of retooling Rust people want.

>>105685723
>called zero cost
>actually compilation times increase

>>105685723
In Rust, all the places that have panic-checks inserted in the compiled output, do not have zero cost at runtime, right? Since the panic-check implies a cost.

>>105706262
> panic checks
Go has them too. You see _chkstk calls left in stuff from Visual C all the time.
It's not supposed to put them in if the compiler can "prove" to itself that they're not needed.
I sometimes just end up NOPing-out any bullshit I don't like in a post-processing pass on the object code.

In general, a lot of these features are designed to be enabled during testing, and then compiled out of the final.
Unfortunately, many people in rust advocacy circles have the magical idea that, merely by having it exist and compile in rust, means that you don't have to do any testing.
Rust people should be a little more discriminating in who they let into the community.
Look at what happened to Java.

>>105696339
> unsafe was used by Crossbeam
So the solution is clear: ban any use of unsafe.

You just know in any SW dev sweatshop they're going to add unsafe whenever they run into compiler bitching and whining so they can go home at 3:30.

Go into your C/C++ dev shop and ban the use of pointers and the heap. And calloc().

Probably improves the performance. I see stuff where they're malloc()ing fucking temporary ints for christs sakes.

>>105706494
its too bad nobody who uses rust has heard of code review they think the compiler relpa ces that

>>105706434
>Unfortunately, many people in rust advocacy circles have the magical idea that, merely by having it exist and compile in rust, means that you don't have to do any testing.
>Rust people should be a little more discriminating in who they let into the community.
>Look at what happened to Java.
I'm not sure that I am getting your points.

>>105706494
>So the solution is clear: ban any use of unsafe.
But if you want to do certain operations efficiently, or need to do certain operations like FFI that requires it, unsafe is needed. And the UB was also in the Rust stdlib.

>>105705833
Rust is the best C++ revision ever. You get all the fancy functional programming features without the legacy cruft and you get things like type safety, no UB by default and that's before we get into the borrow checker and memory safety by default.

>>105706787
>has heard of code review they think the compiler relpa ces that
I know logic isn't a strong suit with you people, but that's literally the logic the cnile you replied to used.

why not java

>>105707798
>certain operations like FFI that requires it, unsafe is needed
Doing certain operations DIRECTLY requires it. Just like directly doing file io, networking or displaying graphics requires kernel mode.

>>105708341
Uhm sorry anon, hobbyists, students and dropouts doing "C with classes" in 2025 decided it sucks, actually.

>>105681089 (OP)
In theory rust has no overhead for the same safety. In practice the rust borrow checker is a massive pain in the ass and prevents feature changes without a full rewrite of the codebase everytime so everyone uses rc and other boxes. Therefore you are right.

>>105708341
Worst revision. Changes everything for no reason and its killer feature is highly overrated.

>>105708391
Was it you that posted those posts you're referring to?

>>105710155
No, retard

>>105710876
So it was you. Nice flamebait. And do stop referring to yourself as a retard.

>>105711015
>am I just a fucking retard that agreed with a post engaging with the exact shit I'm complaining about?
>no, I bet it and the post pointing out how retarded I am were actually made by the same person that made the first post on purpose knowing I would agree with them and while also making a hipocritical complaint so they could point it out
Anon, you.... ARE CORRECT. I saw you were investigating what those darn trannies were up to on onlyfans the entire night so I thought you would be too tired to notice my dastardly plan. Damn, foiled yet again

>>105711713
Didn't read your flamebait.