Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities [email protected]
Depends on if you're coding for critical infrastructure (i.e. - electrical grid), or writing a high performance video game that can run on older hardware.
We should absolutely have specific licenses like Civil Engineers do for computer infrastructure that is required for any software written for specific purposes. It would be a nightmare to implement, but at some point, it's going to be needed.
writing a high performance video game that can run on older hardware
Unless it's some really exotic platform, I'd honestly still say no. Rust has shown that memory safety and performance doesn't have to be a tradeoff. You can have both.
But sure, if whatever you're targeting doesn't have a Rust compiler, then of course you have no choice. But those are extremely rare cases these days I'd say.
There's always a trade-off. In rust's case, it's slow compile times and comparatively slower prototyping. I still make games in rust, but pretending there's no trade-off involved is wishful thinking
They mean a trade off in the resulting application. Compile times mean nothing to the end user.
That may be true but if the language is tough to develop with, then those users won't get a product made with that language, they'll get a product made with whatever language is easier / more expedient for the developer. Developer time is money, after all.
let me feel sort of creative in the way I do things
🚩
I'm just glad to see the White House listening to people who understand technology for a change.
We need legislators who aren't all literally older than cryptography. If they weren't bought and paid for by billionaires that would be nice too.
they don’t feel like your fighting the language
I really understand what you mean wrt Rust. I really do - I was there once. But it's a phase you grow out of. Not just that - the parts you fight now will eventually become your ally.
and let me feel sort of creative in the way I do things
I had the same experience with C/C++. But as the design grows, you start hitting memory-safety bugs that are difficult to avoid while coding - even after you learn how those bugs arise in the first place. Just a lapse of concentration is enough to introduce such a bug (leaks, use-after-free, deadlocks, races, etc). I've heard that C++ got a bit better after the introduction of smart pointers and other safety features. But, it comes nowhere near the peace of mind you get with garbage collected languages.
That's where Rust's borrow checker and other safety measures kick in. The friction disappears when you acquire system knowledge - concepts of stack, heap, data segment, aliasing, ownership, mutation, etc. These knowledge are essential for C/C++ too. But the difference here is that Rust will actually tell you if you made a mistake. You don't get that with C/C++. The ultimate result is that when a Rust program compiles successfully, it almost always works as you expect it to (barring logical errors). You spend significantly less time debugging or worrying about your program misbehaving at runtime.
The 'friction' in Rust also helps in another way. Sometimes, you genuinely need to find a way out when the compiler complains. That happens when the language is too restrictive and incapable of doing what you need. You use things like unsafe, Rc and Refcell for that. However, most of the time, you can work around the problem that the compiler is indicating. In my experience, such 'workarounds' are actually redesigns or refactors that improve the structure of your code. I find myself designing the code best when I'm using Rust.
Leaders in Industry Support White House Call to Address Root Cause of Many of the Worst Cyber Attacks
And it's called C/C++. It's gotten so bad that even the friggin' white house has to make a press release about it. Think about it, the place where that majority barely even understand the difference between a file browser and a web browser is telling you to stop using C/C++. Hell, even the creator and maintainers of the language don't know how to make it memory safe. If that isn't a wake up call, then nothing ever will be.
And this isn't the first call! The IEEE also says more clearly: GTFO C/C++.
If you want memory-safe, don't write C/C++. Trying to get that shit memory-safe is a hassle and a half. You're better off learning a language that isn't full of foot-guns, gotchas, and undefined behavior.
~~If you want memory-safe,~~ don’t write C/C++.
Fixed that for you. There's no situation where you want buffer overruns.
There's no situation where you want buffer overruns.
I want buffer overruns in my game consoles for jailbreaking purposes lmfaoooooo
You’re better off learning a language that isn’t full of foot-guns, gotchas, and undefined behavior.
As a JS developer, seeing this quote about C/C++ for a change gives me unbelievable levels of schadenfreude
What memory-safe systems programming languages are out there, besides Rust?
Zig is better than C, but still a far stretch from the memory safety of Rust: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
Languages with GC
I appreciate your answer, but I mentioned systems programming, because I was more interested in languages that do not rely on a garbage collector.
To play devil's advocate, most systems programming can be done even with a garbage collector. Midori was a project to build an operating system on a variant of C#, and although the garbage collector did impose technical difficulties, it wasn't a dealbreaker. Go isn't usable everywhere Rust is, but it can in fact be used for many things that previously would have been considered "systems" niches (which is part of why there was a somewhat prevalent misconception in the early days of Rust that they were similar languages). Prominent D developers have defended D's garbage collector (even though it's technically optional). Bjarne Stroustrup, the creator of C++, used to express great confidence that C++ would one day have a garbage collector.
...but you're right, Rust and its rise in popularity (and, conversely, the C++ community's resistance to adopt anything with garbage collection) have definitely narrowed the common definition of "systems programming" to exclude anything with a "thick" runtime.
Rust does memory-safety in the most manual way possible, by requiring the programmer prove to the compiler that the code is memory-safe. This allows memory-safety with no runtime overhead, but makes the language comparatively difficult to learn and use.
Garbage-collected compiled languages — including Java, Go, Kotlin, Haskell, or Common Lisp — can provide memory-safety while putting the extra work on the runtime rather than on the programmer. This can impose a small performance penalty but typically makes for a language that's much easier on the programmer.
And, of course, in many cases the raw performance of a native-code compiled language is not necessary, and a bytecode interpreter like Python is just fine.
Rust does memory-safety in the most manual way possible
The most manual way is what C does, which is requiring the programmer to check memory safety by themselves.😛
Also will say that outside of some corner cases, Rust is really not that harder than Java or Python. Even in the relatively rare cases that you run into lifetimes, you can usually clone your data (not ideal for performance usually but hey its what the GC language would often do anyway). And reliability is far better in Rust as well so you save a lot of time debugging. Compiles = it works most of the time.
C# dev with reasonable experience with java, python, and rust:
Rust is harder
The most manual way is what C does, which is requiring the programmer to check memory safety by themselves.😛
The difference is, Rust will throw a tantrum if you do things in an unsafe way. C/C++ won't even check. It'll just chug along.
Rust is really not that harder than Java or Python.
As someone who's done all three, the fuck it isn't.
If you are familiar with C/C++ best practices to any operational level, those things will translate over to Rust quite nicely. If not, that learning curve is going to be fucking ridiculous with all the new concepts you have to juggle that you just don't with either Java or Python.
I like Rust a lot, philosophically and functionally... but it is WAY harder. Undeniably very hard.
Just try and do anything with, say, a linked list. It's mind-boggling how hard it is to make basic things work without just cloning tons of values, using obnoxious patterns like .as_mut(), or having incredibly careful and deliberate patterns of take-ing values, Not to mention the endless use of shit like Boxes that just generates frustrating boilerplate.
I still think it's a good language and valuable to learn/use, and it's incredibly easy to create performant applications in it once you mastered the basics, but christ.
Software engineer for almost two decades at this point, programming off and on since a kid in the late '80s: Rust is harder. It did seem to get better between versions and maybe it's easier now, but definitely harder than a lot of what I've worked in (which ranges Perl, PHP, C, C++, C#, Java, Groovy/Grails, Rust, js, typescript, various flavors of BASIC, and Go (and probably more I'm forgetting now but didn't work with much; I'm excluding bash/batch, DB stored procedures (though I worked on a billing system written almost entirely in them), etc.)
That said, I don't think it's a bad thing and of course working in something makes you faster at it, but I do think it's harder, especially when first learning about (and fighting with) the borrow checker, dealing with lifetimes, etc.
The availability of libraries, frameworks, tools, and documentation can also have a big impact on how long it takes to make something.
A better approach is the one Apple uses with Swift (and before that, Objective-C... though that wasn't memory safe).
In swift the compiler writes virtually all of your memory management code for you, and you can write a bit of code (or annotate things) for rare edge cases where you need memory management to do something other than the default behaviour.
There's no garbage collection, but 99.999% of your code looks exactly like a garbage collected language. And there's no performance penalty either... in fact it tends to be faster because compiler engineers are better at memory management than run of the mill coders.
I'm no Rust expert, but in what I have done with it I've always found it reassuring to know the compiler has my back, and I haven't found the rules too onerous. In some ways I prefer this to counting on some black-box garbage collector with unpredictable performance costs, and I certainly prefer catching as many errors as possible at compile time not runtime.
So that's why I've been hearing non-stop crab rave music!
The interpreter or compiler could also introduce memory issues into the code. Much less likely to happen, but it is not unknown.
