← Home ← Back to /g/

Thread 106315086

261 posts 38 images /g/
Anonymous No.106315086 >>106315219 >>106315232 >>106315362 >>106315862 >>106315885 >>106315922 >>106316431 >>106316445 >>106316598 >>106316941 >>106316963 >>106318019 >>106318052 >>106318399 >>106319684 >>106320254 >>106320481 >>106320671 >>106322582 >>106323205 >>106324143 >>106324937 >>106327089 >>106328004 >>106329463 >>106333414
where is Rust? why is C and C++ first if it's so unsafe?
Anonymous No.106315219 >>106316453 >>106316993 >>106322637 >>106324956 >>106325627
>>106315086 (OP)
they have coding guides that ban you from doing autism showoffs like *((*(++i))++)
https://www.sei.cmu.edu/library/sei-cert-c-coding-standard-rules-for-developing-safe-reliable-and-secure-systems-2016-edition-2/
Anonymous No.106315232 >>106316223 >>106317896 >>106318384 >>106319838 >>106322671
>>106315086 (OP)
ada is pretty much a better rust desu. much better syntax and solves the same problems
Anonymous No.106315282 >>106315316 >>106315396 >>106315835 >>106315854 >>106317744
>Ada 83

That seems odd to me? Do they have tooling that hasn't been updated for newer Ada versions?
Anonymous No.106315316
>>106315282
Chart old prob.
Anonymous No.106315362 >>106315825 >>106315883 >>106318035
>>106315086 (OP)
the F-35 began being developed in the early 2000s
the first version of Rust wasn't released until 2012
Anonymous No.106315396
>>106315282
It's probably some less critical legacy systems.
Anonymous No.106315640
you can audit C and understand what every bit is doing across the entire program

if you audit rust, you have no idea wtf is actually happening
Anonymous No.106315825 >>106315887 >>106329601
>>106315362
rust v1.0 was released in 2015 AKSHUUALLY.
and qualified chains only appeared a few years later.
and i'm not sure any tech would actively want to be associated with SunkCost-35 anyway. lol.
talk about languages is moot in these contexts in any case. because the development process is so distant from the "normal" one, that attempting to extrapolate anything for the latter from the former would very much be a retarded pursuit.
Anonymous No.106315835
>>106315282
>Do they have tooling that hasn't been updated for newer Ada versions
it's about serviceability and reliability. a lot of military stuff relies on certain versions of a programming language as it's been thoroughly tested, approved by government security bodies etc. it's not so easy to just use an updated version when you got hundreds of billions of dollars worth of gear that needs to work.
Anonymous No.106315854
>>106315282
they took some code from F22, that's why
Anonymous No.106315862
>>106315086 (OP)
>C++
Exceptions are banned for the F35, it's a dialect of C++.
Anonymous No.106315883
>>106315362
This is it. I also assume they used a baseline from the previous gen fighter as a starting point. They also don't need Rust, the planes crash just fine without it.
Anonymous No.106315885
>>106315086 (OP)
Because it was developed before Rust even existed? Are you retarded?
Anonymous No.106315887 >>106316338
>>106315825
>i'm not sure any tech would actively want to be associated with SunkCost-35 anyway. lol.
it's like you think programming languages have a choice or something?
>lol
drooling retard
Anonymous No.106315922 >>106315970 >>106323085
>>106315086 (OP)
>uses object oriented shit languages
>Not using only C, assembly and Ada
Safety critical systems require extremely low overhead, first and foremost. I don't know why the fuck you'd need a shitload of classes and huge layers of abstraction in there. Working on shit like this should be like organizing piles of bricks into specific manageable sizes and then bridging them together using a common interface instead of building jenga towers.
Anonymous No.106315970 >>106316030
>>106315922
C++ since the project suffered heavily of "just one more feature bro". It's a necessity for sanity's sake since it's probably just a really advanced game engine simulating physics as fast as possible
Anonymous No.106316030 >>106316396
>>106315970
>It's a necessity for sanity's sake since it's probably just a really advanced game engine simulating physics as fast as possible
Probably some sort of advanced 3D vector threat mapping or some shit like that. You can tell they wrote it like shit because pilots that flew it reported that input controls were slow and the helmet visor was clogged full of visual displays that impeded their ability to fly. Funnily enough C++ was supposed to make it easier for people to write efficient, modular, and reusable code but they ended up building tofu dreg monoliths. That's entirely self defeating.
Anonymous No.106316223 >>106316363 >>106316384
>>106315232
>ada is pretty much a better rust desu
source?
Anonymous No.106316338 >>106316478
>>106315887
>doesn't know about the commercial stake holders of "certified" tech, let alone developers, advocates, and other involved people
>and/or autistic plus ESL/ETL
what are you even doing in this thread?
Anonymous No.106316363
>>106316223
https://www.adacore.com/about-ada
Anonymous No.106316384 >>106316423 >>106321385
>>106316223
adacore probably lmao. who tried to co-opt qualified/certified rust btw, while running anti-rust campaigns.
there is no limit to the number of people and entities feeling the threat of rust exposing their long running scams, or their fully antiquated existence.
Anonymous No.106316396 >>106316663
>>106316030
considering C is heavily used over it in the system, it's probably just interfaces for modular support which is correct usage.
Anonymous No.106316423 >>106316463 >>106317896 >>106318581 >>106321421 >>106321457 >>106321482 >>106323761
>>106316384
no, a lot of auditors and C vets are just sick of the tranny syntax language that can't quite do it all. rust is exceptionally weak at object oriented which is a necessity in fast iteration. ada works much better and has better abi support for outdated repos still being used today
Anonymous No.106316431
>>106315086 (OP)
Don't ask; don't tell
Anonymous No.106316445 >>106328046
>>106315086 (OP)
almost everything is build on top of C and C++ including other languages
example
python is made in C
js engines are made in C and C++
.NET is made in C++
etc
Middle/Low level software is made in C/C++ ie:
Real time operating systems
Operating Systems
firmware
High performance software
C and C++ are unsafe languages because many of the operations involving consequences in the execution environment requires unsafe access (to cause consequences)
Example if you need to point to an specific and operate it , you need unsafe access to the memory location where is mapped then read/write

Rust only avoids to allow the programmer to escape safe guards unless ins necessary but doesn't prevent them to write unsafe code and also requires more mental gymnastics which at the end of the day is stupid.
Anonymous No.106316453 >>106316649 >>106316728
>>106315219
> *((*(++i))++)
If you need a coding guide to prevent you from doing this you should not be programming.
Anonymous No.106316463 >>106316472 >>106316560
>>106316423
lmao. use an llm (or a better one) next time. it's will sound less retarded.
Anonymous No.106316472
>>106316463
>r-retard
I accept your concession, troon
Anonymous No.106316478
>>106316338
> noooo! not like this
the communist child rapist cries out in pain as he strikes you. it's ok, vlad. you have those trash migs and that inferior f35 copy that the chinks made.. that can be seen by radar.
Anonymous No.106316560
>>106316463
>it's will
Learn english.
Anonymous No.106316598
>>106315086 (OP)
F-35 was written before Rust hit v1
Anonymous No.106316649 >>106322439 >>106337324
>>106316453
private static Map parseJavaArgs(String[] args) throws Exception {
Map result = new HashMap(args.length);
for (int i = 0; i < args.length; i++) {
System.out.println("Arg: " + args[i] + "=" + args[i + 1]);
if (args[i].charAt(0) == '-') {
result.put(args[i].substring(1), args[++i]);
} else {
throw new Exception("Bad arg: " + args[i]);
}
}
return result;
}

written by a dude with 25 yoe at work
Anonymous No.106316663 >>106317786
>>106316396
Yeah, but if they write it like shit then it's useless.
Anonymous No.106316728
>>106316453
and that's actually beautiful if you think about it that kind of patterns could be useful for mathematical efficient operations
Anonymous No.106316941 >>106316982 >>106324762
>>106315086 (OP)
that's a lot of percents
Anonymous No.106316963 >>106321522
>>106315086 (OP)
C/C++ is safe when it's written by a white man, not a pajeet.
Anonymous No.106316982
>>106316941
for you
Anonymous No.106316993 >>106317322 >>106317346 >>106321529
>>106315219
That’s for… uh.. government work.
C++ and Rust are both written in C and run on operating systems written in C.
More than 99% of rust code was C2Rust translator output slop. Including the cranelift slop.
Rust in a nutshell.
Anonymous No.106317322 >>106317549
>>106316993
>C++ and Rust are both written in C
Every popular C compiler today is written in C++.
Anonymous No.106317346 >>106321295
>>106316993
>C++ and Rust are both written in C
Can you show me the C code?
https://github.com/rust-lang/rust/tree/master/compiler/rustc
Anonymous No.106317549 >>106317590 >>106318502
>>106317322
and c++ is written in c
Anonymous No.106317590
>>106317549
>anon doesn't know what self-hosting means
Anonymous No.106317744
>>106315282
I think the latest Ada they're likely to use is Ada95 as they're using the Green Hills compiler.
https://www.ghs.com/products/ada_optimizing_compilers.html
Anonymous No.106317786
>>106316663
>if
assuming isn't proof that it is coded like garbage and at that level of required competence it probably isn't terrible like you claim
Anonymous No.106317896
>>106315232
>>106316423
>syntax
nocoder detected
Anonymous No.106318019
>>106315086 (OP)
>where is Rust?
Now I want to see a sixth generational aerial combat of Rust powered airplanes. If you had a spitfire you'd win because everyone else would ack xerselves.
Anonymous No.106318035 >>106328065
>>106315362
Seems like it's ripe for a rewrite in Rust.
Anonymous No.106318052 >>106320312
>>106315086 (OP)
ayo that chart tho, did they render it with libreoffice or what
kek
Anonymous No.106318384 >>106318554
>>106315232
only people who don't use ada (or rust for that matter) say this
Anonymous No.106318399
>>106315086 (OP)
i don't have evidence but trust me bro, any language is fine for this shit as long as it passes the hellish year-long homologation process mandated by law.
Anonymous No.106318502 >>106320255
>>106317549
the cfront transpiler is no longer being used, nowadays you can compile gcc using gcc so whatever
Anonymous No.106318554 >>106324592
>>106318384
there are no engineers, software developers, or even code monkeys here. it doesn't matter what language. if you don't think that's the case, ask them to post code. lol.
best you get is sophomores tarding with the new five words they learned. or literal tech illiterates kvetching about "syntax". maybe you get a script kiddy here or there, and those would be the top of the crop.
and this is a good /g/ hour still. most /g/eets are asleep. their shit will be smelled in ~12 hours.
Anonymous No.106318581 >>106318990
>>106316423
>no, a lot of auditors and C vets are just sick of the tranny syntax language that can't quite do it all.
read: couple of cnile midwits started to smell their retirement, so they bring up that ada thing they have heard about 15 years ago and start to shill it despite never using it as a last attempt to dunk on Rust
Anyone who has used Ada knows how much pain in the ass it is to do general programming in it. Also "solves the same problems" is just straight up lie. There is a notable intersection between two but each has different kind of autism. Ada can't even free dynamic memory in a safe way.
Anonymous No.106318990 >>106321591
>>106318581
It's actually insane how mad rustroons get when they hear Ada mentioned. I heard other anons talk about it, but to witness it in person is quite something.

Personally I use Ada because I don't really like C++, and picked it up around 2015 without even considering Rust.
>Ada can't even free dynamic memory in a safe way.
This is true, but ameliorated by a programming style which leans more on dynamic creation on the stack, and if you use the built-in datastructures have to rely on the implementation to allocate/free correctly. That's a bit "trust the science" but every Rust programmer finds themselves in the same predicament when they use an unsafe block.
Anonymous No.106319684 >>106320272
>>106315086 (OP)
pilots would get HIV if rust were used so
Anonymous No.106319817
>340,534,53%
>562,931,35%
>115,099,7%
>71,400,5%
>1,094,0%
saaar
Anonymous No.106319838 >>106320129 >>106320261
>>106315232
>ada is pretty much a better rust desu
It's named after a real woman, which is probably why the Rustroons hate it so much.
Anonymous No.106320129
>>106319838
TRVKE
Anonymous No.106320254 >>106320282 >>106328083
>>106315086 (OP)
Rust is a cool idea and looks nice on paper but in reality, where things are messy and everything isn't this clean a -> b transformation with minimal state and mutation then the language just doesn't work (just like all functional style languages).
Anonymous No.106320255 >>106324269
>>106318502
the c layer is always there under the hood it was used to make c++ the first time
Anonymous No.106320261
>>106319838
>a real woman
no she was a hoax woemn dont eixist
Anonymous No.106320272
>>106319684
>HIV
That depends. If the pilots only limit themselves to sucking trans cock then, while technically possible to contract HIV, they would be the first officially recorded human to catch HIV from cock sucking if they do, so it might be a worthy endeavor if they can resist taking it in the pooper.
Anonymous No.106320282 >>106320339
>>106320254
Rust is imperative just like C and C++.
Anonymous No.106320287
>hurr durr why wouldn't you use this relatively new language we're figuring out as we go instead of an old version frozen incredibly well explored language????
who can say?
Anonymous No.106320304
Ayo, troons deadass gettin' cooked in here.
Anonymous No.106320312
>>106318052
Bruh... I'm dead.
Anonymous No.106320339 >>106320364
>>106320282
It's pretty much a an oop-lite/functional language. It's closer to Java than it is to C.
Anonymous No.106320364 >>106320404 >>106321600
>>106320339
Java is a managed OOP language. Rust is a systems programming language and no OOP. By all means, it is closer to C than Java. I would say even C++ is closer to Java than Rust, given its inheritance autism, virtual functions, overloading, etc.
Anonymous No.106320404 >>106320421 >>106322063 >>106328095
>>106320364
Yes I would say C++ is closer to Java than it is to C and so is Rust. Rust is a managed language. The borrow checker is a method of doing automatic memory management without the need for garbage collection and it's why you need to use a bunch of bullshit escape hatches to get the same level of control you get in C and it's the same level of bullshit you have to do in something like Go to get pure, unfiltered access to controlling the hardware. Also given Rust's adoption in say something like webdev vs os/kernel/embedded/game dev, it's more apt to call an web/applications language. The devs might have had the intention of it being a systems lang, like Go, but it hasn't turned out that way.
Anonymous No.106320421 >>106320523 >>106321931
>>106320404
>Rust is a managed language
It is not because it can run on bare metal.
Java is a managed language because it runs on JVM.

>The borrow checker is a method of doing automatic memory management
Borrow checker has nothing to do with memory management. It doesn't allocate or deallocate anything. It's a static analyzer and it functions in heapless environments as well.
Anonymous No.106320481
>>106315086 (OP)
How much of that is GPL?
Anonymous No.106320523 >>106322760
>>106320421
So Go and swift aren't managed languages lol? There is more java on embedded devices than there every will be Rust on embedded so there goes that theory of yours. The borrow checker has everything to do with memory management. How the fuck would Rust prove a use after free without it? The borrow checker is tracking and enforcing the memory management model of Rust such as not allowing me to use a variable after passing a variable to a function. I cannot do that if it isn't tracking and managing allocations. It's collecting metadata and running checks behind the scenes to confirm the validity of your program and still freeing memory for you.
Anonymous No.106320671 >>106323294
>>106315086 (OP)
Be the change you want. Call your representatives to tell them that all the F-35 code must be rewritten in Rust.
Anonymous No.106321295
>>106317346
>what is bootstraping
it was at some point written in OCaml
also LLVM is C++ which rustc uses anyway
Anonymous No.106321385 >>106324557 >>106326613
>>106316384
>who tried to co-opt qualified/certified rust btw, while running anti-rust campaigns.
Source? I thought Ada and Rust and other languages had joined against C and C++, considering the adoption of C and C++.
Ada somewhat recently was inspired by the borrow checker, but I know very little about Ada.
Anonymous No.106321421 >>106322801 >>106328117
>>106316423
Rustacean poisoning the debate well detected.
Unsafe Rust is more difficult to reason about than C, and that issue is made infinitely worse by the Rust Foundation lying repeatedly through their teeth about that topic and officially according to their website paying people to evangelize their language instead of fixing the issues in Rust. Why do Microsoft, Google, etc. spend a lot of money on donations to the Rust Foundation, just so that the Rust Foundation can use that money to evangelize? Kickbacks?
Instead of evangelizing Rust, you should fix your language.
Anonymous No.106321457 >>106322292
>>106316423
Also, Rust is not memory safe, Rust is not even close to being memory safe.
Anonymous No.106321482
>>106316423
>rust is exceptionally weak at object oriented which is a necessity in fast iteration.

Why focus on fast iteration? Though even in systems where that is a high priority, the borrow checking and the difficulty of unsafe is more likely to be the cause of that.
Anonymous No.106321522
>>106316963
Neither Rust or C or C++ or Ada is safe when written by almost everyone.
Anonymous No.106321529
>>106316993
Source on that, well-poisoning Rustacean?
Anonymous No.106321591 >>106321635
>>106318990
>Personally I use Ada because I don't really like C++, and picked it up around 2015 without even considering Rust.
What compiler and tools do you even use? Gratis and open source, or do you pay for the compiler? Do you have any open source projects written in Ada?
Anonymous No.106321596
Do I need to be a 1000x engineer to have all my code add up to 1000%?
Anonymous No.106321600 >>106322760
>>106320364
>Rust is a systems programming language and no OOP.
Does this fit with 'dyn'?
Anonymous No.106321614
>tfw you will never write software for a fighter jet
ehh bros
Anonymous No.106321635
>>106321591
GNAT FSF (part of GCC), so gratis and libre. I don't have any open source projects.
Anonymous No.106321931 >>106322760 >>106324919
>>106320421
>Borrow checker has nothing to do with memory management. It doesn't allocate or deallocate anything. It's a static analyzer and it functions in heapless environments as well.
Are stack allocations not part of memory management?
Anonymous No.106322063 >>106322304 >>106328410 >>106328425 >>106329459 >>106335087 >>106335119
>>106320404
>Rust is a managed language.
I think this depends on the definition used. If one goes with the definition of "idiomatic code does not have runtime overhead for memory mamagement", then some Rust might fit. In Go, it would probably not be idiomatic to not use the garbage collector. In D, many libraries assume the garbage collector from what I hear, so D in practice might be more or less a managed language. When in Rust people write Arc (atomic reference counting) all over the place, it's fairly managed. But when Rust code avoids such features, it can be unmanaged, despite what hoops one has to go through, especially in unsafe, which is more difficult than regular Rust. Consider for instance the infamous double-linked lists in Rust.

Many complain about the borrow checker in Rust, to the point that there are several crates for avoiding using the borrow checker, with different trade-offs.

"no_std" is an option in Rust, similar to C++ with no standard library. But, that actually makes it very easy to accidentally get UB even in safe Rust, for instance through something as basic as a stack overflow.
Anonymous No.106322282
Cool chart
Anonymous No.106322292 >>106322304
>>106321457
How so? (Not a Rust fag I just want to know what Rust is lying about).
Anonymous No.106322304
>>106322292

>>106322063
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
Anonymous No.106322439
>>106316649
I love Java but this code is just embarrassing
Anonymous No.106322582 >>106322614
>>106315086 (OP)
because that trannie language is just one big astroturf thats why.
rust foundation spends a lot of money on pajeets writing posts appraising rust on reddit and alike
Anonymous No.106322614 >>106322696 >>106322779
>>106322582
>because that trannie language is just one big astroturf thats why.
There are some good aspects to Rust, but it also has significant issues. And the lack of honesty makes it way, way worse.
Anonymous No.106322637 >>106322758
>>106315219
It's not that hard to be secure, just don't do stupid shit thinking you're clever. Coding guides are for pajeets that can't think things through.
Anonymous No.106322671 >>106322817 >>106328022
>>106315232
C is pretty much a better ada too.
it's VERY easy to have formal tools generate safe and secure C code or to hand-write it, this is what they do, this is what space agencies do, this is what military do, this is what critical scada software are written in, this is what I do, why is the FOSS world unable to? are they stupid?
I've also seen multiple moves to replace aging ada code by C++17 code...
in the end C and C++ will outlive us all, all these other languages are fun experiment but in the end, when it matters we always come back to C and C++.
if it's good to make simulations of rockets, manage the real-life rocket, make the real-life rockets come back to earth then it's good enough for your trashy SaaS with 0 clients, it's good enough for your vmm and your motherboard firmware.
the actual issue with C and C++ is the third-world has access to it
Anonymous No.106322696 >>106322729
>>106322614
i did not say its completely useless
it has its audience, sure, but the current hype about it is severely overblown
primarily due to the rust foundation's "advertising" efforts
Anonymous No.106322729
>>106322696
>primarily due to the rust foundation's "advertising" efforts
Some of the people officially hired and paid by Mozilla to do evangelism and fundraising regarding Firefox and Rust at Mozilla, stayed in the Rust ecosystem after Mozilla cut a lot of monetary support for Rust. They have many years of experience with this subject.
Anonymous No.106322758 >>106322771
>>106322637
Security and safety (safety should not be conflated with "memory safety", the two are completely different, and Rust is also not even memory safe despite claims to the contrary) should not be underestimated, and there are incompetent liars everywhere, you absolutely have to vet each person carefully, among many other aspects. Rust makes some things easier, but makes other things harder regarding security, for instance unsafe being harder than C and C++. Ada is not a panacea either, like with the fatal disaster of Ariane 5 that involved Ada. You simply cannot go "this language is safe!". That can lead to deaths.
Anonymous No.106322760 >>106322851
>>106320523
>So Go and swift aren't managed languages lol?
Go is a managed language because it requires runtime with GC.
I don't know swift.

>There is more java on embedded devices
That doesn't make Java any less of a managed language. It requires a JVM to run.

>The borrow checker has everything to do with memory management.
[citation needed]

>How the fuck would Rust prove a use after free without it?
>The borrow checker is tracking and enforcing the memory management model of Rust such as not allowing me to use a variable after passing a variable to a function. It's collecting metadata and running checks behind the scenes to confirm the validity of your program and still freeing memory for you.
That's static analysis, not memory management.
Borrow checker doesn't exist in runtime and memory management is something you do in runtime.

You have no idea what you are talking about.

>>106321600
Trait based polymorphism is very different from OOP style inheritance based polymorphism.

>>106321931
Rust doesn't support stack allocations(alloca)
Anonymous No.106322771 >>106322851
>>106322758
Rust is no less memory safe than Java, which is what coined this term in the first place.
Anonymous No.106322779 >>106322851
>>106322614
What are the significant issues of Rust?
Anonymous No.106322801 >>106322851
>>106321421
>that issue is made infinitely worse by the Rust Foundation lying repeatedly through their teeth about that topic
Can you link these lies?
Anonymous No.106322817 >>106322896
>>106322671
Rustacean suspected.

It would be sad if C and C++ will be the only systems programming languages indefinitely. I think it would be good if there is a healthy software development ecosystem with several viable systems programming languages with language communities of good size. Rust has issues, but hopefully they work on them and have success fixing them (so far that is possible), and I personally hope for successor languages to Rust and C++. Though the Rust community being significantly dishonest makes it harder to create good successor languages. I hope the Rust community is not trying to use its dishonesty in part as a "moat", as the managers and indoctrinated developers of orange Reddit giving away their expertise and talent in demented startups they lose ownership of would say. And the Rust community seems to be drinking its own Kool-Aid to a significant degree.
Anonymous No.106322851 >>106322999
>>106322760
>>106322771
>>106322779
>>106322801
Read the thread, you incompetent, lying, low-IQ, retarded, moronic idiot. And then off yourself.
Anonymous No.106322896 >>106322935
>>106322817
>Rustacean suspected.
never touched that shit, probably never will
>It would be sad if C and C++ will be the only systems programming languages indefinitely
blame language research, nothing important was created/discovered in the last decades, all these languages are just syntaxical remixes of each other and when you need to get shit done you which you had the frexibility of C anyways.
if C did not exist it would be created nearly 1:1.
>but hopefully they work on them and have success fixing them (so far that is possible), and I personally hope for successor languages to Rust and C++
why? there is no language out there with killing features, rust included.
>Though the Rust community being significantly dishonest makes it harder to create good successor languages.
don't trust 41%ers, they could disappear at any moment.
>And the Rust community seems to be drinking its own Kool-Aid to a significant degree.
if you want a new language use C3 instead, develop the ecosystem.
any successor to C will be C-compatible, no ffi, just c/p C code and it compiles as-is, that's the only required feature for a C successor and why rust, go, etc have already failed before they even started, zig had a chance but it will be in beta forever and it's getting more complex that C++ at this point while still lacking basic features..
Anonymous No.106322935 >>106322956
>>106322896
I still suspect that you are a rustacean, or some other kind of troll.
Anonymous No.106322956 >>106322999 >>106323036 >>106323036
>>106322935
why lmao
I'm a C dev, I write firmware for a living, I have no use for rust and I'm not trolling at all.
don't mix the FOSS world full of trashware with code written so people don't fucking die, most of the C code in the widl is perfectly bug-free.
Anonymous No.106322988
>not running avionics on node.js with an Electron gui
do you even agile development bro? baka
Anonymous No.106322999 >>106323027 >>106323036
>>106322851
>no arguments
>ad hominem
It's very funny to accuse others of lying a d being incompetent while also acting like this lmao.

>>106322956
It should be clear to you that guy is just a cnile schizo. Just look at how he arguments his posts and his aggressive outbursts when you point it out/ask for clarification.
Anonymous No.106323024
>this makes rust trannies piss and shit themselves

#define segfault *(int*)NULL = 0
#define assert(exp) \
{ \
if (!(exp)) { \
fprintf(stderr, \
"%s:%d: assertion failed: (%s)\n", \
__FILE__, __LINE__, #exp); \
segfault; \
} \
} while(0)
Anonymous No.106323027
>>106322999
Cute, this isn't the first time you have trolled and lied repeatedly. Your lack of intelligence does not give you a free pass to lie as you see fit. Cease your trolling and off yourself, retarded, inept, useless, moronic liar.
Anonymous No.106323036 >>106323198
>>106322956
But you already made your trolling clear.

>>106322956
>>106322999
Is this monologuing?
Anonymous No.106323042 >>106323060
Kek
Anonymous No.106323060 >>106323318 >>106323393
>>106323042
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
Anonymous No.106323085 >>106323345 >>106330548
>>106315922
believe it or not but even in low-level embedded C++ offers quite a few benefits you just don't get with C
the type system for one
named casts, templates, constexpr/eval, requires/concepts to name a few more
all while keeping pretty much anything you'd need from C too
the only thing that can be a bit obnoxious is explicitly linking text into specific sections when you do class hierarchies, templates, or lambdas but you never really need to be on a function-by-function level for it anyway since its all just read-only and data can still be strictly protected
i will never understand why retards won't into properly abstracted, decoupled, and portable HAL/MCAL layers that are simply not possible using C unless you write a ton of nightmareish macros
Anonymous No.106323198 >>106323210
>>106323036
>But you already made your trolling clear.
where?
>Is this monologuing?
I don't understand this schizo either lmao
Anonymous No.106323205
>>106315086 (OP)
No python? Brahmin bros...
Anonymous No.106323210 >>106323256
>>106323198
LLM spam?
Anonymous No.106323256 >>106323287
>>106323210
no, I think he misquoted the post, I'm the cnile schizo he is talking about
Anonymous No.106323287
>>106323256
LLM spam.
Anonymous No.106323294
>>106320671
If we ever find out that DHS placed this anon on the saboteur list due to this post, we'll know Rust is a psyop and honeypot
Anonymous No.106323318 >>106323352
>>106323060
That's a lot of links I am not going to click.
Anonymous No.106323345 >>106323373 >>106323672 >>106334699
>>106323085
I like how Rust does HALs.
Using borrow checker to ensure only one thing gets to use a peripheral at the same time is really neat. Also embassy is so much nicer to work with than RTOS.
How does C++ deals with freestanding, heapless environments? I know that C can do this, but aren't random allocations required by some parts of C++ stdlib? I heard that async is pretty unusable without dynamic memory allocations.
Anonymous No.106323352
>>106323318
Anonymous No.106323359 >>106323437
>hey mom, I posted it again
Anonymous No.106323373 >>106323678 >>106333450
>>106323345
https://github.com/embassy-rs/embassy/issues/4367
>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.
Who is at fault?
Anonymous No.106323393
>>106323060
You know what else is unbounded? Marcan's faggotry.
Anonymous No.106323437 >>106323451
>>106323359
Jeremy Bicha.
>SEX BAT BY JUVEN/VCTM UNDER 12; F.S. 794.011(2) (PRINCIPAL - 2 COUNTS)
Rust developer.
PPA for Rust.
https://launchpad.net/~jbicha/+archive/ubuntu/rust
Anonymous No.106323451 >>106323528
>>106323437
>Rust transitions
Kek, truly the tranny language.
Anonymous No.106323528
>>106323451
Mental health, pronouns and alter egos are at the very least trends in Rust. Also as the community Rust Discord server goes.

Hector Martin.
Insisting that Asahi Lina is not his alter ego.

https://aturon.github.io/tech/2019/06/25/back-in-the-saddle/

https://fasterthanli.me/articles/state-of-the-fasterthanlime-2024
https://fasterthanli.me/articles/that-health-is-mental
Anonymous No.106323672 >>106323735
>>106323345
>but aren't random allocations required by some parts of C++ stdlib
sure, and IEC61508 or MISRA C++23 don't explicitly forbid dynamic allocation even in safety critical systems
during runtime its not advised or might be outright forbidden, but you are free to use it at initialization
some stl containers are const or constexpr compliant so you can work around some of those issues if you need to
others like the ranges and views contain methods that dont use dynamic allocation, so some of these are good too
and if you really really must need dynamic allocation you can create your own allocator you can hate when it doesnt work well

no RTOS i know of for micro controllers has good support for C++ threads or even pthreads for that matter
its all just OS-provided threading (Β΅-velOSity, FreeRTOS, SafeRTOS, SYSGO, eSOL)
the overhead for pthreads is not worth it on this level and apparently implementing support for C++ threads is not something RTOS OEMs do
OSes for microprocessors such as Zephyr, Integrity, QNX, et.al. do generally support pthreads, not sure about C++ threads though, these OSes arent my area of expertise

anyway, async behavior or execution policy things in the C++ language arent always supported by the OS
and this is particularly tricky if we look at mutexes and such that OSes generally provide their own construct for
i've grown a habit of wrapping these in lockable-compliant containers and then using the locks from C++
but std::lock contains a deadlock-avoidance algorithm that may call yield on the executing thread

when do you ever have a free-standing, heapless environments? no useful micro controller has so little RAM that you cannot allocate a 4k heap
Anonymous No.106323678 >>106323781 >>106324079 >>106330554
>>106323373
>Who is at fault?
How am I supposed to know? It's an open issue, you can read the discussion yourself, or do you need some explaining?
I never used nRF52840. I am doing embedded development on ESP32 and I did experienced stack overflows with and without RTOS. That's not really an uncommon thing in embedded programming.

And you even the guy I was talking about. What is the point of this post?
Anonymous No.106323735 >>106323790 >>106323895
>>106323672
>when do you ever have a free-standing, heapless environments? no useful micro controller has so little RAM that you cannot allocate a 4k heap
I was just curious about the support.
After I have moved away from RTOS and went bare metal, I did allocated some heap but quickly realized I am literally never using it for anything. All my buffers and stuff are statically allocated and I have no use of dynamic memory at all. I will still need it later on for some stuff, but for now I was really surprised with how everything just werks on no_std without needing any dynamic allocations. Reading your post I got curious how would C++ perform in such scenario since the stdlib seemed dodgy at places.
Is there any mechanism of disabling or generalizing parts of standard library that depend on OS specific features like heap or mutexes? Or do you just write code until it fails to compile because of missing symbols or something?
Anonymous No.106323761
>>106316423
>object oriented which is a necessity in fast iteration
fast iteration is possible when the code is well factored (i.e. you don't have to consider the whole program every time you make a change). this is independent of the paradigm, the linux kernel is massive, not object oriented and moves fast
Anonymous No.106323781 >>106323790 >>106323834
>>106323678
Fuck off ESL.
Anonymous No.106323790
>>106323735
>>106323781
Anonymous No.106323834 >>106324028
>>106323781
What?
Anonymous No.106323895 >>106324073 >>106324469
>>106323735
there are some mechanisms in some compilers to turn off stuff like exceptions or RTTI, but i have never considered turning off dynamic memory
the compiler i use at work supports multiple different C++ libraries such as embedded, extended embedded, dinkum
I think the ETL might be what you're looking for in that case
in the case i mentioned previously with std::lock and the yield function it works because the yield function is a customizable part of the library my compiler offers, so its weakly linked and empty per default
i can override it and make a kernel call to the OS to yield if i want, but i think the overhead of doing so is not worth it

anyway, i forgot to mention in my previous post that the borrow checker, while probably useful, is quite useless when you have two separate binaries on separate CPU cores that share memory/hardware
i don't mean to bash Rust in particular, all languages share this issue
OS mechanisms arent really an option then either since these OSes don't support SMP, or the CPUs don't have cache coherency
its just choosing bad or worse
LDREX and STREX instructions in ARM might be an option (std::atomic_flag), but then you need to be able to tell the OS why you are blocking to allow good scheduling
message units on the MCU will introduce sporadic interrupts that may eventually affect the real-time performance of your system
the semaphore peripheral might not have enough semaphores for everything you need to share...
there's no right choice
Anonymous No.106324028 >>106324072
>>106323834
ESL, leave.
Anonymous No.106324072 >>106324095
>>106324028
stop alluding you're superior because you know only one language
Anonymous No.106324073 >>106324081 >>106324169 >>106324871
>>106323895
i've heard of a company that just "le dds for everything" and they're losing 60% of the CPU to just transfer data
anyway its off topic i guess

a thing i've just recently discovered is called manual virtual dispatch and its a very interesting thing
class task_wrapper_c
{
using task_fn_t = void(void *);

task_fn_t *task_entry_;
task_fn_t *task_init_;
void *const obj_;

friend void task_entry(task_wrapper_c &object) { object.task_entry_(object.obj_); }
friend void task_init(task_wrapper_c &object) { object.task_init_(object.obj_); }

public:
task_wrapper_c() = delete; // Delete the default constructor

template
task_wrapper_c(T &obj)
: task_entry_([](void *object)
{ task_entry(*static_cast(object)); }),
task_init_([](void *object)
{ task_init(*static_cast(object)); }),
obj_(&obj)
{
}
};


it allows complete decoupling of the OS task management and the actual task functionality, at the cost of a pointer size + n*pointer size per function

not sure whether there is a similar thing in Rust
Anonymous No.106324077
where is javascript??
imagine the nice UIs you could make with JS
Anonymous No.106324079 >>106324277
>>106323678
>I did experienced stack overflows with and without RTOS
rust developers, everyone.
Anonymous No.106324081 >>106324141 >>106324169 >>106325022
>>106324073
so this is the task itself, the first one is just a wrapper to generalize all tasks and provide the manual dispatch for "virtuals" (task_entry, task_init)
class task_c
{
using task_fn_t = void(void *);
task_wrapper_c task_wrapper_;
TickType_t period_time_;

static void task_callback(void* args)
{
auto& self = *static_cast(args);

task_init(self.task_wrapper_);
for(;;)
{
task_entry(self.task_wrapper_);
vTaskDelay(self.period_time_);
}
}
public:
task_c(const char *const name,
uint16_t stack_depth,
UBaseType_t priority,
TickType_t deadline,
task_wrapper_c &&object)
: task_name_{name}
, stack_depth_{stack_depth}
, priority_{priority}
, task_handle_{nullptr}
, object_{object, deadline}
{}

void spawn()
{
// How to handle tasks that are not delay-triggered?
// We can release tasks using timers, semaphores, mutex, messages, and event group flags....
xTaskCreate(
task_c::task_callback,
this->task_name_,
this->stack_depth_,
this,
this->priority_,
&this->task_handle_);
}

void kill_task()
{
vTaskDelete(this->task_handle_);
}

TickType_t get_deadline() const
{
return this->object_.period_time_;
}

private:
char const *const task_name_{nullptr};
entry_args_t object_; // No default constructor
uint16_t stack_depth_{};
UBaseType_t priority_{};
TaskHandle_t task_handle_{nullptr};
task_fn_t *task_entry_{nullptr};
};
Anonymous No.106324095
>>106324072
Learn the language you are writing in, ESL, or leave. Unless English really is your first language and you just suck that much.
Anonymous No.106324141 >>106324218
>>106324081
and then just create whatever tasks you need

using thing_s = struct
{
uint32_t data;
};
thing_s thing;

void task_init(thing_s& thing)
{
thing.data = 0u;
}

void task_entry(thing_s& thing)
{
++thing.data;
}

class task_stuff_c
{
public:
void do_something() noexcept { }
};
task_stuff_c second_thing;

void task_init(task_stuff_c& obj) {}
void task_entry(task_stuff_c& obj)
{
obj.do_something();
}


task_c task1{
"Test task",
0x100u,
2u,
20u,
thing};

task_c another_task{
"fuck off",
0x100u,
2u,
20u,
second_thing};

[[noreturn]] void main()
{
std::vector tasks
{
task1,
another_task
};

for(auto& task : tasks)
{
task.spawn();
}

vTaskStartScheduler();

for(;;) {
}
completely decoupled from the classes task_wrapper_c and task_c, and can be tested independently
Anonymous No.106324143 >>106324175
>>106315086 (OP)
F-41 will use Rust
Anonymous No.106324169 >>106324218
>>106324073
>>106324081
This much usage of void pointers is not pretty at all.

Do users of the classes avoid having to use void pointers?
Anonymous No.106324175
>>106324143
Source?
Anonymous No.106324218 >>106324254
>>106324169
out of the two (2) void pointers there is only one (1) void pointer that is not type safe and it is in this function
static void task_callback(void* args)
{
auto& self = *static_cast(args);

task_init(self.task_wrapper_);
for(;;)
{
task_entry(self.task_wrapper_);
vTaskDelay(self.period_time_);
}
}


the other void pointer in class task_wrapper_c can by all metrics be considered type safe

the last post >>106324141 is the "user" of the tasks, no void pointers
Anonymous No.106324254
>>106324218
but anyway, it is a private member of a non-accessible class to the "user", so assuming you are sure of your own ability to cast a void pointer to its actual type, then it could also be type safe

this void pointer is also difficult to remove considering that it is directly related to the (in this case) FreeRTOS interface (void *pvParameters)

BaseType_t xTaskCreate( TaskFunction_t pvTaskCode,
const char * const pcName,
const configSTACK_DEPTH_TYPE uxStackDepth,
void *pvParameters,
UBaseType_t uxPriority,
TaskHandle_t *pxCreatedTask
);


i don't know of any way to mitigate this other than hide the entire OS interface from the user and apply the absolute minimum void pointer operations necessary to handle it internally
Anonymous No.106324269
>>106320255
Actually gcc is fully written in C++, even the C compiler part.
Anonymous No.106324277 >>106324373
>>106324079
Because C/C++ doesn't have stack overflows?
Anonymous No.106324343
but if you absolutely sneed to remove as many void pointers as possible you can opt for virtual functions too

not sure if this is 100% correct, but it should look something like this for the wrapper in that case
a unique_ptr is also possible, but it does dynamic memory allocation so i've opted no not use it

mind you that with increased number of tasks the virtual lookup table grows and you'll sometimes end up spending many microseconds looking up the correct function

class task_wrapper_c
{
struct wrapper_base_s
{
virtual ~wrapper_base_s() = default;
virtual void task_entry() = 0;
virtual void task_init() = 0;
};
template
class wrapper_internal_c : public wrapper_base_s
{
T internal_task_;
public:
wrapper_internal_c(T const& obj) : internal_task_{obj} {}
void task_entry() override { task_entry(internal_task_); }
void task_init() override { task_entry(internal_task_); }
};


wrapper_base_s* const obj_{nullptr};
public:
task_wrapper_c() = delete;
template
task_wrapper_c(T&& task) : obj_{new T(std::forward(task))}
{
}

friend void task_entry(task_wrapper_c& object) { object.obj_->task_entry(); }
friend void task_init(task_wrapper_c& object) { object.obj_->task_init(); }
}
Anonymous No.106324373 >>106324531
>>106324277
maybe (you) should learn to program, no matter what languages you use.
Anonymous No.106324440
>why is multi-decade project mired in the retardation of milshit acquisitions using boomer trash?
gee, I don't know anon. It's almost like we live in a dead society allergic to actually paying up for anything remotely new.
>b-but old good
no, it really isn't. I'm convinced only a jobless neet who just plays video games every day can say any of the foundations of software built on the trash that is C and UNIX are actually good. All we do is slather more makeup on it and it keeps creating more tech debt landmines for some other cuck to step on 10 years later. it's like we live in some kind of manifestation of hell.
Anonymous No.106324469 >>106324503 >>106324559
>>106323895
>the compiler i use at work supports multiple different C++ libraries such as embedded, extended embedded, dinkum
>I think the ETL
Oh I see. So libraries typically need extra support from compiler?
In Rust, even when using esp tool chain, you are expected to have any no_std library working out of the box.

>anyway, i forgot to mention in my previous post that the borrow checker, while probably useful, is quite useless when you have two separate binaries on separate CPU cores that share memory/hardware
>but then you need to be able to tell the OS why you are blocking to allow good scheduling
What do you mean? I just spawn async executor on each core and have stuff working in parallel. I use mutexes(implemented using critical sections) and channels to communicate with each other. Tasks pass around static references and singletons representing access to specific buffer/peripheral and things just work. Drivers set up interrupts and use wakers to resume appropriate tasks even across cores, so CPU can sleep when waiting for IO/timers.
Correct me if I'm wrong, but isn't this the right choice?

Here is how are the CPUs performing under heavy load with explicit yields in the drawing tasks. But if it's not doing anything, the CPU is sleeping nearly all the time.
Anonymous No.106324503 >>106324793 >>106324872
>>106324469
>How does C++ deals with freestanding, heapless environments?
how good is esp32 toolchain for rust? any issues with random crate dependencies? I have an old esp32 laying around. wonder if I should do something with it.
Anonymous No.106324531 >>106324746
>>106324373
uh, are you talking about yourself or something? not everyone has 8MiB stacks on cortex-m CPUs nigga.
Anonymous No.106324557 >>106326613
>>106321385
you are too innocent for this world.
let's use public info only:

* adacore partners with ferrous systems
* adacore ends partnership with ferrous systems
* adacore announces GNAT Pro for Rust

read the announcement from the last one. even with your innocent glasses on you will see that adacore basically wants to funnel all money made in this space to itself.
note that adacore has nothing to do with the rust project itself, nor did it ever contribute, collaborate, or "join forces" with the rust project itself. it just saw a threatening-if-small rust related company entering adacore's "turf", and tried the usual EEE move on it, except just like with M$, the times have moved on, and this can't be done as effectively as before.
they are not too occupied with hiring people with rust expertise either. and they don't need to. because the only "mission" here is to scam bureaucrats, who are incapable of making informed technical-first decisions, of all the money to be made in this bureaucratic space.
Anonymous No.106324559 >>106324793
>>106324469
>Oh I see. So libraries typically need extra support from compiler?
no, you can link external libraries with any compiler, its just that mine has a non-standard compiler flag that lets you choose one thats built in (for maintaining the safety certificate i suppose)

that looks pretty neat, which CPU is that? are those two separate executables?
Anonymous No.106324592
>>106318554
>their shit will be smelled in ~12 hours.
psychic
Anonymous No.106324746 >>106324757 >>106324800
>>106324531
i'm not the one introducing stack overflows left and right, no-coder.
Anonymous No.106324757 >>106324898
>>106324746
>I only ever dealt with environments with near limitless stacks
ya, I know. no one asked you to opine.
Anonymous No.106324762
>>106316941
At least 100 of them.
Anonymous No.106324793 >>106324887
>>106324503
I had no issues so far on Linux, everything just works and documentation(on the no_std variant) is good. After all, Rust has first party support on these chips. My friend had some issues setting up drivers for USB-JTAG on windows though. You might need to downgrade your USB driver.
I just suggest to not even bother with the esp-idf and rtos version, just go bare metal. The abstractions esp-hal provides are arguably more useful and it's focus on DMA is nice. Your binaries will be order of magnitude smaller and you will be able to dive into any abstractions down to registers using your IDE.

>>106324559
Ah makes sense.

>that looks pretty neat, which CPU is that?
Xtensa LX7. It's ESP32-S3

>are those two separate executables?
No. Esp32 gets booted with the main CPU running and other core stopped/reset.
After I initialize serial output and basic stuff, I launch second core by passing a lambda to esp_hal's start_app_core, which sets the appropriate boot address register(IIRC) and launches the second core. On that core I just spawn another executor and spawn whatever tasks I need. There is no task stealing though, all tasks are pinned to specific executor on one of the cores, but they can wake each other cross cores.

Here is the CPU with low load. You can see how does the draw task begins instantly the moment display tasks releases one of the frame buffers through async channel. And when there is nothing to do, the CPU is going into low power mode while waiting for the SPI interrupts or timers to resume operation.
Anonymous No.106324800 >>106324898
>>106324746
I mean, you can't encounter stack overflows if you never program anything. That's true.
Anonymous No.106324871 >>106324887
>>106324073


why define

friend void task_entry(task_wrapper_c &object) { object.task_entry_(object.obj_); }
friend void task_init(task_wrapper_c &object) { object.task_init_(object.obj_); }


instead of like

public:
void task_entry() { task_entry_(obj_); }
void task_init() { task_init_(obj_); }


?

are you avoiding method syntax on purpose?
Anonymous No.106324872
>>106324503
Also if you use JTAG(esp32s3 can do this over USB), probe-rs provides some really neat stuff. I have seen it has harness for running tests on hardware and I think it can even do benchmarks and gdb debugging(dunno how well it works with IDEs).
Working with this is so much nicer than Arduino IDE, but I digress.
Anonymous No.106324887 >>106324972
>>106324793
>Esp32 gets booted with the main CPU running and other core stopped/reset.
>Xtensa LX7. It's ESP32-S3
ah then you have SMP and its a non-issue because you can compile one binary for all the available cores and have multi-core scheduling and stuff like that
maybe there are ways to work around the issue in AMP mode, i'm not sure but for what its worth the OS i work with (Β΅-velOSity) executes on only one CPU core, so the software for each CPU is compiled and linked independently
this is very obnoxious in some sense and maybe there are ways around it

>>106324871
because the friends are injected into the surrounding namespace and basically end up as global functions that access the internal members of the class
if you had member functions you would introduce a dependency between your task code and the OS task wrapper
with the hidden friend you dont do that
the only place you would include the OS task wrapper would be in e.g. main.cpp where you create the task objects. the task code itself you can have floating wherever
Anonymous No.106324898
>>106324757
>>106324800
lol, last i professionally worked with embedded systems, i never once introduced stack overflows as i remember, and one stack size was less than 1kb. Lmao learn2code no-coders.
Anonymous No.106324919 >>106326632
>>106321931
He didn't mention stack. Borrow checker is orthogonal to stack too
Anonymous No.106324937
>>106315086 (OP)
Because anything delivered with a warranty is written in proving systems like COQ, or just straight paper proofs, and then transliterated to its target language. If you depend on the language safety features to catch your fuckups you probably work for Boeing.
Anonymous No.106324956
>>106315219
Because C is perfectly safe, unless you are a retard that can't write simple code. There is nothing "unsafe" about C. You are only retarded.
Anonymous No.106324972
>>106324887
Well, there is no mutli core scheduling here though. Similarly to your case, I spawn separate executor on each core, each having its own tasks to run. Executors are like these RTOS, but because I initialize them instead of using them to boot my code, I can have one codebase that sets up the cores and then initializes the executors. This makes it easier to initialize shared memory.
On first, both cores can only share data using static atomics and thread-safe mutexes(and structures using them like channels). Thread safety is enforced using Rust's Sync/Send traits.
But yeah, if you are not responsible for setting up cores and rely on some single threaded OS to boot your code, I can imagine why sharing might be tricky to set up.
Anonymous No.106325022 >>106325103
>>106324081

why is task_entry_ private? Is it the whole class?

private:
task_fn_t *task_entry_{nullptr};
Anonymous No.106325103 >>106325212
>>106325022
no, its a lambda function that deduces the appropriate global function to call for the given task
pic related is a simpler example
Anonymous No.106325212 >>106325274
>>106325103
if i understand you correctly, what i was referring to was the field task_entry_ in class task_c, not in class task_wrapper_c.
Anonymous No.106325274 >>106325377
>>106325212
aha sorry
that is something of a typo
had it as a lambda but it was obtuse so i made it into the private static member function
its the entry point forwarded to FreeRTOS, or whats actually being scheduled by the OS
Anonymous No.106325377 >>106325446
>>106325274
but is it used anywhere? Or is it unused?
Anonymous No.106325446 >>106325503
>>106325377
the pointer is unused and can be removed
Anonymous No.106325503 >>106325721
>>106325446
okay

shouldn't the compiler have warned about a private unused field? Do you have all warnings enabled?
Anonymous No.106325627 >>106325635 >>106325698
>>106315219
*((*(++i))++) is actually very good if youre trying to impress employer

his especially if their firm run on i--
Anonymous No.106325635
>>106325627
At least two of those parathesis are not needed.
Anonymous No.106325698 >>106325738
>>106325627
learn2code
https://stackoverflow.com/questions/949433/why-are-these-constructs-using-pre-and-post-increment-undefined-behavior
Anonymous No.106325721 >>106325738 >>106325860
>>106325503
yes anon but its a post on 4chan not a code review
i didnt compile it
Anonymous No.106325738
>>106325721
isn't it your code?

>>106325698
oh wait, maybe it's not ub, but i'd never let it fly.
Anonymous No.106325860
>>106325721
Anonymous No.106326613 >>106327340
>>106324557
That does not cover this:

>while running anti-rust campaigns.

And they claim to add value to Rust:

https://www.militarysystems-tech.com/articles/adacore-announces-gnat-pro-rust

https://www.adacore.com/gnatpro-rust

>When GNAT Pro for Rust 25 launches officially, it will offer full integration with gprbuild and will provide advanced Ada-Rust bidirectional bindings - all while supporting more platforms.

They seem way more aligned with Rust than against Rust, and could well be aligned against C++ still. So that >>106321385 is the case.
Anonymous No.106326632 >>106327003
>>106324919
Off yourself, incompetent, lying retard.
Anonymous No.106327003 >>106327185
>>106326632
Why are you getting so emotional?
Anonymous No.106327089
>>106315086 (OP)
F-35? as in the Jet?
Anonymous No.106327185 >>106328064
>>106327003
Emotional? My posts are entirely reasonable considering your repeated and persistent lies and trolling, you incompetent, delusional, worthless pretender. Now off yourself.
Anonymous No.106327340 >>106327526
>>106326613
you fucking retard. the title of of Adacore's homepage is literally:

"Commercial software solutions for Ada, C and C++ | AdaCore"

There would be no point in pointing you to sponsored "papers", let alone leaking some behind-the-scenes chatter to you if you can't even bother to read website homepage title.

their shtick is not "Rust good, C++ bad". their shtick is "you must use us and pay us for certification/qualification. no matter what language you use: C, C++, Ada, or even Rust".

on the Rust question, the talking point is/was "yeah, Rust is good. we like it. but SPARK is best". they might put Rust front and center in the future if they successfully an fully EEE certified/qualified Rust and become a de facto monopoly in this space. but that's going to be tough considering the worldwide investment and interest in Rust, from chinks, to the EU, to everywhere else. So current strategy will continue.
it doesn't take a genius to figure out why they are doing this. or how little objective technical reasoning matters in this context.
Anonymous No.106327526 >>106327746
>>106327340
Nice try, you fucking useless, lying, moronic retard. Why are 4 out of the 7 most recent press releases on Adacore about Rust? Off yourself.
Anonymous No.106327746 >>106327946
>>106327526
do you know what EEE means?
Anonymous No.106327946 >>106328535
>>106327746
Troll, your lies are too obvious. Off yourself.
Anonymous No.106328004
>>106315086 (OP)
>where is Rust?

Because there is ADA there, and whenever Ada developers are working, Rustaceans must shut their effing mouth and watch Real Programmers do Real safe software.
Anonymous No.106328022 >>106328303
>>106322671
>i have no fucking clue what Ada is, and I think C + valgrind (or other tool) = Ada

kek
Anonymous No.106328046
>>106316445
>almost everything is build on top of C and C++ including other languages

hi pajeet:

- fortran compilers, written in fortran
- lisp compilers, written in lisp
- ocaml compilers, written in ocaml

- even tranny langs like rust are self-hosted by now

>python is made in C

I'm talking real programming languages, not toy stuff
Anonymous No.106328064 >>106328102
>>106327185
Buddy, this is my second post. I'm the guy who told you borrow checker is orthogonal to stack. Because it is. And to heap too. It works with zero-sized types, so you can express meaningful borrow checker semantics without involving the stack at all. Stop being hysteric, woman
Anonymous No.106328065 >>106334836
>>106318035
>Seems like it's ripe for a rewrite in Rust.

and a sex change operation for all the development team, plus hormone replacement therapy
Anonymous No.106328083
>>106320254
>i have no clue what funcional programming is
Anonymous No.106328095 >>106328222
>>106320404
>The borrow checker is a method of doing automatic memory management

kek

"automatic memory management"
Anonymous No.106328102
>>106328064
Not even a good attempt, you demented, deceitful, inept retard. Now off yourself.
Anonymous No.106328117
>>106321421
>Unsafe Rust is more difficult to reason about than C, and that issue is made infinitely worse by the Rust Foundation lying repeatedly through their teeth about that topic and officially according to their website paying people to evangelize their language instead of fixing the issues in Rust.

Based chad.
Anonymous No.106328222 >>106328247 >>106328259 >>106329482 >>106332067
>>106328095
Borrow checking is 100% relevant for and a part of general overall memory management in Rust. The checker checks statically, and some types check dynamically.


RefCell

thread 'tests::it_sends_an_over_75_percent_warning_message' panicked at src/lib.rs:60:53:
already borrowed: BorrowMutError
Anonymous No.106328247 >>106328331 >>106328410
>>106328222
>and a part of general overall memory management in Rust.

Yeah,

And it is NOT " a method of doing automatic memory management", you rustrannie.
Anonymous No.106328259 >>106328331 >>106328410
>>106328222
>The checker checks statically, and some types check dynamically

lol confusing type checks with allocation checks
Anonymous No.106328303
>>106328022
fucking moron, I've written ada/spark for a decade before, I know very fucking well what it is, you're just misunderstanding my post on purpose because you're a troon.
writting perfectly safe C is possible with things like frama-c and the trillions of other solutions available for C and no others languages.
just use simulink if you're too retarded for hand-written C
Anonymous No.106328331
>>106328247
>And it is NOT " a method of doing automatic memory management", you rustrannie.
Never claimed that, but RAII is integral to Rust, and borrow checking is deeply intertwined with that, at least if a holistic perspective is taken instead of a more specific mechanical view with more narrow definitions. And in this context, I do not see how it would make sense to use those more narrow definitions, rustrannie.

>>106328259
Are you a complete moron? Did you not read the panic message? That message is not compile-time, but runtime.
Anonymous No.106328410
>>106328247
>>106328259

>>106322063
Anonymous No.106328425
>>106322063
>mamagement
should be management.
Anonymous No.106328535 >>106332051
>>106327946
>he doesn't know what EEE means
sorry. i didn't expect you to be at the same wave length as mine. but i didn't realize the gap was that big.
Anonymous No.106328571 >>106328655
>Adacore doing paid PR in 4jeet of all places
They can't possibly feel THAT threatened, right?
In any case, they should buy an ad.
Anonymous No.106328655 >>106329303
>>106328571
Threatened by who though
Anonymous No.106329303
>>106328655
threatened by Ada/SPARK joining the deprecated list like C++
Anonymous No.106329459 >>106332067 >>106332078
>>106322063
Managed language is a language that requires runtime.
RAII does not make a language managed as long as it can run on bare metal.
Anonymous No.106329463 >>106329601 >>106333548
>>106315086 (OP)
>This left the pilot unable to abort its landing sequence as it stopped responding and sharply banked to the left.
https://militarywatchmagazine.com/article/software-glitch-f35-crash-danger

this is your safety of C
Anonymous No.106329470
Just don't write buggy code then it's safe.
Anonymous No.106329482 >>106332094 >>106332127
>>106328222
Interior mutability is not a form of memory management. It does not allocate or deallocate anything.
Anonymous No.106329601
>>106329463
no used tech should be blamed for SunkCost-35's faults.
>>106315825
Anonymous No.106330548
>>106323085
>i will never understand why retards won't into properly abstracted, decoupled, and portable HAL/MCAL layers that are simply not possible using C unless you write a ton of nightmareish macros
It isn't because C programmers can't write HALs or MCALs, without creating huge macros, but it's because we don't want to write one where it can be easily bloated by some fucking jeet or some dumb faggot who wants to add a million features. Why have it at all if someone is just going to fuck it up and try to shove that shit upstream?
Anonymous No.106330554
>>106323678
>embedded development on ESP32
lel more like ESL32. Shut your brown faggot ass up.
Anonymous No.106332051 >>106332271
>>106328535
Embrace, extend, extinguish, yet your lies are clear as day. Off yourself, retarded troll.
Anonymous No.106332067 >>106332078 >>106334354
>>106329459
And what would reference counting, count as? Some consider reference counting to be a type of garbage collection. Rust has Rc and Arc, and RefCell implies runtime checks considering the panic of >>106328222 .
Anonymous No.106332078 >>106334354
>>106329459
>>106332067
And why do you write RAII, when that does not occur in the post you referred to?
Anonymous No.106332094 >>106332127 >>106334354
>>106329482
Yet for RefCell, time is spent at runtime on checks that may cause panics.
Anonymous No.106332127 >>106334354
>>106329482
>>106332094
And rustaceans discuss the runtime costs of RefCell and Rc.
https://www.reddit.com/r/rust/comments/jkh99u/how_heavy_is_rcrefcellt/
Anonymous No.106332271 >>106332320
>>106332051
Your emotional responses tell of someone worried about losing their employment.
Anonymous No.106332320
>>106332271
Is this projection? Off yourself, you retarded, low-IQ, nitwit, inept, worthless, lying troll.
Anonymous No.106333414
>>106315086 (OP)
what the FUCK is going on with the numbers in this pie chart?
Anonymous No.106333450
>>106323373
>as little as 10-12KiB of stack
Anonymous No.106333548 >>106334100
>>106329463
You can't blame a language for your algorithms making retarded decisions

also
>touchscreen hard to use in flight
breathtaking retardation by the jeets making the decisions. Imagine not realising that the shit you make on the ground might not work as smoothly while doing a 7G loop-de-loop.

Idk why some retards want to blame languages for everything, as if their could be a language that prevents you from making stupid decisions.
Anonymous No.106334100 >>106334844
>>106333548
C/C++/Rust shill
>if you write unsafe C/C++/Rust you are mentally challenged
$LANG shill
>the plane must be safe because $LANG is memory safe
Anonymous No.106334354 >>106334527 >>106335087
>>106332067
Reference counting is usually a form of RAII.
It does not make a language managed because it does not require a runtime.

>>106332078
Because you mentioned Arc which is a shared smart pointer implemented using RAII.

>>106332094
That doesn't make it a form of memory management.
It does not allocate or deallocate anything therefore it is not a form of memory management.

>>106332127
>linking random reddit posts
How about you go back there.
Anonymous No.106334527 >>106334590
>>106334354
You're basically adding a shitty version of garbage collection when you use RC. It cannot mange your allocations by magic. There is a program or additional code injected into your program that is performing the same role as a run-time's GC (and it's slower than something like Java's or Go's GC). You can cope with semantics all you want but you're telling Rust to manage memory for you as soon as you reach for that.
Anonymous No.106334590 >>106334618
>>106334527
That doesn't make it managed language.
It doesn't require runtime therefore it is not a managed language.
Anonymous No.106334618 >>106334770
>>106334590
Explain how it does garbage collection without a program tracking allocations.
Anonymous No.106334699
>>106323345
It's less defined than C's freestanding rules, but you can override malloc, etc. Just don't use std in freestanding C++ and you should be fine. You barely have any libc functionality anyway when writing freestanding C code.
Anonymous No.106334770 >>106334807 >>106336876
>>106334618
I never claimed so.
I only said that RAII doesn't make a managed language.
It can run on bare metal therefore it is not a managed language.
Anonymous No.106334807 >>106334974
>>106334770
You can run a garbage collector on bare metal if you pack into the binary of your program which is what Go does. It's still a form of runtime memory management.
Anonymous No.106334836
>>106328065
they're way ahead of you buddy
Anonymous No.106334844 >>106334856
>>106334100
modern sepples is reinventing java, poorly
Anonymous No.106334856
>>106334844
misquote
Anonymous No.106334974 >>106335016 >>106336888
>>106334807
Go requires a runtime to run therefore it is a managed language. It can't run on bare metal.

That doesn't mean it can't run on an embedded system. For example, in my embedded project, I run Rust on bare metal with Lua embedded on top. Rust runs on bare metal without any runtime, but it does implement a garbage collector and a runtime for Lua to run on. And here the difference is clear. Rust code is freestanding, the firmware bootloader can jump directly into it without having to initialize anything beyond hardware. Lua on the other hand needs that Rust runtime to initialize garbage collector, create global tables and manage its memory. A bootloader can't just jump into Lua code without initializing that runtime.
Anonymous No.106335016
>>106334974
https://github.com/usbarmory/tamago
Anonymous No.106335087 >>106335119 >>106336734
>>106334354
Reference counting, regardless of how it is implemented, is by many considered a kind of garbage collection, and it tends to have overhead.
https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Reference_counting

>Because you mentioned Arc which is a shared smart pointer implemented using RAII.
Off yourself, you demented troll. Arc literally is an acronym of Atomically Reference Counted. And RAII is not its only aspect, and while it is implemented usint RAII, it is a smart pointer providing reference counting, which many consider a kind of garbage collection, and which generally has overhead.

And read >>106322063 .

Are you too stupid to figure out how to off yourself, troll?
Anonymous No.106335119 >>106335852 >>106336920
>>106335087
>Reference counting, regardless of how it is implemented, is by many considered a kind of garbage collection, and it tends to have overhead.
I never claimed otherwise. I only said that a language that requires runtime is a managed language and a language that can run on bare metal is not a managed language.

>Off yourself, you demented troll. Arc literally is an acronym of Atomically Reference Counted. And RAII is not its only aspect, and while it is implemented usint RAII, it is a smart pointer providing reference counting,
I never claimed otherwise.

>And read >>106322063 .
Managed language is a language that requires runtime.
RAII does not make a language managed as long as it can run on bare metal.
Anonymous No.106335852 >>106336556
>>106335119
Are you genuinely too stupid to even pretend to debate? Is this LLM spam? Off yourself, you dimwitted moron.
Anonymous No.106336556 >>106337230
>>106335852
Not an argument
Anonymous No.106336734 >>106337220
>>106335087
It means automatic reference counting
Anonymous No.106336876
>>106334770
>It can run on bare metal therefore it is not a managed language.

lol these things are orthogonal

why people are so ignorant?
Anonymous No.106336888 >>106337064
>>106334974
>Go requires a runtime to run therefore it is a managed language. It can't run on bare metal.
>That doesn't mean it can't run on an embedded system.

You should enroll into an university into a CS degree and only comment afterwards.
Anonymous No.106336894
they all lead to 30 dollars an hour
Anonymous No.106336920
>>106335119
>and a language that can run on bare metal is not a managed language.

Seriously, seriously

Where did you get your education from? Youtube videos?
Anonymous No.106337064
>>106336888
No, you should, because you don't kniw the definition of embedded (hint: it's not a synonym for shit, weak or low-cost)
Anonymous No.106337220
Do you get paid by the (You), troll? Off yourself.

>>106336734
Not even putting effort into trolling.
Anonymous No.106337230
>>106336556
Off yourself, troll.
Anonymous No.106337324
>>106316649
Java does the out of bounds checks for you, why do it yourself? :^)