121–130 of 342 posts
Maybe C programmers need some more thoughts and prayers at deployment time?
I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…
I would love to be able to use Rust in my professional project. Unfortunately, I am doing high performance scientific computing. Rust doesn't even come close to offer any good alternative to cross-plateform, cross-device (CPU/GPU) libraries such as OpenMP Target, Kokkos, SYCL, ... I believe we need Nvidia/AMD to take Rust seriously (I'm not sure it is even possible without unsafe everywhere) to be able to offer good…
My broader point was that C/C++ are still kings in some areas but people insist on using them where a bunch of languages do better today.
Earlier quoted context omitted.
There is a difference between praising and preaching, the latter happens more often with rust
If you say so. ¯\_(ツ)_/¯ But even if it was true (I'd contest it's not) can't you ignore it and judge the language on its merits? We are not teenagers for a long, long time now, we should be making up our own mind about things.
But you denied my right to make up my own mind about Rust based on what its proponents say.
I believe you even attempted to insult me, too bad I don't know what curmudgeon means :)
Earlier quoted context omitted.
Simplicity.
This isn't a crazy thought to have about K&R C. They're trying to fit a high level language onto a 1970s computer and so sacrifices must be made. Some of the trades they make are... questionable and others I'd say clearly wrong (they just don't need Tony's billion dollar mistake, nor to be so cavalier with types in general), but it's not as though they're targeting a machine with gigabytes of RAM and a multi-core CPU…
This makes simple application code slightly faster. That's kind of a reasonable domain for C++ but on dubious ground for C. Where C is superb is talking to hardware and language implementation, exactly the areas the ISO group has chosen to cripple the language for.
Thankfully compilers know about this and provide fno-strict-aliasing et al. Maybe there should be a std= style flag to change to the language subset that doesn't actively try to miscompile your program chasing benchmark numbers.
Earlier quoted context omitted.
Eh, Rust would be fine if not for the fact that it's too opinionated. Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times
So a few things .. Rust is a very good safe language. It also has an unsafe keyword to make the compiler ignore borrows etc. If you want fast iteration, use python and then hand transpile your code into rust. Not every tool has to be used at once ... but Python for the idea and rust for the implementation can be the best of both worlds ... :)
And while you can technically prototype in a other language, speed of iteration is always a bottleneck.
The only way to escape it is if You are an about master of language, the project you are working on and even the feature you are adding.
But that's a verry rare case scenario
Earlier quoted context omitted.
There is a difference between praising and preaching, the latter happens more often with rust
Before the current "AI" hysteria, HN was full of "I've rewritten this thing that was working just fine in Rust". No mention of how it's better, has more features - or even has all the original's features - or anything about why you should use the rewrite instead of the original. Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me?
No embarrassing buffer overflow CVEs is a very good start.
To me that's an actual selling point and I've migrated from almost all UNIX coreutils to Rust alternatives for that reason alone.
> Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me?
No, as an adult you are supposed to not frame the discussion unfairly and ask the right questions.
Earlier quoted context omitted.
They're being satirical. People usually berate my posts because I have cartoon characters for Socratic exchanges to teach people things like Kubernetes, claiming that is "unprofessional" or something. These people are sarcastically berating my post for NOT using that Socratic system.
It's gross because I don't want to think about your sex life when at work, but I guess this type of exhibitionism is fine.
Earlier quoted context omitted.
If you say so. ¯\_(ツ)_/¯ But even if it was true (I'd contest it's not) can't you ignore it and judge the language on its merits? We are not teenagers for a long, long time now, we should be making up our own mind about things.
> we should be making up our own mind about things But you denied my right to make up my own mind about Rust based on what its proponents say. I believe you even attempted to insult me, too bad I don't know what curmudgeon means :)
I have not denied you anything, I implored you to ignore the zealots that exist IN EVERY ECOSYSTEM and judge the thing based on what it can actually do.
Please don't misrepresent what I said, that's not arguing in good faith.
Earlier quoted context omitted.
> only the baggage a project needs What projects need manual memory management? Those where the hardware costs are comparable to development/maintenance costs. That is much rarer than people think. RAM is cheap, and few applications really need bespoke allocation. And it's not just a question of skill; even the most disciplined make mistakes. It's one of how much brainpower you want to allocate to... memory allocatio…
>What projects need manual memory management Games. Big/specialiased games to be precise, as for smaller projects managed language offer good enough performance.
High end games programming sometimes knocks the love of malloc()/free() (and naive RAII) out of them.