This voluntary guidance provides an overview of product security bad practices that are deemed exceptionally risky, particularly for software manufacturers who produce software used in service of critical infrastructure or national critical functions (NCFs).
I am mostly joking but rust is quite annoying and is only useful in very specific circumstances. I’m not against encouraging people to use better designed languages than C though
I’m not sure if you’re making a real point or if it’s something you heard is complicated but never looked into why. You almost never actually write a linked list. There are usually way easier ways to have a potentially infinite list, but more often you will write your code to operate on blocks of arrays of known size for performance reasons (cache locality, etc) or safety reasons (memory exhaustion, etc), or the linked list is hidden away in a queue implementation (which again you usually want to make bounded).
Most C++ programmers don’t actually understand lifetimes or even basic memory safety.
Most programmers don’t know when they should be using a linked list or something more cache-friendly.
Most software is really bad.
If I can get away with it, I’ll bang something out in Python or whatever I’m required to do something in for the task at hand, and I’ll absolutely know 10 ways my program can break, but if I need speed AND reliability, it necessarily takes effort from me, the programmer, to tell the computer exactly how it has to go down. And then Rust usually lets me say what I want to say.
I interpreted your comment as being dismissive of understanding basic memory safety because no jobs care about this.
I thought it ridiculous that people don’t care that their programs explode. I guess it changes your mindset when your service going down isn’t a matter of costing the company money, but affecting real people.
Just because you can, doesn’t mean you should. For application code, it’s almost always better to use a language with garbage collection, in order to get memory safety without undue ceremony. Yes, some gc-ed languages are slow (Python, Ruby), but others are quite fast (JVM, .NET, Common Lisp, Haskell).
If you’re looking to write the types of server daemons often written in C, Go is another good choice. It’s very C-like in its syntax. It has a lot of the same safety features Rust has but isn’t nearly as complex to learn. It also has a huge standard library, so you rarely need to rely on third-party code.
Go isn’t too suitable for drivers or kernels or other kinds of system software though. Rust is definitely a better choice for those.
I hope you’re joking. This mindset has had terrible consequences, such macho bullshit needs to go.
The Zionazis will find your mistakes before you do. So have the computer check your work as much as possible.
I am mostly joking but rust is quite annoying and is only useful in very specific circumstances. I’m not against encouraging people to use better designed languages than C though
skill issue
huh? about the only place I can’t use rust is on microcontrollers, and it’s kind of a pain in the dick on mobile (just use kotlin lol)
Most rust programmers don’t know how to implement a linked list
I’m not sure if you’re making a real point or if it’s something you heard is complicated but never looked into why. You almost never actually write a linked list. There are usually way easier ways to have a potentially infinite list, but more often you will write your code to operate on blocks of arrays of known size for performance reasons (cache locality, etc) or safety reasons (memory exhaustion, etc), or the linked list is hidden away in a queue implementation (which again you usually want to make bounded).
Most C++ programmers don’t actually understand lifetimes or even basic memory safety.
Most programmers don’t know when they should be using a linked list or something more cache-friendly.
Most software is really bad.
If I can get away with it, I’ll bang something out in Python or whatever I’m required to do something in for the task at hand, and I’ll absolutely know 10 ways my program can break, but if I need speed AND reliability, it necessarily takes effort from me, the programmer, to tell the computer exactly how it has to go down. And then Rust usually lets me say what I want to say.
Fingers crossed I get this job I’m applying for where they actually care about this.
oh okay you’re actually stupid
wow
I am blown away that even in a socialist space people like you are obsessed with employment, and not with whether your program actually functions.
excuse me?
I interpreted your comment as being dismissive of understanding basic memory safety because no jobs care about this.
I thought it ridiculous that people don’t care that their programs explode. I guess it changes your mindset when your service going down isn’t a matter of costing the company money, but affecting real people.
But maybe you weren’t being sarcastic?
Just because you can, doesn’t mean you should. For application code, it’s almost always better to use a language with garbage collection, in order to get memory safety without undue ceremony. Yes, some gc-ed languages are slow (Python, Ruby), but others are quite fast (JVM, .NET, Common Lisp, Haskell).
If you’re looking to write the types of server daemons often written in C, Go is another good choice. It’s very C-like in its syntax. It has a lot of the same safety features Rust has but isn’t nearly as complex to learn. It also has a huge standard library, so you rarely need to rely on third-party code.
Go isn’t too suitable for drivers or kernels or other kinds of system software though. Rust is definitely a better choice for those.
Yeah I’ve been using Go a lot lately. It’s pretty good