191–200 of 272 posts
Earlier quoted context omitted.
Great then let's prove that ASM is correct. the reference C code is just as bad.
Which is actually possible, unfortunately the industry never cared that much about strong typed assembly. See Verve OS from Microsoft Research, TAL and the origins of the Dafny language.
Earlier quoted context omitted.
That's really just not true. Easy counterexample: any codec should be written in a memory safe language. Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.
In fact codecs in particular should be written in something much stricter but more special purpose than Rust, WUFFS (Wrangling Untrusted File Formats Safely) https://github.com/google/wuffs WUFFS gives up generality - you can't write "Hello World" in WUFFS because it lacks both strings (for the "Hello, world" text) and I/O (for the printing it out). But you can write a codec, going from a block of bytes representing…
Earlier quoted context omitted.
Which is why in some OS written in memory safe systems languages, like Burroughs, still being sold by Unisys as ClearPath MCP, any use of unsafe code blocks taints the binary. Execution is only allowed after the OS admin adds the executable to a specific process white list. This is similar to how some managed runtimes work, and the Java ecosystem is moving forwards it. Currently it only triggers a warning, however in…
That's probably because the OS itself didn't have great defenses, right? We have permissioned virtual memory now.
The customers that still buy such systems, care about security as the feature above anything else.
As you can see, the marketing is all about security.
https://www.unisys.com/product-info-sheet/ecs/clearpath-mast...
I don't the fanaticism around memory safe languages. We've had memory safe languages for a very long time. Algol-60, the granddaddy of many modern languages, had it sixty-five years ago. Algol-60 also had other safety features that modern languages don't have - for example integer overflow safety. The real issue is that we came to accept unsafe languages and are taking a really long time to put such features back.
Earlier quoted context omitted.
> I was not aware of the antagonism from the Zig .. people to Rust, but it makes absolutely no sense. Lol, have you ever watch Andrew Kelley speak? I've only seen 3 or 4 talks he's given, but he frequently makes not-so-subtle digs towards Rust. Zig's home page prominently displays "Focus on debugging your application rather than debugging your programming language knowledge" which sounds horrible to me, but is clearl…
“Focus on debugging your application rather than debugging your programming language knowledge” to me sounds like it is directed primarily at C and C++., it’s a much more direct translation.
Earlier quoted context omitted.
> I was not aware of the antagonism from the Zig .. people to Rust, but it makes absolutely no sense. Lol, have you ever watch Andrew Kelley speak? I've only seen 3 or 4 talks he's given, but he frequently makes not-so-subtle digs towards Rust. Zig's home page prominently displays "Focus on debugging your application rather than debugging your programming language knowledge" which sounds horrible to me, but is clearl…
> "Focus on debugging your application rather than debugging your programming language knowledge" This sounds like it's made by someone who fears discovering they don't know something more than discovering they made a mistake. I am the reverse: I would prefer to debug my programming language knowledge over debugging my application. I hate debugging applications specifically because making a mistake is SO much worse t…
Earlier quoted context omitted.
> memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. I wouldn't go that far, what matters is the finished whole. Memory safety of the finished program is a critical factor and using a memory safe language makes it easier to achieve that goal. However simply using a memory safe language doesn't make you a "Software Engineer" any mor…
Overall safety matters. Memory safety is just one factor. Log4Shell happened in Java, a GC language without pointer arithmetic.
Presence of worse bugs won't make memory bugs disappear.
Earlier quoted context omitted.
> One of the basic ideas behind Rust's memory safety story is that eliminating race conditions Rust does not prevent race conditions. You're getting confused with data races. However GC's solution to data races (make every load/store act as very relaxed atomic instructions) makes race conditions much easier to write.
Rust does prevent race conditions.
Earlier quoted context omitted.
Linked lists are cool but they are terrible for cache performance, so their apparently elegant performance characteristics are often illusory. And hybrid data structures which get you the best of both worlds are quite complicated to implement. I think that's why there's a general pressure against using them unless you have a very specific reason (and ideally some measurements) to demonstrate that they are a good opti…
Yeah, I'd blame mainly 2 factors for the continued undue influence of linked lists 1. CS professors teach them. The Programme Lead for our CS course still teaches linked lists as the first data structure in the DSA course. Does this type exist? Sure. Is it a good idea? Almost never. But you wouldn't think so from its prominence in the course materials. 2. The Linux kernel uses a LOT of linked lists. Multi-core atomic…
In general yes, but right now I'm contributing to folk.computer, which is a multithreaded task scheduler/central DB (among other things not relevant to the topic at hand). The biggest use of atomics is during statement insertion and removal, by using RCU operations in the central trie.
One of our current performance drags is the interpreter we use is not threadsafe, so we have to serialize and deserialize objects as they move between threads. This contributes to about 30% of Folk's CPU usage. So I'm currently working on making a threadsafe interpreter by porting the Tcl interpreter we use (Jimtcl), and I'm learning all the fun things around atomic ordering and threaded data structures. So I'm definitely the audience for these data structures.
Well I feel most of the Rust devs are there for saying shits about other languages to prove their own dumbassness.