𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍 
  • 3 Posts
  • 509 Comments
Joined 2 years ago
cake
Cake day: August 26th, 2022

help-circle
  • Doesn’t it steal control flow? More like a break point, except you define where execution continues.

    I wonder if it’s a compile error to have multiple conflicting COMEFROM statements, or if it’s random, kind of like Go’s select statement.

    How awesome would it be to be able to steal the execution stack from arbitrary code; how much more awesome if it was indeterminate which of multiple conflicting COMEFROM frames received control! And if it included a state closure from the stolen frame?

    Now I want this.









  • Everything is slower than C (I haven’t seen a benchmark yet where a language bests C; even hand-crafted ASM ceded the high ground decades ago when compilers got better than human assembly programmers), but then, C compiler technology has had literally 40+ years to mature.

    Go and Java (once warm) do pretty well, but absolutely give up execution speed for coding simplicity and (in Go’s case, anyway) speed. Nim is young; I’m curious to see how it matures. They’re having a bit of a performance crisis at the moment, but assuming they get past that it seems like a fair middle ground between Go’s simplicity and Rust’s bare-metal performance. Then again, manual memory management was absolutely my least favorite thing about C and is what eventually drove me away; worst. Boilerplate. Ever. Even worse than Go’s error handling (which they almost fixed and looks like will be addressed within the next free releases). Anyhoo, going back to that shit is going to be a hard pill to swallow.

    Rust is still having its honeymoon, and is the hip language of the decade now. We’ll see!


  • I think you’re missing the point where I said I don’t write Rust. I’m merely making an observation - as a user who’s more than usual, probably, aware of which language any given tool is written in, of what I observe.

    I know I’ve seen a Rust program segfault, and I’m certain that I saw this only once. I’m equally confident that almost every other segfault has been from C/C++ code, but not other languages.

    What I’m hearing you say is that crashes aren’t a risk, per se, as long as they aren’t memory related and so the crashes I see from Rust programs don’t count because they aren’t segmentation faults. Did I read that right? And I also hear you claiming that, e.g., NPEs are security issues, even if the runtime catches them and safely exits the program in a controlled manner (“crashing out” safely) - is that right?




  • Sure. I haven’t seen a proper segfault from any modern, post-C/C++ language in ages. I’ve never seen a Go program segfault, or a Nim one (although, there are comparatively few of those as a sample size).

    So, it seems to me that - purely from the perspective of a user of programs - Rust still seems about as safe as any other modern language - since I’ve seen no other modern (say, created in the past decade) compiled language segfault. Even the C segfaults seem to be largely becoming rare occurrences, which I have to chalk up to better tooling, because I highly doubt that there’s been some magical increase in general C programmer quality in the intervening years.


  • As a user. I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in. I almost never see segfaults; I can’t say I’ve ever seen one in a Go program, and I use a bunch on those.

    If we’re only talking about segfaults, the only language I can remember seeing doing that has been C, or C++. If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust. If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.



  • Related, but just hanging this on here. As the default (as installed) security of distributions has improved, so have the amount of headaches when trying to use tools like this increased. For decades, when I’ve had issues like this is not been because of a LAN firewall issue, and so now my first thought is never been, “I should check the firewall,” when it should.

    Sadly, firewall info is almost always locked down so that apps can’t even check by themselves and provide helpful hints to users.

    Anyway, it’s been a hard lesson for me to learn, for some reason. I need to practice my mantra: it’s always the firewall.