Thread 105806228

>Ctrl+F
>Rust
>0 results
What happened?

>>105806228 (OP)
Rust dev teams failed the async & await aspect of the language by releasing an MVP years ago and making exactly zero progress regarding making it easier to make async runtime agnostic crates since then. This is absolute bullshit, I don't fucking want to use tokio.

>>105806228 (OP)
I love Rust so much its unreal
If Rust has 10000000 fans I am one of them
If Rust has 10000 fans I am one of them
If Rust has 10 fans I am one of them
If Rust has 1 fan that fan is me
If Rust has 0 fans that means I joined the 41%

>>105806228 (OP)
Rust has won. No need for sloppy psyops any more.

>>105806228 (OP)
Shills are no longer being funded by Globohomo due to free money drying up. When interest rates eventually reach 0 expect shilling to pick back up again.

>>105806228 (OP)
USAID money dried up

>>105806605
No sirr Rust open source full independent sirrr

>>105806228 (OP)
another memelang is going the way of Ruby

>>105806260
>>105806284
>>105806311
>>105806312
>>105806605
>>105806640
>>105806650
tsmt keked hard

>>105806260
I never understood retarded comments like this. C and C++ are objectively worse at reusable async code.

>>105806260
Also all you need in 90% of cases is futures. If your crate uses it, it will work fine on all the major runtimes. The 10% are harder like timers, which is where you depend more on the runtime semantics. You're extremely overblowing how bad it really is though.

>>105806228 (OP)
>Ctrl+F
>Rust
>1 result

>>105807412
I'm not comparing it to C or C++, I'm saying that Rust is my general purpose go-to language for writing everything and the async fucking sucks
>>105807438
My async library needs IO types, timers and task spawning and that really applies to every large async library

>>105807516
Why are you using a language that needs a 3rd party runtime to be usable for what I presume is webdev?

>>105806228 (OP)
Faggots and trannies are too busy with the pride

>>105807516
Ok and tokio and async-std has those. So you don't need to worry about real problems. So why do you fucking care again?

>>105807412
>>105807516
async without gc is just retarded. adding coroutines to C++ was a mistake. don't know about Rust, but I imagine it can't be much better.

>>105806311
>Rust has won.
This is true. Even regarding the last non-Rust component in the build chain (the linker), wild knocked mold out of the park already.. before even getting to implementing incremental linking. It's literally not even a competition anymore, especially when it comes to new projects.
>No need for sloppy psyops any more.
There are/were no psyops, except a potential russian anti-Rust one, and even that is probably overstated/exaggerated, and their /pol/-tard tactics don't work on real developers anyway, just tard "consumers".
Even the supposed greybeards' resistance is overstated, although my view of that aspect is probably colored since i'm a (youngish) greybeard myself (literally) and I liked Rust since day 1. The older greybeards are all retiring anyway.
/g/ is mostly jeets talking to bots. This became even more true after the site got hacked, since many non-jeets never came back (including myself, I just open /g/ ~twice a month to check out trending tardations). The jeets seething about Rust are mostly juniors and sophomores. So maybe it's just exams/post-exams season LOL

>>105807810
That's (You)r opinion. Some people like not having to ship a whole GC for something that doesn't need it.

>>105807823
async and GC are orthogonal. so no, there is no context where the jeet tard (aspiring C# wageslave would be my guess) is expressing a valid "opinion".

>>105807516
PEBKAC. Rust async is quite nice now and is a good brainlet filter.

>>105807562
It's not web dev
>>105807775
Do you not understand? I need my library to work with every async runtime and I absolutely do not want to use your monopolist tokio and async-std libraries.
>>105807905
You're using tokio I bet, now trying doing anything useful with async with any async runtime that isn't tokio

>>105807812
this insanely insecure post is indicative of the overall "little-brother syndrome" about rust.

>>105808100
>I need my library to work with every async runtime and I absolutely do not want to use your monopolist tokio and async-std libraries.
what does your totally real library do, and why isn't runtime-agnostic?
if you don't need runtime-specific behavior, then your code will be runtime-agnostic without you needing to do anything.
if your code needs runtime-specific features, then you can write support for the common run-times easily, or use a third-party shim to do it for you. it's very easy if you're not retarded.
the only other option from rust's side would have been making the run-time specific behavior as a part of the language/std, i.e. making tokio itself a part of the standard/implementation. in other words, you are effectively arguing against your own argument, a sign of larper, or a retarded drone.

>>105807812
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

>>105808248
>what does your totally real library do
It handles and responds to messages received on a UDP socket and it does it without any input from the library user, response messages are sent on timeouts and in response to data that was received on the socket.
>why isn't runtime-agnostic
It is, but only because I had to write it in a generic way using traits I defined myself and then implement these traits for common runtimes. But that's what I'm talking about in the first place - you can write runtime agnostic libraries, but the Rust's async WG dropped the ball and haven't been working on anything to make writing runtime-agnostic libraries easy and natural, despite it being explicitly a goal in the past, around the time when async & await was first stabilized. It's a shame because Rust is such a nice language otherwise.
>making tokio itself a part of the standard/implementation
If you're talking about the "I don't want to use tokio" part, then that would actually be fine for me, I'm only against being forced to use third party libraries that force you to write your application code in a specific way (instead of just forcing some library X that uses that third party library like tokio to write code in a specific way), being forced to use whatever is in the stdlib doesn't bother me.

>>105808416
>(instead of just forcing some library X that uses that third party library like tokio to write code in a specific way), being forced to use whatever is in the stdlib doesn't bother me.
i mentioned this before months ago, and maybe you were in that thread. but rust lang team decisions around this were proven right, since io-uring came out shortly after, and nothing being "forced" allowed for new run-times to emerge that utilize io-uring to the maximum.
there were aspects around async rust that may have been rushed a bit due to the huge pressure to deliver early (e.g. pinning stuff), but this is not it. and it worked out well enough in the end, i think.

>>105808653
Well I don't mind not having a standard runtime, that's fine since there are different use cases like embedded, but they gotta do the runtime agnostic stuff and put into the stdlib because doing anything network related or especially web related is very difficult if I don't want to use tokio because all the libraries use it, rewriting everything yourself is absolutely unrealistic

>>105806228 (OP)
trannies ACKED

>>105806312
Most Rust threads are made by people who don't like Rust though. They do it for free.

>>105808352
The peak of throwing random shit to see what sticks.

>>105807810
>don't know about Rust, but I imagine it can't be much better.
It actually is. There is no hidden random allocations like in C++ and composing tasks actually works.

>>105808692
it was always the intention to put more async traits in std over time. i think that's what you're talking about, and it is what is intended to actually happen. although it is probably taking a longer time than it should. but it is also understandable. the type system itself wasn't ready after all (e.g. async in traits haven't been stable for long), and some aspects are not ready even today. so it becomes a balancing act when to deliver, and when to take your time from the rust teams' perspective.
i don't follow rust's progress closely anymore desu, or care about the minute details behind the surface. i just write code that works and call it a day. it's been "Good Enough" for a while.

>>105808803
>it was always the intention to put more async traits in std over time
Yes, but they're literally not doing it. If they can't add AsyncRead, AsyncBufRead, AsyncWrite in 5 years, then how long are we going to wait to get traits for timers and spawning tasks? Even then, I bet libraries will hard code to tokio

>>105806228 (OP)
>USAID off
>got ICEd
>dead from acute gender dysphoria

>>105808653
io-uring is a meme, nobody is switching to it in any event loop implementation for any language, epoll is good enough for everyone

>>105808786
>composing tasks actually works
Kinda works.
Not really when doing library code - you're stuck manually writing state machines if you want your API to be nice to use.

Async has really poor orthogonality with the rest of the language in Rust.

>>105806228 (OP)
Turned out to be not so memory safe

>>105808971
kino

>>105808772
Except it isn't shit, but it all sticks, like a sticky grenade.

>>105806228 (OP)
Apple could've stopped Rust by making Swift firstclass on every commonly used platform but they didn't

>>105809113
Swift has issues, like its type checking being fucked.

let a: Double = -(1 + 2) + -(3 + 4) + -(5)


Try an online Swift compiler and confirm that the Swift compiler complains about the expression taking too long to type-check.

https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html

>>105807412
Why in the world would you have async in any low(ish) level language?
If you want an event loop, make your own.

>>105809386
main.swift:5:17: error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
let a: Double = -(1 + 2) + -(3 + 4) + -(5)
^~~~~~~~~~~~~~~~~~~~~~~~~~

=== Code Exited With Errors ===

>>105808966
>Not really when doing library code - you're stuck manually writing state machines if you want your API to be nice to use.
What do you mean? The state machines are generated automatically from async functions.

>>105809393
>Why in the world would you have async in any low(ish) level language?
Because it saves you from including entire fucking RTOS? Embassy has been a blessing to embedded development.

>>105810075
he might mean something like this: https://www.firezone.dev/blog/sans-io
it's a big thing for new rust async libs nowadays

>>105806228 (OP)
Lowkey ugly syntax

>>105810432
I'm not reading whole random article but what they are doing doesn't seem by any means required. If you want a state machine you can just use async function.

>Ctrl+F
>israel
>0 results
no really, what happened to this place?

>>105810946
>>>/pol/

>>105810089
In for instance this example, how much overhead does its approach incur relative to some other approaches? None? Some?
https://github.com/embassy-rs/embassy/blob/main/examples/nrf52840/src/bin/multiprio.rs

>>105810089
Is the user or Embassy at fault here?
https://github.com/embassy-rs/embassy/issues/4367
Stack overflows, UB, it seems.
He said he didn't have the problems when using RTOS.
>I've worked with ESP32 boards in the past running Rust code using ESP-IDF (i.e. bindings to FreeRTOS, which should be a much more RAM-hungry approach) instead of Embassy, and I've never really experienced stack overflows even while doing pretty complicated things using tasks with as little as 10-12KiB of stack, whereas now I'm running into issues while using no RTOS and having ~256KiB of RAM available, so I really can't figure out what's going on.
Could just be a bug on his end.

>>105810089
Is "unsafe" just a fake, ceremonial keyword when doing embedded Rust?
https://github.com/embassy-rs/embassy/issues/4226

>>105810089
I don't know if I like that approx. 1/3 of all issues are open, and that possible crashing bugs are not at least labelled. But, it might be a volunteer project that is free to use, so maybe one is getting what one paid for.

>>105811306
>possibly

>>105811178
Benchmark it

>>105811211
How should I know?

>>105811276
No, RTFM

>>105811306
It's a young but popular FOSS project. That's expected.

Why did you split your response into 4 separate posts?

>>105810089
>Embassy has been a blessing to embedded development.

>>105811667
Evangelizing Embassy without really being able or willing to actually answer questions about it or topics related to it.

I guess this is the "push" strategy employed by Rust evangelists, not the "pull" strategy, similar to how drug dealers aggressively push drugs onto youngsters and trap them in addiction, instead of letting the drugs be seen as attractive by themselves.
Just sucks that dishonesty is anathema to technology and science.

>and honestly it seems unlikely given the marketing around Rust that such a core term as "unsafe code" would get used generically/casually when talking about low-level API options here

Marketing and unsafe.

Rust is Death Grips of programming languages. No, I will not elaborate.

>>105811856
>Evangelizing Embassy without really being able or willing to actually answer questions about it or topics related to it.
Just because I've used embassy doesn't mean I can tell you details about overheads or why some random guy got a stack overflow lmao. The meaning of unsafe you can read in the book and rustonomicon.

RUSTED

>>105806605
kekd

>>105808979
disgusting jeetoid reaction gif totally nullifies whatever based opinions your brown ass might have

>>105809946
Jeet tier language kek

So how long until the async issue is solved?

>>105814758
I find that designation weird. The only connection I can see is between Lattner and Vikram Adve.
Besides, the main original author of Swift has a PhD, and is well-renowned from his work with LLVM
https://en.wikipedia.org/wiki/Chris_Lattner
But that kind of blunder regarding the type system still puzzles me. Yes, programming language design can be extraordinarily difficult, and there are a huge number of things that can go wrong. And several aspects of Swift seem nice. But type checking very basic, non-esoteric code, really should not result in compiler performance that is that degraded.
Both C++ and Rust has issues with their type systems. Rust has a more complex type system than C++, and in some ways worse issues than C++.
Swift has other issues than its type system, though some of those I would chalk up to how Swift is financed, developed and used.

>>105814758
>>105814994
An example of Rust having exponentially long compile times, or just crashing, is:

fn main() {
let a = (
1, 1, 1, 1, 1,
1, 1, 1, 1, 1,
1, 1, 1, 1, 1);

let mut b = 0;

match a {
(
_ | _ , _ | _ , _ | _ , _ | _ , _ | _ ,
_ | _ , _ | _ , _ | _ , _ | _ , _ | _ ,
_ | _ , _ | _ , _ | _ , _ | _ , _ | _
) if {b += 1; false} => {
println!("match {}", b);
},
_ => {}
};
}


But this code is also esoteric. The Swift examples are not, and the issues also crop up in practical Swift code.

Rust does have fundamental soundness issues in its type system, and those issues appear to be very difficult to fix. The type system issues of Rust is also one cause of the long compilation time issues of some Rust projects. Though different Rust projects have different causes of long compilation time issues.

>>105815138
Sometimes rust mode in emacs crashes out elisp or renders certain lines uneditable.
Haven’t seen that since Perl4.

>>105814994
>and in some ways worse issues than C++.
What type system related issues Rust has over C++?
From my experience it seems that Rust has better type system altogether. Especially because of proper ZST, function types, bottom type and singleton.

>>105815138
>Rust does have fundamental soundness issues in its type system, and those issues appear to be very difficult to fix.
What are they exactly? If they are fundamental then you can't fix them.

>The type system issues of Rust is also one cause of the long compilation time issues of some Rust projects
Isn't that because of huge amount of IR emitted, and not type system. What exactly does take that much time to type check in Rust? It doesn't have back and forth algorithms like Swift IIRC

>>105806228 (OP)
Rust devs Alt-F4 themselves

>>105816520
The type system of Rust is more complex than that of C++, and while it is expressive, complexity can have costs. And some mistakes were made.

https://github.com/Speykious/cve-rs

is a classic.

If you go to the Rust language repository on Github, and select the unsound label, a bunch of issues show up. You can also select the compiletime label, some of the issues there take exponential time to compile in the length of the source code, and involves changing the type system.

Someone mentioned this special repository

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

It has intruging issues, you can read through them.

Should I dig for specific issues?

>>105816556
>What are they exactly? If they are fundamental then you can't fix them.
Well lcnr tries, and it isn't easy. They have a solver named Polonius, maybe that will fix some woes they have.
If you change the type system, but kind of make the new type system backwards compatible, the type system issues might have been fundamental and unfixable, but you replaced that type system. The trick is then the backwards compatibility, might be possible to get very hairy.

>Isn't that because of huge amount of IR emitted, and not type system. What exactly does take that much time to type check in Rust? It doesn't have back and forth algorithms like Swift IIRC
Rust does have at least one solver. But whether a Rust project has poor compile times for one reason or another, depends also on what features of the language it uses and how it uses them. For some Rust projects, IR generation as you say will dominate.

Rust is built by troons for troons. Not my cuppa tea.

>>105816767
No, they definitely have some talent on board. Whether they tricked that talent and lured them in with some genuinely different and interesting subjects or not, is a different question.

>>105816780
t. Rusttroon

>>105816787
No, Ralf Jung for instance has a PhD, and he and his colleagues have been busy fixing and cleaning up a lot of messes in Rust, both in terms of theory and practice. They work within the constraints of backwards compatibility, despite what editions might help or hinder in this regard.

>>105816763
>The type system of Rust is more complex than that of C++, and while it is expressive, complexity can have costs. And some mistakes were made.
>https://github.com/Speykious/cve-rs
That requires quite an esoteric set up and basically boils down to a dangling reference bug. Something that is trivial to do in C++. How is this a worse issue than what you get in C++? C++ type system(and even parsing grammar!) is undecidable.

>If you go to the Rust language repository on Github, and select the unsound label, a bunch of issues show up.
What makes them way worse than what you see in C++?

>Should I dig for specific issues?
If that answers the question.

>Well lcnr tries, and it isn't easy. They have a solver named Polonius, maybe that will fix some woes they have.
But what exactly are these fundamental issues you are talking about?

>>105807812
>jeets talking to bots.
assuming "bots" include LLM posts, this is accurate.
just look ^^ lol

>>105811856
>I guess this is the "push" strategy employed by Rust evangelists, not the "pull" strategy, similar to how drug dealers aggressively push drugs onto youngsters and trap them in addiction, instead of letting the drugs be seen as attractive by themselves.
The Rust strategy is
>do nothing
>win
The only "evangelism" is because C/C++ programmers are lying about Rust, so people who used Rust correct them because lies are bad and they don't want Rust to fail because people lied about it. Ironically, this actually makes Rust look better and is responsible for Rust's increasing popularity.

>Just sucks that dishonesty is anathema to technology and science.
That's why people hate C/C++ shills.

[1/?]

>>105817962
>What makes them way worse than what you see in C++?
This was my original claim:
>Rust has a more complex type system than C++, and in some ways worse issues than C++.
Please do not misrepresent what I claimed.

>C++ type system(and even parsing grammar!) is undecidable.
Rust's type system is Turing-complete, though not what I'm focusing on.

[2/?]

>>105817962

>That requires quite an esoteric set up and basically boils down to a dangling reference bug. Something that is trivial to do in C++. How is this a worse issue than what you get in C++?
In C++, the language makes the programmer responsible for avoiding certain issues, while the type system catches other issues. In Rust, more issues are caught by the type system and borrow checker, in return for having to deal with the constraints of the borrow checker. A language that had both the guarantees of Rust, and the relative freedom and ergonomics of C++, would be better than both C++ and Rust in these regards. However, when Rust does not provide the guarantees that it promises, depending on the specifics, it could result in for instance UB. Basically the worst of both worlds. The lower complexity of C++'s type system also makes it more feasible for C++ programmers to reason about types than for Rust programmers (even though C++ is not that simple in its type system). Rust takes care of a lot of stuff, with NLL, advanced type inference, etc., which mitigates the complexity and cumbersomeness of Rust's type system, but this also makes Rust programmers in practice more reliant on the compiler being correct, since figuring out themselves whether a given piece of Rust code should type check, may frequently be very difficult for many or most Rust programmers. And if the type system itself is broken, it might be the case that the compiler is not ever able to be correct.
There are also the cases for Rust that old code that compiled with compiler version A, may not compile with compiler version A+1, and the Rust language designers may not always be able to fix it or figure out why, due to the complexity of the solver.

[3/3]

>>105817962
>>105818929
>>105818945

In C++, there is a principle to not include or require any complex solvers for its type system, even though such a solver might enable a lot of stuff in C++.

There is Rust nonsense like this

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

>Even worse, there may be changes to asymptotic complexity of some part of the trait system. This can cause crates which start to compile fine due to the stabilization of the new solver to hang after regressing the complexity again. This is already an issue of the current type system. For example rust-lang/rust#75443 caused hangs (rust-lang/rust#75992), was reverted in rust-lang/rust#78410, then landed again after fixing these regressions in rust-lang/rust#100980 which caused yet another hang (rust-lang/rust#103423), causing it to be reverted yet again in rust-lang/rust#103509.

Is there anything even remotely similar in C++? Since C++'s type system is simpler and more limited, and less ambitious, than that of Rust, it also ought to be easier to avoid having existing code no longer compile with a new version of the compiler and language due to changes in the solver, like is seen for Rust.

Are there any similar type system issues in C++ as here in Rust?

Does C++ have any problems even remotely similar to the problem of https://github.com/lcnr/solver-woes/issues/6 ?

>But what exactly are these fundamental issues you are talking about?
There appear to be a wealth of them, like I linked, and some of them might be too complex for Rust language designers to figure out. And they might be hoping that Polonius happens to fix things.
https://github.com/rust-lang/rust/issues/75992

>>105817962
Imagine having a 100K LOC Rust project, updating the compiler, and suddenly your project no longer compiles, and the Rust language designers aren't able to figure out how to fix the compiler, leaving you stuck on the old compiler version or trying out whatever to hope your project begins compiling again.
https://github.com/rust-lang/rust/issues/75992

I'm not OP but why are people turning on Rust now? I did some research on some projects i want to do and found that Rust would be the best language to do it, so i was about to learn it.. my project(s) prioritize security..

>>105818142
Are you demented? Rust evangelists not pushing anything?

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

>Technical patches and discussions matter. Social media brigading - no
than\k you.
>Linus

>>105819013
The less unsafe your Rust project and transitive dependencies use, the better.
Also read
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>105819033
I'm sorry anon, but i only understood that reliance on faulty dependencies basically removes the niche advantage of Rust-- aka memory and security. Am i missing anything? [spoiler]I never coded a single line in my life[/spoiler]

>>105819183
>reliance on faulty dependencies
But that in the above case included the Rust standard library.
How to guard against that?
Miri, Valgrind and gdb can mitigate it, or at least help debugging.

At least Rust has pattern matching.

>>105818929
>>What makes them way worse than what you see in C++?
>This was my original claim:
>>Rust has a more complex type system than C++, and in some ways worse issues than C++.
>Please do not misrepresent what I claimed.
Yeah, that's why I'm asking how are these issues worse than C++.

>>105818945
>However, when Rust does not provide the guarantees that it promises, depending on the specifics, it could result in for instance UB.
Yeah, but his bug requires esoteric set up that you don't find in regular code. Ada has worse soundness problems and yet people keep bringing it up as an example of safe language.

>The lower complexity of C++'s type system also makes it more feasible for C++ programmers to reason about types than for Rust programmers
Based on what? Rust has more complex type system in a way that lets you express more abstract things in it. But C++ has way more stuff and weird stuff in it that makes it harder to reason about types in my opinion. All this void being incomplete type, SFINAE, value categories, two kinds of references, non-lambda functions having the type of their pointers, constructors, multiple inheritance etc makes it harder to reason about types. Rust type system seems way more elegant and minimal, more akin to functional languages.

>Rust programmers in practice more reliant on the compiler being correct
That's true for any kind of static analysis.

>since figuring out themselves whether a given piece of Rust code should type check,
Same for complex templates. We come up with RAII, types, static analyzers, linters, calling conventions, etc to offload that cognitive overhead to the compiler. We all rely that they work properly so we can think within more high level abstractions.

>And if the type system itself is broken, it might be the case that the compiler is not ever able to be correct.
But that requires kind of code that you don't write in practice. And it's just a bug, it will be fixed eventually.

>>105818945

>There are also the cases for Rust that old code that compiled with compiler version A, may not compile with compiler version A+1, and the Rust
language designers may not always be able to fix it or figure out why, due to the complexity of the solver.
That's what editions are for.
Keep in mind that C++ also straight up removes stuff every version and your code will also not work with newest C++.

So, where are the fundamental issues you were talking about and issues that were worse than C++?

>>105818956
>There is Rust nonsense like this
>https://github.com/lcnr/solver-woes/issues/1
>Is there anything even remotely similar in C++?
C++ also can blow up compilation time. Check out "there is no zero cost abstractions" from Google.

>it also ought to be easier to avoid having existing code no longer compile with a new version of the compiler
Then why do they remove stuff from it in new versions? It's literally breaking change

>Are there any similar type system issues in C++ as here in Rust
What is the actual problem here though? That guy is making a hypothetical on some potential problems of some new solver that isn't stabilized yet. Was this actually stabilized? If so, why is this issue on some random noname repo instead of the official one?

>Does C++ have any problems even remotely similar to the problem of https://github.com/lcnr/solver-woes/issues/6 ?
I don't see what is the problem here. Was there any actual regression or breaking change or what is this even about.

>There appear to be a wealth of them
Such as?

>https://github.com/rust-lang/rust/issues/75992
What makes this issue fundamental?

>>105818987
>Imagine having a 100K LOC Rust project
What project are you talking about?

>language designers aren't able to figure out how to fix the compiler,
Are they? It seems they are working in it. This issue has tons of discussion.

Why are you splitting your responses into multiple posts like this?

>>105819245
>How to guard against that?
In the very same way you guard against bugs in stdlib in any other language.

>>105806228 (OP)
>What happened?
41%

>>105807412
>It's not bad because a 60 year old language is worse.
Is that really the bar? lmfao, Rustoids are cooked.

>>105806260
Based. OS primitives should have been wrapped in library-agnostic futures.

>>105809946
> the compiler is unable to type-check this expression in reasonable time
That's what you get for using 2 way HM. kwab the language. Wasn't it started by the LLVM guy when he got acquihired by Apple?

>>105819033
>Rust channels
>Actually it's crossbeam-rs
...

>>105820825
I don't see you coming up with anything better retard. Reminder, anything you propose has to work in a multitude of environments as well. C++ took the easy way out and as a result you can't even guarantee no heap allocations. Rust doesn't have that problem btw.

>>105806228 (OP)
>>Rust
>>0 results
No one uses Rust any more. That sure was a quick love affair. :p

Now that Rust is dead and gone, and there's no debate required because the science is settled, what killed Rust? Where are the Rustroons going as they leave the sinking ship? What lessons did we learn from the failures of Rust?

>>105809386
I tried this out just now. Absolutely incredible that issues reported 10 years ago with perfectly reasonable and simple constructs haven't been improved on.

>>105821400
>I don't see you
That's because this is an anonymous basket weaving forum. Touch grass and learn2code.

>>105821400
>C++
Don't care. Zig is better than both.

>Rust
>4MB hello world
Yeah, I'll just stick to serious languages I think.

>>105807823
>Some people like
Tell me you only do tinkertranny projects without telling me. Good engineering isn't about what you "like".

What does Rust actually provide to users of software? Mostly just a barrage of buzzwords and having to deal with mentally unstable maintainers.

>>105821886
It doesn't even support RAII

>>105822008
What does any language provide to the users of software?

>>105822030
What problem does RAII solve? Helping to break up programs into 10 million tiny allocations? Just use linear allocation and coarser lifetimes. Simple as. Rustoids inherited all the worst C++ brain damages (including calling their dynamic array a "vector", lmao).

>>105822008
Nothing, but that doesn't stop the troons from advertising it as a feature. MADE WITH BLAZINGLY FAST MEMORY SAFE RUUUUUUST!

>>105821896
Hello world is not a serious software.

>>105822192
Serious software is 100M in Rust, when the sane version is 640K.

>>105822213
>he forgot to compile in --release
>he forgot to strip

>>105822262
>DUDE JUST COMPILE IT WITH 14 DIFFERENT FLAGS
> JUST USE A SHELL SCRIPT DUDE
> TOTALLY BETTER THAN C++

>>105822213
Third world problem. 100M is a fraction of modern storage. My phone has 1TB storage capacity.

>>105822115
>What problem does RAII solve?
Allows you to tie resource lifetime to object lifetime. It's a kind of type invariant.

>>105822278
Strip isn't a shell script retard.

>>105822343
Ai post

>>105822278
you'd have to do these same steps with C/C++

>>105806228 (OP)
I'm on vacation.

>>105819013
shillfarm bucks dried out
and modern c++ is safe enough

>>105806228 (OP)
All the funding that was used for propaganda went back to israel

>>105806312
Fucking this. People realized the whole safety thing was a sham too and went back to c/c++.

>>105822278
>meanwhile in cnileland
>gcc -O3 -march=native -Wall -Wextra -Wpedantic -Wvla -Wshadow -Wundef -Wstrict-prototype -Wmissing-declarations -Wmissing-prototypes -Wdouble-promotion -fsanitize=address -o faget faget.c
So shrimple.

>>105820718
>>105820796
Your replies are of so low quality, that it's clear that you're not being forthright.
DOS by spewing nonsense.

Tragic state of affairs for Rust evangelists.

>>105820805
Except the Rust standard library is full of unsafe. That does not hold for all standard libraries.

>>105821328
Yes, Chris Lattner.

>>105821595
Rust does have some good aspects to it. Rust (language and ecosystem) would have been way better, if it had:
>more honesty
>less belligerent and malicious evangelism
>better and less faulty type system foundation
>better unsafe
I don't think everyone should abandon Rust. But a more benevolent approach, for both Rust, its users, and for programming languages generally, would be great. Personally, I would hope for a successor language to C++ and Rust, but that would at least require a lot of research and experimentation without guaranteed results apart from furthering knowledge.

How many research languages are there with Rust-inspired borrow checking?

>>105821598
I think it's because it's a fundamental issue in Swift that is difficult or impossible to fix without breaking backwards compatibility to a significant degree.
I wonder if Swift could try to pull a breaking version change. But even in the best of cases, that is an enormous amount of work. And the track record isn't great for that kind of stuff:
>Perl 5 to Perl 6: Killed Perl.
>Python 2 to Python 3: Decade worth of pain and misery, but Python survived and is thriving.
>Scala 2 to Scala 3: Community still split.

Both C++ and Rust are significantly better on this point with exponential compile times than Swift. Swift does have some other good things going for it, but also more issues.

>>105822008
Pattern matching is nice.
The borrow checker is neat, but is also really, really ambitious, and I think Rust did not do quite as well on that subject as the marketing of Rust pretends. Hopefully research languages can explore that topic more, and successor languages have better luck with it (this would be helped a lot by research, knowledge material, etc. of borrow checking generally, to avoid pitfalls and get the best out of it).

>>105806228 (OP)
You weren't awake yet to make (yet) another Rust(tm, dilator not included) thread, anon.

>>105825338
Just because Rust has unsafe and safe distinction doesn't mean it's standard library is doing anything extraordinary. It's the same kind of code and you guard against it's bugs in the very same way as in any other language.

>>105825324
Not an argument

>>105825496
What would you change in borrow checker to improve it without losing any of it's guarantees?
I don't think it's ambitious. BC itself is pretty simple conceptually. The only thing somewhat tricky might be NLL but that's still not really anything complex.

>>105825611
>Not an argument
You break the basic rules of conversation, it's completely fair for me to call you out, dishonest evangelist.
The fault lies 100% with you, and 0% with me. And you knew that while you typed those replies.
Who knows if you used AI to help your spam.

>What would you change in borrow checker to improve it without losing any of it's guarantees?
>I don't think it's ambitious. BC itself is pretty simple conceptually. The only thing somewhat tricky might be NLL but that's still not really anything complex.
If one ignores what is actually possible and realistic (since it's not necessarily clear what is actually possible in practice, and AFAIK there has been very little research on the topic), and we take the borrow checker, unsafe, etc. as a whole:
>easy to reason about, also when using unsafe
>fully specified
>way better ergonomics
>ease of implementing compilers independently
>fully flexible and zero-cost design and architecture options without needing unsafe; or, alternatively lessening the requirement, by needing unsafe or easy-unsafe, where unsafe/easy-unsafe is easy to reason about, such that Rust would have been a good option in for instance https://github.com/microsoft/typescript-go/discussions/411
>avoid the type system issues of Rust, and have a type system without fundamental issues and bugs and where non-esoteric code never yields exponential compile times
>a project written in one version of the language that compiles in reasonable time, shouldn't ever compile in exponential time when upgrading language or compiler version. This doesn't hold for Rust currently https://github.com/rust-lang/rust/issues/75992 https://github.com/lcnr/solver-woes/issues
>ensure that the borrow checkee, unsafe, etc. is a good alternative to arena allocations, such that there is rarely ever any reason to use arena allocation, like some Rust developers do (arena avoids borrow checker)
>etc.

>>105825611
>>105825734
I don't believe that Rust's borrow checker, unsafe split, etc., is the best possible that one can get. But if that is the case, that it really is the best possible, then I think it counts against that approach as a whole, given the drawbacks. Could still be worth it for some types of applications and domains.

>>105825734
>such that there is rarely ever any reason to use arena allocation, like some Rust developers do (arena avoids borrow checker)
fukken lamao
this cant be fucking serious, post sauce anon

>>105825611
>it's guarantees
Grammar mistake.

>>105825758
https://donsz.nl/blog/arenas/
>other times for lifetime-related reasons.
https://reddit.com/r/rust/comments/1etbfym/a_comparison_of_every_arena_in_rust/
>If you're interested in why the arena/slotmap concept is especially important in Rust (a generic way to satisfy the borrow checker), I have a post on this: https://jacko.io/object_soup.html
https://reddit.com/r/rust/comments/1jlopns/turns_out_using_custom_allocators_makes_using/
>A couple of weeks ago at work I introduced the `bumpalo` crate (a crate that implements a simple bump/arena allocator) to simplify our memory management.

>>105825822
no way lamao
and i bet they defend the lang as it is

>>105825822
>https://reddit.com/r/rust/comments/1etbfym/a_comparison_of_every_arena_in_rust/
>wants into rust
>cant even comprehend the concept of arenas
in truth i bet hes reading a bad source
although there seems to be legit fukken talks about em
how?? arenas are dead simple as a concept

>>105826010
arenafags are terrible at explaining what an arena is.
it is actually very simple: an arena is like a burrito.

>>105825822
not gonna lie, reddit can be interesting at times if you just want to poke fun at the normies

>>105826045
>like a burrito
thats novel
otherwise one could just say that an arena is a memory space you allocate beforehand, and then distribute said memory depending on your programs needs
it naturally maps to your function scopes, making memory management- trivial

im legit in awe that arenas are such a fucking problem for the wider industry
heres one of the reddit-recommended talks:
it takes the guy 30 minutes of intro before he starts describing what an arena is
wtf, is it something novel, rediscovered for the wider industry?

also im curious of the synchronicity bw our arena-talks on /g/ and the appearance of arena-evangelists (for lack of a better word)

(forgot sös)
https://www.youtube.com/watch?v=TZ5a3gCCZYo

>>105825749
>I think it counts against that approach as a whole, given the drawbacks
How so? So far it seems that many people enjoy working with borrow checker. It makes it so much easier to design safe, zero cost abstractions. For example in C++, people often do not feel confident using string_views that often and rather copy strings everywhere to avoid potential UBs, while in Rust people pass references around without hesitation. Borrow checker motivated Ada developers to add kind of lifetime tracking to the language and it also spawned some proposals to C++.

>>105825760
Not an argument

>>105825734
>You break the basic rules of conversation
I am merely asking you for details and examples of your claims.

>dishonest evangelist
I could call you a dishonest hater.

>The fault lies 100% with you, and 0% with me. And you knew that while you typed those replies.
>Who knows if you used AI to help your spam.
Not an argument.

>>easy to reason about, also when using unsafe
>>fully specified
>>way better ergonomics
>>ease of implementing compilers independently
>>fully flexible and zero-cost design and architecture options without needing unsafe; or, alternatively lessening the requirement, by needing unsafe or easy-unsafe, where unsafe/easy-unsafe is easy to reason about, such that Rust would have been a good option in for instance https://github.com/microsoft/typescript-go/discussions/411
>>avoid the type system issues of Rust, and have a type system without fundamental issues and bugs and where non-esoteric code never yields exponential compile times
>>a project written in one version of the language that compiles in reasonable time, shouldn't ever compile in exponential time when upgrading language or compiler version. This doesn't hold for Rust currently https://github.com/rust-lang/rust/issues/75992 https://github.com/lcnr/solver-woes/issues
>>ensure that the borrow checkee, unsafe, etc. is a good alternative to arena allocations, such that there is rarely ever any reason to use arena allocation, like some Rust developers do (arena avoids borrow checker)
>>etc.
So, what would you change in borrow checker exactly?

>>105825734
>>fully flexible and zero-cost design and architecture options without needing unsafe; or, alternatively lessening the requirement, by needing unsafe or easy-unsafe, where unsafe/easy-unsafe is easy to reason about, such that Rust would have been a good option in for instance https://github.com/microsoft/typescript-go/discussions/411
So, you would want to make Rust into managed language, wtf?
Do you even understand why did they choose Go in the first place?

>>avoid the type system issues of Rust, and have a type system without fundamental issues and bugs and where non-esoteric code never yields exponential compile times
What are the fundamental bugs? You still failed to state them.

>>ensure that the borrow checkee, unsafe, etc. is a good alternative to arena allocations, such that there is rarely ever any reason to use arena allocation, like some Rust developers do (arena avoids borrow checker)
There is plenty of area allocators for Rust.

>>105825758
Arena allocators do not avoid borrow checker. It doesn't actually matter what allocator you use, all the borrow checker rules are still applied.

>>105826097
Area allocators are old concept. There is nothing unusual about them. Like any other kind of allocators, they have their strengths and weaknesses, and they are far from being universal.

>be cnil
>get owned over and over and over again by malloc and free
>cry silentyl in a dark room
>suddenly an idea impacts the cnile's brain
>what if... instead of using a global allocator for eveything I use a local allocator?
>cnile stops crying and immediately spams her revolutionary idea in every online forum he knows

>>105826226
>Area allocators are old concept. There is nothing unusual about them.
yeah
thats why i was surprized
>and they are far from being universal.
>far
for all intents and purposes you can use them everywhere
>but threading
one arena per thread- problem solved
overengineering is worse than communism in its cost in human lives

>>105826271
>no you
that means you care
which in turn means youre developmentally retarded <3

>>105826152
But I already discussed why. You are still lying.

>>105826186
The only liar here is you, dishonest Rust evangelist. And you are perfectly aware of it.
Are you doing sandbagging tactics against me?

>>105826200
More lies and nonsense.

The only part where you could have an actual argument is GC, and even then, GC does not cover all of it. I should have written
>better of an option
instead of
>good option
If you look at https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12470176 , the listed items for Rust are:
>No garbage collection, and rewriting the compiler in a way that does not depend on garbage collection is not feasible
>Rust does have memory management, but it is not as automatic as having a built-in GC
>Having to deal with reference counting and borrow checker makes straightforward port impossible
>Cyclic data structure is outlawed
Cyclic data structures tend to require unsafe in Rust, unless for instance they fit into some cyclic generic data structures, or something like indices are used. This is not the case for languages like C++ or Zig, neither of which uses GC. Furthermore, the borrow checker is directly mentioned, which most languages (GC or no GC) do not have.

>>105806260
>>105806228 (OP)
rust these days is just losers porting C/C++ software like tmux as tmux-rs to feel relevancy
they just hijack other prods and then say they saved everyone whilst nobody had issues with tmux """memory safety""" to begin with
there is a reason genital lice were called as a case of "having the crabs"
once they are there, you can't get rid of them
best code in zoomer zig, that usually pisses them off

>>105821886
>>105826662
Zig will kill Rust just for being simpler and more lean with the same promise.

>>105826684
maybe in 10 years
https://github.com/ziglang/zig/pull/24329
>Deprecates all existing std.io readers and writers in favor of the newly provided std.io.Reader and std.io.Writer
>I have a lot more changes to upstream but it was taking too long to finish them so I decided to do it more piecemeal.
>These changes are extremely breaking.

>>105826285
>for all intents and purposes you can use them everywhere
You can't use them in long running programs where lifetime of your allocations is non deterministic. They are frankly quite limiting for most applications. They only really make sense in short lived programs where you don't need to deallocate or in programs where you have hard boundaries at which you can free all the data all at once, like raytracers.

>>105826309
Not really.

>You are still lying
Point out my lies.

>>105826329
>The only liar here is you
Point out my lies.

>dishones
I could say the same about you.

>Are you doing sandbagging tactics against me?
No

>>105826506
>More lies
Point out my lies.

>The only part where you could have an actual argument is GC, and even then, GC does not cover all of it. I should have written
>>better of an option
>instead of
>>good option
>If you look at https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12470176 , the listed items for Rust are:
>>No garbage collection, and rewriting the compiler in a way that does not depend on garbage collection is not feasible
>>Rust does have memory management, but it is not as automatic as having a built-in GC
>>Having to deal with reference counting and borrow checker makes straightforward port impossible
>>Cyclic data structure is outlawed
>Cyclic data structures tend to require unsafe in Rust, unless for instance they fit into some cyclic generic data structures, or something like indices are used. This is not the case for languages like C++ or Zig, neither of which uses GC. Furthermore, the borrow checker is directly mentioned, which most languages (GC or no GC) do not have.
The reason they have chosen Go is because Go is a webdev friendly, managed language that is more similar to JS than Rust is. No idea what point you are trying to make here. That Rust should be a manager, GC language? It's a systems programming language, it doesn't need any sort of stuff.

>Cyclic data structures tend to require unsafe in Rust,
False. Just count your references

>This is not the case for languages like C++ or Zig, neither of which uses GC.
You can write cyclic data structures in Rust in the same way you would write them in C++. Both are systems programming languages.

>>105826706
>You can't use them in long running programs where lifetime of your allocations is non deterministic
why?
i wont address the rest yet because its based on a completely wrong assumption

>>105826684
2 more weeks

>>105826756
until the next rust fork of a C project to feign relevancy

>>105826754
>why?
Because area allocators typically can only free all the allocations at once. If the lifetime of your allocations is not deterministic, you don't know when will they all be released for freeing and your memory usage is going to keep increasing until you run out of memory.

>i wont address the rest
Of course you won't. I don't think you have addressed any of my posts so far, outside if as hominem and moving the goalpost.

>>105826804
>Because area allocators typically can only free all the allocations at once.
you dont need to shove everything into one arena
and your arenas dont need to follow your function scopes

you just tie your arena to the lifetime of your objects

>sad homonem
you can shove it into your axewound trany
its the first time i address you
you should have deduced it from the difference in tone and capitalization

>>105826836
>have the same opinions as all other cniles
>get upset when she gets treated like other cniles

>>105826932
>rent free
>constant state of hate
>knows fuck all about tech

>>105826941
keep seething

>>105826953
>n-no u
u lost

>>105826959
dumb retard
its the first time i address you
you should have deduced it from the difference in tone and capitalization

>>105826970
lmao u maaaaaaaad
soooooo mad

and still fail

>>105826986
lmao u maaaaaaaad
soooooo mad

and still fail

>>105827000
complete ego breakdown lamao
youre truly developmentally retarded

>>105827021
https://desuarchive.org/g/search/text/lamao/
oof, yikes bro

>>105827028
>it's the "rust on resume = do not hire" retard

>>105827028
what about it?

>>105826836
>you dont need to shove everything into one arena
>and your arenas dont need to follow your function scopes
You don't, but if your allocations do not have deterministic lifetime you are back at the same problem.

>you just tie your arena to the lifetime of your objects
If you create areas for each object then that's just RAII and you will need some other allocator to dynamically manage these areas.

>you can shove it into your axewound trany
Not an argument

>>105827052
>crabs confused by an arena
and how was i wrong in saying that?

>>105827064
>If you create areas for each object then that's just RAII and you will need some other allocator to dynamically manage these areas.
this was the last bridge
it can be done. its not optimal, but it can
but you could also do some more fancy stuff like having an index where you have a address of the pointer-associated arena block. block which contains your non-deterministic-lifetime object alone
or have second order arenas to avoid allocating/deallocating your stuff and use heuristics when allocating blocks your first order arenas

theres so much you can do with arenas, there isnt a one-size-fits-all solution, and some of them are somewhat expanding what an arena is even called
but at its origin, its still an arena

>>105827089
i dont post very often but i appreciate it that you all think about me everyday since i made THAT thread

Over the last month, I read the Rust Programming Language and completed my first rust project, a webapp chatroom that communicates keystrokes in real time using websockets. Writing the backend in axum was a walk in the park, and writing the frontend in 100% Rust using web_sys and wasm-bindgen was shockingly manageable compared to other languages I've tried that compile to wasm.
Rust is great. High level features like iterators, direct memory access, simple ownership rules that prevent footjob code. Also, switching back to other languages, `rustfmt` is so convenient, marking up this HTML I'm working on now makes me want to kms.
The function coloring problem is real, as in other languages, yet Rust does not hide this from you. That generally sums up how I feel about it. Debugging my first Rust app was 20x better experience than shitty interpreted languages. The problems are directly in front of you and it forces you to learn about them and confront them.
The memory safety features of Rust are massively overblown. It's nice to have the compiler tell you you're a fucktard if you messed up ownership, but in C/C++, you can literally enforce the same ownership rules upon yourself and use valgrind to make sure you didn't fuck your shit up. Memory safety is basically a non-issue. I think the other features of the language, such as the lack of a labyrinthine template engine for autist bitch library programmers to ruin your life, the lack of nulltype, and Rust's enums are a much bigger selling point.
Thankfully, I'm a chemist by profession, so I don't have to cope for trannyscript, jannyscript, pyreddithon, or java like all of the soulless kike-led 'engineer' drones getting replaced by indians and Actually Indians. In my work, I choose the system I want. For now, I choose the language with the kick-ass package manager, fearless concurrency, and baller cross-platform support. Low IQ coding troglodytes need not apply.
Go ferris!

>>105827139
ah
so usaid money DIDNT dry out after all

>>105827147
tfw i did everything described, learning and dev, on the clock at a government agency. i went through the eye of the needle to dodge the day of the rope for feds, thrice over.
are you a rust lover?

>>105827179
>quacks like an ad...
its fairly clear that you copy pasted that from reddit

>>105827193
And yet it doesn't appear anywhere, because I wrote it. Your writing abilities are so poor that you project my comment was not original?
I mean, if you're interested, I could show you my app. It's live. And what C projects have you written in the last year?

>>105827250
>And yet it doesn't appear anywhere, because I wrote it. Your writing abilities are so poor that you project my comment was not original?
no its bc i was trained in marketing and i could recognize a pr blurb with my eyes closed
>I mean, if you're interested, I could show you my app
please prosneed
>And what C projects have you written in the last year?
its hard to tell bc im working on a multi year project
but in the past 365 days i done fuck all bc im still living form money i earned before
>writing skills
you call your pr blurb "writing skills"?

>>105827297
cavalier.samfield.net
no, its shitposting to troll language squabblers. and here you are. the only reason i came on /g/ today was to ask about thinkpad price crashes with the win10 shutdown. and speaking of, are you thinking about any old computers after the win10 shutdown?

>>105826684
Zig doesn't promise memory safety at all, what do you mean?

>>105806228 (OP)
What we really need is a high-level garbage collected programming language with non-blocking I/O by default, just like Go, but without Go's retarded decisions and with a C-like syntax. It will literally win the whole next-generation programming language competition. Everyone wants simple memory safety (which means we need GC), non-blocking I/O (need green threads or async/await) but out of the mainstream newlangs only Go fits this criteria, which is a retarded language that most people don't like.

>>105827456
Java/C#

>>105827378
>and here you are.
i started slow and polite
but as customary with crabs, they just had to engage
i wanted to discuss arenas but if someone is disagreeable i make sure they stop
which they did. as expected. crabs are fucking retarded its not like theyre a real contest

>cavalier.samfield.net
dont you have anything more serious?
this is cs-project tier.

>are you thinking about any old computers after the win10 shutdown?
not really. i use loonix. i will be able to use most computers for a good while yet

>>105827461
People want newlang features that aren't present in these two languages too, like not having to write everything in a class, tagged unions, maybe even not having inheritance

>>105827456
Oh and I forgot to mention: people really like AOT compilation, so that too.

>>105825822
Does your approach solve obscure memory leaks in Rust? Whenever a program written in Rust is sufficiently complex, it always leaks no matter what the program is, and as i continue to notice it, any such software quietly removes the focus on fixing obnoxious memory leaks and keeps it buggy and worse than an electron app for years. Apparently professional Rust developers do not know how to fix some of the leaks.
Or maybe everybody does what you do, which then results in obscure memory leaks?

>>105827470
>polite
Hey sure, I'm used to knee jerk shit flinging on here but if we'll be polite there's no need. Water under the bridge.
>crabs are retarded
Personally I had to wait for industry adoption to feel okay with Rust. It's crazy how the socks stereotype was not a stereotype for years.
>cs-project
Oh sure, but I'm not here to prove myself. I cobbled it together over 4 days to see if it was viable, and it is. Sadly, I'm going back to academia in a few weeks, so I don't have time to make this into something more substantial and less of a "F1RST P0ST" project. Nevertheless, I learned the language, and I intend to use Rust for any substantial comp chem that I do from now on.
You got my Github, I'd like to see yours.
>loonix
Exactly, it's going to be a goldmine of old and cheap fleet computers for us linuxchads. I've had this fantasy of putting together a blade server cluster from laptop motherboards for a couple years. I recently set up a k8s cluster with my brother from cheap hp elitedesks, and I think this fall could offer even better opportunity to build a low power high availability system.

>rust thread
>cnile sperg out
erry tiem

>>105827120
>this was the last bridge
>it can be done. its not optimal, but it can
>but you could also do some more fancy stuff like having an index where you have a address of the pointer-associated arena block. block which contains your non-deterministic-lifetime object alone
>or have second order arenas to avoid allocating/deallocating your stuff and use heuristics when allocating blocks your first order arenas
You are going to reinvent malloc very soon

>>105827570
>Oh sure, but I'm not here to prove myself.
its not about proving yourself
well, sometimes it is, but heres its more about your opinion and how founded it is
>you got my github, id like to see yours
i dont have a githoob. and best i can do is post some code from 3 years ago bc my current code is airgapped
and i dont have the environment to even compile it. i would need opencl which i dont have on this machine
and all you would see is numbers anyways. which isnt the interesting part, its that i dont have to wait for a moth to get them
but heres a header to give you an idea of the scale of the project
its a finance analysis tool i used to probe crypto for opportunities. it is the multi year project i alluded to earlier
im at or around version 20, its 4 years old now, and i still dont consider the project as complete since im still working on it
i have other projects but theyre either unfinished, in a dysfunctional state, or not worth mentioning at all

>loonix
>goldmine
i may have a look at it. i didnt give the situation much thought, but this may mean good opportunities
i tend to steer away from used hardware though. and performance-wise gpus are still king for throughput
so i will give it a think first

>>105827656
y-yeah i guess
but i will still call it an arena ^^

>>105827711
HAHAHAHAHA
nice header file, retard. show some code, dumb retard.

>>105827729
and wtf is it gonna tell you huh?
>calls you a retard
wow, such d&k

>>105827743
>(*(*ptr)
LAMAO

>>105827752
>3 years ago
>still made me fat stacks
and how long is your commute then?

>>105827765
ok :)

>>105827711
>>105827743
This type of low level boilerplate is one of the reasons I got fatigued on C and decided to learn Rust recently. But all the more power to you if you get your project complete with it and it worked.
I've never dug into quantitative analysis for crypto out, purely out of disgust for the lie. Then again, it's all the more ripe for opportunity when the majority of buyers are dumbass normies that believe they're buying "currency." What sort of data sources did you use?
>>105827778
something about this comment reeks of shit. shit in the street, even.

>>105817962
>>105818929

>>105827796
>This type of low level boilerplate is one of the reasons I got fatigued on C and decided to learn Rust recently
Nice blog post. Did you git gud yet?

>>105827796
hmm
from what i hear rusts boilerplate is just abstracted away
as for the crypto: i just used the average price.
thats it. all you have to do is to determine what are the signs of a whale buying, what the dynamics of the movement are, and then buy when they do
and obviously sell before they dump

its a financial product like any other
>but the hype
how is it any different with the legacy market?
what do you think all the ai-shilling on this board comes from? - it investor hype
same fucking shilling as "le currency" shit
same scam as people's investment funds, and 401k's. 401k's may be worse bc i heard some companies/states force people to invest into them
crypto haters ùyst have gotten burned on a dumb investment methinks
but its not the fault of crypto
one should always do their due diligence

>>105827835
This post is giving delusional poorfag. You must have spent too much time on /biz/.

>>105827855
lol, ur jelly
here let me step on you

>>105827835
Let me be clear, I have never gotten burned on crypto. YTD I have never been manipulated into a scam or lost money on crypto. I do like XMR and the related memecoins, but even in those circles there are such fools.
As you said, all of the value from crypto comes from demand, which is spawned by hype. This makes it even more distasteful than short term stock trading. I don't know how involved you are, but if you spend time in a normal industry and are then forced to interact with day traders and crypto bros spewing filth, you know what I mean.

>don't buy used hardware
Any reason? I guess if you're all-in on GPUs, that makes sense. I wouldn't buy used GPUs either. Laptops, computers, components though? I'll say I'm a usedcel. I love used computers. So cheap, plentiful. I love getting twice the specs for the same money, just because it was used by someone before me. I also never have to baby and take care of my hardware.

>>105827905
all the involvement i have with the cryptosphere is the dashboard of binance.
cryptobros? hype? whtas that?
i trade crypto specifically because its extremely volatile and so things like hype dont influence the curve at the time scale i operate on (~15 mins bw acquiqition and sale)
unironically short term investments in a highly volatile market are quite predictable because all the information that influences the curve, is contained within the curve. most of the time, black swan events do exist but so do counter-measures

>This makes it even more distasteful than short term stock trading.
??
whats distasteful about trading, esp short-term?
the impression that its unearned? if thats so simple why dont you try yourself, kek
and about the cryptobros- what about em?
cryptobros are bad, but planned obsolescence is not, right?
or is it that crypto is non-essential but an iphone is?
because iphones also get shilled
in fact, many companies use scummy tactics
like disney- if you used any of their products, and signed an eula with em, you have relinquished your right to sue them
thats not only a scam, but also enforced by the government, why the double standards?
and more importantly- these practices are accepted by society
i see no reason to differentiate bw crypto, tradfin, or even big corpo

>>don't buy used hardware
yup. all in on gpus. actually one right now, to be honest. i have a radeon 7 in my wo rk machine, i dont think ill need anything more for a while yet, im memory bound, so modern HW doesnt have much to offer me
i might go with a cluster of a770's in the future, but i dont need em yet

also i avoid used HW in general bc you never know what the previous owner did with em
im a waitchad. i wait for the right moment then snatch up new hardware at destock / second hand prices

>>105828060
nobody cares

>>105827835
>rusts boilerplate is just abstracted away
What I mean is actually writing the boilerplate. Yeah, Rust hides lots of boilerplate, especially macros like #[derive], async, and when chaining adapters. I don't mind as long as i can read the docs and understand it. On the other hand, Rust is like Python: I will never spend my time writing definitions and implementations for len(), cmp(), atoi(), etc. Instead, I spent my time programming websockets in a novel way. I actually like C quite a bit, but I'm coming from an angle where, for convenience, I'm using Rust because I don't want to use Python, but I want the nice-ness of a massive package library and having common shit already done for me in any easy to use expressive keyword or function.
>>105828060
>distateful
No, not because its un-earned, not because it's improper, not because its unintelligent, not because of anything. I'm up to date on tech companies ruining our lives, and I don't rank trading up there. You can be totally into it and be a normal person, just like you could be a big fan of insane clown posse and not be a faggot. I'm averse from people I have met, which it not uncommon. All the more power to you if it works all on your work.
>gpus vs laptops
With a used laptop, you can basically see how much use it got by looking at the ebay listing. GPU, it probably spent 4 years at 90C churning away sha256.
What are you doing with your gpus? Can't see any reason your quant system would run on them. Are you working on a game, or modeling?
>>105828302
You could join our conversation if you weren't an asshat with nothing to say. Post your project.

>>105828302
>attempt at being hurtful
>through gregarity argument no less
this is extremely ineffective, trany
and also it shoiws that youve been seething since a couple hours now

youre also autistic. because youre unable to visualize for shit, desperately suck at abstraction and are generally ignorant
you wanna know how i KNOW this?
because you cant wrap your head around the simple fact that people have varying psychological structures

this should show the terrible limitations of an autistic mind
if you autists wouldnt have an immature ego like the developmental retards you are, i would probably have compassion
but since youre very disagreeable people, i will advocate for your extermination, or at least, internment in mental asylums whenever applicable <3

have a nice rest of day thinking about me
i will immediately forget about you the second i will leave my chair (which will happen soon, i have to get groceries)

>>105828344
>typing this much midwit drivel
Touch grass bro. You're cooked. If you're not a bot, that is.

>>105828344
your "conversation" is beyond retarded

>>105828349
tldr

>>105828356
>>105828358
choke on your mother's feces in hell, samefag jeetstain. the pain of being surpassed by everyone you know in life will pass eventually, just 50 more jerkoff comments on 4chan and you'll be free

>>105828344
>>105828349
>Samefagging a wall of text, 1 second after the post timeout
OK bot.

>>105828369
>Everyone who replies to me is the same person.
Also a schizo bot.
Meds.

>>105828369
>samefag
>18:37:51
>18:37:59
hmmmmm

>>105828374
you are worthless and you should give up
you will never find love

its impossible for anyone above 70IQ to imagine posting about programming when you don't know any programming

>>105828393
>Oddly specific projection
Hope you have sex soon, anon. You clearly need it lmao.

>>105828344
>What I mean is actually writing the boilerplate.
you can do away with most of it
you reuse code, you dont need to reimplement the atois of this world all the time
but you do have to reimplement them at least once bc the libc's are shit
if rust works for you, then more power i guess

>What are you doing with your gpus? Can't see any reason your quant system would run on them. Are you working on a game, or modeling?
no, its for the raw throughtput. i get 1TB/s on my trusty ol R7
i work with snapshots taken once per second.
each snapshot is a 16 bit float value
i survey slightly more than 400 currencies
my database was founded in 2020
and i run thousands of tests
thats aloooot of data to move because alongside that theres the results of the tests which i cross reference to see which ones correlate with eachother and buy or sell signals (two tests might not corelate with a buy signal lets say, but 2 tests & (and operator) toegether might. so you have to exaust all the possible combinations of a set of tests)

>>105828489
>lil bro thinks he is jane street

>>105828512
>senpai, notice me
i did, a couple posts ago
and you didnt like it...

>>105828512
also my role model was blackrock
their aladin system
and the fact it was all built on the equivalent of a modern 200usd gpu
jane street can suck my cock

btw
theres another thread about why g is dying
and heres why: (you)
jelly autismo trash cant help themselves but disrupt the discussions of this board

>>105827552
Like java. Impossible to fix memory leaks when it happens.

>>105827552
Leaking memory isn't a problem as it is safe. Just buy more memory. What, are you poor or something? Get another job you fucking cheapskate.

>>105828584
>run out of memory
>crash
>your plane will now prosneed to plunge into the sea bc firmware was rewritten (tm) in (tm) rust (tm)

>>105828344
>>105828489
(cont)
also im going afk
ill be back in something like 45mins-1h in case it matters

>>105828611
>in case it matters
it doesn't/won't

>>105827787
Chudjak became chadjak. Chuds won.

>>105828595
At least it was a memory safe planecrash.

>>105828619
>still seething
and you will be for the next 45-1h
then you will seethe some more bc i will come back
so obviously it doesnt matter from your perspective
given that you seethe since that glorious thread 3 years ago, i think no amount of time is gonna restore your sense of self-worth

>>105828653
>schizo thinks everyone is the same person

>>105828626
baste
>>105828641
i guess in that case rust IS a GC language

aight im out
ill never leave otherwise

>>105828665
oh my science that's a lot of drugs, what's your favorite facci ouchhi?

>>105828665
but anon
youre the only one seething ITT
youre ust easy to spot

>xe didnt answer
lamao
i hoped he was still gonna be seething
i wasnt done bullying him yet

>>105826749
Your lies are getting even more obvious.

>>105827743
i think i've been harsh on LLM-generated code

>>105829883
i take that as a compliment because i just dropped out from school at that point
i also reviewed the rest of the code, for keks
its from 3 years ago
and it turns out that, no
its from 4 years ago
i didnt even use opencl in that version
i was trying to bruteforce finance with a fucking cpu
an fx 8350 nonetheless, by hand, and with the help of a fucking spreadsheet

i still found a buy signal
i still made some money with it
iirc its a rolling average of 6 periods over 180 seconds. so 30 secs per period, and you compare it with "now"
and if you see a dip over 6% of the initial value you have something like 80% of gaining 2 percent on the next 3 mins

you have to be in a bullish market doe otherwise youre catching the edge of a falling knife

>>105829962
>i just dropped out from school
ah, that explains your retardation

>>105830089
except id do cool stuff when youre installing one of 3 DE's for the 123456789th time
and dont try to bullshit me
thats where your venom comes from
you think what i do is unearned, because you think youre better than me

well
you got all you need to replicate what i did ITT
prove to yourself youre as good as me, and, maybe better, who knows

>>105830109
>retarded
>droupout
>bragging on 4chan
that's just sad

>>105830123
yeah but
its your opinion, right?
and i thought i was pretty clear what i think about you
so youw possibly could you expect to hurt me with your opinion?
when i quite literally live from my code? how more manifest my skills could be? they put literal food on the table
not bc im a protected group
not bc i know the boss
not bc im a rich daddy kid

just because im good
and now
you think your opinion can even reach me?
im verbose so that you take time to process the enormity of it lamao

>>105830123
He's actually the world's smartest C programmer.

>>105830166
nono, you read all of it
bc youre narcissistic

its a syndrome that overwhelms your whole personality
youre plain and uninteresting
your whole personality could be described in a couple directives
one of them is- "when you see a mirror, look at yourself you beautiful beast"

>>105830166
>>105830187
thats why you keep responding btw
you need positive feedback which would reinforce the image that you have of yourself

(positive feedback which you wont get from me. so you confront me to get it against my will. but thats where youre retarded becasue im clearly dominating you in every way)

>>105809113
lol nah Swift is a complete fucking meme.
t. tried Swift and gave up after 3 months

>>105822030
It literally does? Drop can drop your file handles and other resources so when the reference goes out of scope everything is cleaned up

>>105825338
Because they are 100% unsafe instead

>>105822008
End users and nocoders don't know or care what language the software is written in. Rust provides benefits for those who write the software.

>>105830401
actually- voice of reason
good on you, bruce
the end user doesnt fucking care as long as the maintainers deliver

>>105822008
Fewer bugs, faster programs, faster development time, more security and reliability.

>>105827499
So Haskell?

>>105830401
Rust is a filter for jeets and cniles so usually I'm happier with software written in Rust on average

Like ripgrep and stuff is pretty nice

>>105830401
>>105830412
Linux just werks. Simple as.
>>105830419
>Fewer bugs, faster programs, faster development time, more security and reliability.
Source?

>>105830512
NTA but
https://thehackernews.com/2024/09/googles-shift-to-rust-programming-cuts.html

>>105830419
>faster development time, more security and reliability
$ cargo build
building TroonWare...
downloading 850 dependencies from 850 untrusted authors
[40 minutes later]
50M binary ready for use

I could've rewritten in C and compiled 500 times before the Rust build finishes. What did I gain for all that glacial slowness? A "safe" version of my already perfectly safe C code? Top kek.

>>105830579
>The rewrite specifically focused on security was more secure
Fascinating.

>>105830579
>...as a "practical and incremental approach" to embracing memory-safe languages and ultimately eliminating entire vulnerability classes
Rust isn't memory safe, nor does it eliminate any "vulnerability classes". Whole article deboonked right there.

>>105806228 (OP)
Ever since Trump bombed Iran the number of Ruat shills has gone down.
Truly accelerates one’s cognition

>>105830704
>Rust isn't memory safe
Yes it is
>nor does it eliminate any "vulnerability classes"
It eliminates use-after-free and double-free

>>105830687
>>The rewrite specifically focused on security
That's why they chose Rust.
>>105830704
Sure buddy.

>>105830748
>Yes it is
What does it have an unsafe keyword then?
>It eliminates use-after-free and double-free
It doesn't.

>>105830775
Why does it*

>>105830755
>That's why they chose Rust.
Not an argument.

>>105830775
Safe Rust is memory safe and is what 99% of Rust users are writing.
Unsafe Rust is not, but if you're writing it then you should know what you're doing anyways.

>>105830839
The first Rust program I ever wrote needed unsafe lol. I doubt 99% of rust programmers aren't touching it (given how much unsafe is spammed in the stdlib, it looks like you need unsafe to do pretty much anything useful in Rust).

>>105830775
To implement safe abstractions in Rust that cannot be proven safe to the type system.

>>105830989
Because you wrote a linked list which has a bazillion implementations already

I wrote thousands of lines of code for an AI that can play Go and none of them needed unsafe

>>105830989
And what program was that?

>>105831011
Good for you. Please tell me you didn't use Rc or Arc?

>>105830358
>Drop can drop your file handles and other resources so when the reference goes out of scope everything is cleaned up
Drop is Rust thing, not zig.

>>105831047
NTA but why wouldn't I? It's strictly better than naked pointers. In C++ I'd use shared_ptr too.

>>105831105
Ok cool. That tells me everything I need to know.

>>105831047
I did use Arc, but only to send the copy of the config around so it has no performance impact since that doesn't get constantly allocated and freed

>>105831125
Glad it did. Also says a lot about people who do not understand or know to use shared_ptr effectively.

>>105831079
Rust has a Drop trait that runs destructors
https://doc.rust-lang.org/rust-by-example/scope/raii.html

>>105831149
Says a lot about people who strap garbage collection onto systems programming languages but refuse to acknowledge they are using a (shitty) garbage collector.

>>105831185
Manual garbage collection is still garbage collection

>>105831173
I was talking about zig you retard.

>>105830839
>Safe Rust is memory safe
Safe C is memory safe.
>Unsafe Rust is not
Unsafe Rust, AKA Rust.
>but if you're writing it then you should know what you're doing anyways.
Cope.

>>105831288
>Safe C is memory safe.
There's no such thing as safe C.

>>105831134
>send the copy of the config around
NTA, you can use static mutex/RWLock for this too.
I use Arcs when sharing non-static data across multiple threads.

>>105831307
>There's no such thing as safe C.
you did a retard
do you want to do over what you just said?

>page 2
nono
this is important

fukken paiton is written in c
what do you mean not memory safe, you fucking crab?

>page 2 again
fukken death to crabs i guess
lmaoing at your failed language you work on since 18 years

>>105831307
Of course there is. It's C without any bugs. Exactly the same concept as safe Rust. There's literally no difference.
>b-but muh compiler checked lifetimes
That's a tiny subset of bugs.
>but muh stats show otherwise
90% of everything is shit. People who write shit C write shit Rust too, so this is just another example of the Rustoid's "but at least it's better than absolute dogshit" talking point.

>>105831484
>People who write shit C write shit Rust too
fenk yuuuu
EVERY mem issue in C is an algorythmic problem
how are you gonna solve security with a lang that checks everything BUT ALGOS

>>105831484
>That's a tiny subset of bugs.
and in any case, the Rust language contains the unsafe keyword. Can't get any more unsafe than having a whole keyword dedicated to it, lmao.

>>105831505
>EVERY mem issue in C is an algorythmic problem
Likewise for unsafe Rust. Have you tried just writing correct code?

>>105831454
Fucking kek. Rustroons on suicide watch.

>>105831507
yeah but then it doesnt work as intended bc it forces an artificial complexity

no, srsly
look at this fucking dogshit
im 1 gorilion percent sure theres a false security factor going on somewhere
>>105831518
>Have you tried just writing correct code?
i have 500k of C under my belt
yes it took 200K before i started being error-less
but now im there i dont need red tape

what i posit is that we should take programming as seriously as medicine
5 year study then specialization

>>105831529
they never stood a chance to be honest
and thats 100% on how you cant be political in your code

>>105831484
C without any bugs doesn’t exist. Safe Rust provides a good amount of guard rails and useful abstraction.

>>105831507
errr
i completely fucked up the picrel
>false positives
yeah
and how "rust takes care of everything"

>>105831507
its not a firster either
same fucking crate
same fucking problem
so theres two solutions:
either crabs are untrustworthy
or its just a supply chain attack
and crabs are untrustworthy

>>105831454
If it’s an “18 year old failed language” why does it need to be highlighted in page 1?

>>105831554
>i have 500k of C under my belt
What does that even mean? How did you count? Totally blew the believability of the lie with that one, champ.

>>105831606
because this
>>105831582
>>105831567
logically theres no other way around the fact that roost is a greedy cashgrab
with the annihilation of free software to boot bc the licenses and such
its fukken baaaad

>>105831561
int main(void) {return 0;}

Show me the bug, Bruce.

>>105831623
>>105831615
damage control

i will end up believing that bruce is an evangelist
but you two are scum

>>105831637
>you two are scum
Source?

>>105831623
Not all platforms may use 0 as success code ie the windows API/OpenVMS etc
You failed to write one line of bug free C.

>>105831653
ITT
youre creating a context to push a man against his own judgement
how is it not villany?

>>105831662
Works on my machine.

>>105831622
That looks like a strawman argument. Rust reduces a lot of bugs, doesn’t promise to eliminate them.
It has a lot of useful guardrails that come in handy in real world scenarios

>>105831678
Concession accepted
(Smug Basedjak meme)

>>105831682
yeah but why the licence change, then?
or something
explain that one for me
you alrdy know im not dogmatic about this shit
you have the soapbox
have at it

>>105831682
>Rust reduces a lot of bugs
I find that hard to believe. Does Rust write itself?

>>105831715
theres certain cases where it forces corectness
its not 100% but its 70+, it is a thing

>>105831701
GPL is losing popularity all across the board not just in Rust.

>>105831697
Can you show me how to reproduce the bug, Bruce? It just werks for me, so I don't understand the problem.

>>105831723
unsafe{segfault()}

Where's the forced correctness?

>>105831715
>>105831723
and thats the whole fukken debate
->is it worth it to learn tons of shit to be insured, but onloy in 70% of the cases
>>105831729
thats a non-answer and you know that
>>why is an ti corpo shit getting pushed off the table
>welp, its because it gets pushed off the tablme i guess

>>105831744
in the ethos
in the same way you avoid void * in your code when using c
why didingenuous?
i talk code, not politics (now)

>>105831751
>you avoid void * in your code when using c
lmao, nocoder spotted.

>>105831747
>onloy[sic] in 70% of the cases
More like 5%.

>>105831776
>doesnt use the compiler as a copilot
sharty negro = opinion automatically retarded

>>105831751
>in the ethos
My ethos in C is just to not write bugs. Simple as. Works every time.

>>105831784
depends on the code
i write opencl which is beyond guarantees of either c or rust
its another device, actually, which interacts with your ram
you just cannot "safe" that interaction

>>105831789
Not an argument.

>>105831808
none needed with shartynegroes
do you want picrels?

why does this thread exits what reason to discuss rust is here

>>105831744
If you use unsafe you are waiving guaranteed memory safety

>>105831808
yeah shartywhore
which picrels you want?
the pedos
the tranis
or when aubrey fucking cottle the snitch posts on your board?
>>105831835
its one of the last things that get engagement
ban the tranimeposters already
let the board resurect
except high iq tranimeposter
although i bet he posts on pol now

>>105831808
i even have picrels i could send to the fuckign fbi
bc you have such a bad fucking opsec
KNOW YOUR PLACE GODDAMIT
WHY DO I HAVE TO REMIND YOU EVER SO OFTEN
WTF IS YOUR PROBLEM WITH BOUNDARIES? ARENT YOU WHITE
GAH DAMMIT FUKKEN SHARTYNEGROES

fukken
*throw a shoe at (you)*
go away ffs
or at least, behave

>>105831949
Meds.

>>105832018
>mfw they dont wo rk
also : no
sharty are jewcrainians
only jewcrainians are that fukken brazen
and what the fuck was it about posting thet theres p on b
that means you lu rk b
and you dont fukken report p
tf am i supposed to think about shartynegroes?

>>105831852
Unsafe is part of the language, so the language isn't memory safe. Hope that helps clarify things for you.

>>105832018
aaaaaaaaaaaaaaaa
forgot picrel

>>105832065
yeah but its /ourpedo/
also long time no see hi iq tranimeposter
the board went to shit while you werent here

>>105832052
Wrong. Rust is 4 languages posing as 1 language.

>>105832065
>yeah but its /ourpedo/
im a poole idgaf abt belgioom, you know me, right?

(well, almost, since i live here, i ts actually werd now bc i think im more of a globalist actually. i used to cross poland out bc they accepted jewcrainians but they stand agtainst the germanoids. so i might give them a chance, idk)

>them
im at a fucking crossroads lads
i dont expect you to weight on
but its fucking weird.
polishanons weigh in. idk i kinda wanna go back to the country bc stuff makes me very angry
alrdy since the whole jewcrainian thing
and now germoney is at it? its kinda wtf and breakage of social contract, idk
kinda makes me angry

>>105832128
>Lost his marbles
I accept your concession.

>>105831731
Sure, compile and run this program in OpenVMS
>>105831747
All mainstream languages are corporate. You can’t single-out Rust. I don’t see you complaining about Python, C++ or Node ecosystem.

>>105832152
delusional
>>105832157
I don’t see you complaining about Python, C++ or Node ecosystem.
these aint shilled as c replacements
and, more importantly- they arent inadequate at that
im perfectly ok with a c replacement
but it has to pick up on the traits of c
and improve on everything that matters to me

other things matter to you
thats ok
then you go with python, js, typescript
or rust. i guess
i think its a solution looking for an answer
but if you can do a good job with it
then prosneed i guess
the job speaks from itself

>>105832157
>Sure, compile and run this program in OpenVMS
It exits with 0 successfully. That's exactly what I wanted it to do. Not seeing the bug.

>>105832157
>>105832206
Is the bug in the room with us now, Bruce?

>>105832206
The success code in OpenVMS isn’t zero. You failed.
>>105832214
>cniles cannot see the bug
Classic
>>105832204
I don’t understand your premise. You’re fine with GPL software being replaced if theyre not written in C?

>>105832355
>The success code in OpenVMS isn’t zero
OK, what's your point? It worked around the bug in OpenVMS and exited exactly how I wanted it to.

>>105832398
You didn’t. The reason you returned hardcoded 0 because you lack the knowledge about return codes in different platforms.
Hold the L and drop the mental gymnastics.

>>105832417
It didn't crash thoughbeit. Can you say that about Rust?

>>105832417
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdlib.h.html#:~:text=exit()%3B-,evaluates%20to%200,-.
Looks like I've done you, Bruce. No one cares about non-POSIX platforms.

>>105832454
>portability suddenly doesn’t matter
Gotta love the mental gymnastics of an average cnile in /g/
At least the boomers in LinkedIn will hold the L like a trophy

>>105832434
>bugs don’t exist outside krashes
Kek

>>105832504
Portability to OpenVMS never mattered. I'll accept your clutching at straws as a concession.

>>105831615
>What does that even mean? How did you count? Totally blew the believability of the lie with that one, champ.
He/she counted the header files.

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

>>105830358
Wrong. And unsafe is not easy relative to other languages, otherwise please explain tree borrows, pinning, aliasing, how to write cyclic data structures efficiently, and the incompleteness of specification of how to write correct unsafe code.

>>105831561
And yet for Rust development, Miri, Valgrind and gdb are still recommended.
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>105831682
Yet Rust can make some tasks harder to get correct.

>>105833044
NTA, Rust stdlib doesn't do anything special that other stdlibs don't do already. Standard libraries exist to be the most basic abstractions over operating system and the machine so they always involve some code that can't be completely analyzed statically.

>>105833134
Correct as in sound/no-UB or correct as in write code that compiles at all?

>>105833143
>Rust stdlib doesn't do anything special that other stdlibs don't do already.
Unsafe is more difficult than C and C++, and the Rust standard library has lots of unsafe. And UB has been found a lot in the Rust standard library. If the Rust standard library writers cannot handle unsafe, can anyone?
>>105833152
Correct as in making the code correct, which includes but is not limited to avoiding UB.

>>105833233
No, nobody can write perfect code. That's why you need machine assisted proofs.

>>105833233
Show me a language that never had any bug in it's standard library.

>>105833044
>crossbeam
>uses unsafe
What have you proven exactly? That unsafe code can have bugs? Yes, we know.