3 ms·

> The systems programmer has written drivers for buggy devices whose firmware was implemented by a drunken child or a sober goldfish This accurately describes

by weland 11y ago

> The systems programmer has written drivers for buggy devices whose firmware was implemented by a drunken child or a sober goldfish This accurately describes my experience lately. I knew those goldfish weren't to be trusted. Edit: > “Why would someone write code in a grotesque language that exposes raw memory addresses? Why not use a modern language with garbage collection and functional programming and free massages after lunch?” Here’s the answer: Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. This accurately describes my experience every time I click on a HN topic about Rust.

AceJohnny2 11y ago
Look, osmosis is a verified scientific fact! It's bound to work at some point! We've just got to adjust some simple parameters... <tightens clamp on chip-book assemblage>
kibwen 11y ago
> This accurately describes my experience every time I > click on a HN topic about Rust. Hm? Rust doesn't have garbage collection, let alone free massages. It does have pointers and it does have raw memory access. Like C++14, it's thoroughly a systems language with a few functional niceties floating around.
- andrewflnr 11y ago
  I think the joke is about people criticizing Rust for having pointers, etc.
- weland 11y ago
  THANK YOU! I'm in the Go camp myself (largely because I speak Unix and with Pike being involved it was inevitable) but I've read a lot on Rust and have been procrastinating learning it for about two years now. It's a very interesting language. Has a lot of helpful constructs. I'm quite convinced it's a better systems language than C++. However, every time something about Rust or Heartbleed hits the net, people flock around and dream of a world of Rust where Bad Stuff can't happen because Rust doesn't let you write programs that do Bad Stuff. Indeed, Rust doesn't let you write C++-branded Bad Stuff in Rust. Real life, however, leads me to believe that Rust-branded Bad Stuff will be trivial to write in Rust, and it is not the panacea that everyone hopes it is. It won't just magically make systems programming better and safer. People somehow managed to have buffer overflows in firmware written in that hideous form of Pascal that had the length of the array as part of the type, so foo(int x[10]) only compiled if you passed it an array of ten ints. They'll manage to write shitty, unsafe code in Rust, too. Edit: > let alone free massages. If you know of a language with free massages please share that information with me because I definitely want to learn it :-). I'm not nitpicking, it's just such a funny typo!
  - phonon 11y ago
    Umm, he was quoting "and free massages after lunch?" Not a typo :-)
    - weland 11y ago
      Oh. Crap. Joke's on me.
cbd1984 11y ago
Pointers are only real if you ignore MMUs and cache lines and imagine that C actually gives a good model of real modern hardware.
- weland 11y ago
  > Pointers are only real if you ignore MMUs Which is true on architectures without MMUs, which probably account for about 90% of the computing devices in use. Okay, maybe 85% since tablets and smartphones became important. And is also obviously true in MMU code. And then they're just pointing at an imaginary address that the MMU "projects", so they're still very real in the sense that the author is using (i.e. in one form or another, we're going to keep having to write arbitrary values at arbitrary addresses that mean something until someone figures out a better way to talk to devices). I don't think that better way doesn't exist. Like anyone who ever found himself wishing PDP-11 would just fucking die already, I even have a few ideas of my own about a better way. Alas, I'm probably wrong about them and I don't know of any commercially-available processor that has a better way of doing that. > ...and cache lines Which you can generally do as long as you remember to account for it when it comes to timing and you don't have a buggy cache. I know a guy who spent about an year and a half chasing a bug that got traced to a bug in the IP. It would occasionally decide to flush the cache, even though it didn't. Talk about dedication. > and imagine that C actually gives a good model of real modern hardware. It never really did, not even on the PDP-11, but that's hardly the point. LISP didn't really give that good a model of the LISP Machine either, but it provided an abstraction that was close enough to be useful and allow you to reason about what you had to do.

by weland 11y ago

AceJohnny2 11y ago

Look, osmosis is a verified scientific fact! It's bound to work at some point! We've just got to adjust some simple parameters... <tightens clamp on chip-book assemblage>

kibwen 11y ago

> This accurately describes my experience every time I > click on a HN topic about Rust. Hm? Rust doesn't have garbage collection, let alone free massages. It does have pointers and it does have raw memory access. Like C++14, it's thoroughly a systems language with a few functional niceties floating around.

andrewflnr 11y ago
I think the joke is about people criticizing Rust for having pointers, etc.
weland 11y ago
THANK YOU! I'm in the Go camp myself (largely because I speak Unix and with Pike being involved it was inevitable) but I've read a lot on Rust and have been procrastinating learning it for about two years now. It's a very interesting language. Has a lot of helpful constructs. I'm quite convinced it's a better systems language than C++. However, every time something about Rust or Heartbleed hits the net, people flock around and dream of a world of Rust where Bad Stuff can't happen because Rust doesn't let you write programs that do Bad Stuff. Indeed, Rust doesn't let you write C++-branded Bad Stuff in Rust. Real life, however, leads me to believe that Rust-branded Bad Stuff will be trivial to write in Rust, and it is not the panacea that everyone hopes it is. It won't just magically make systems programming better and safer. People somehow managed to have buffer overflows in firmware written in that hideous form of Pascal that had the length of the array as part of the type, so foo(int x[10]) only compiled if you passed it an array of ten ints. They'll manage to write shitty, unsafe code in Rust, too. Edit: > let alone free massages. If you know of a language with free massages please share that information with me because I definitely want to learn it :-). I'm not nitpicking, it's just such a funny typo!
- phonon 11y ago
  Umm, he was quoting "and free massages after lunch?" Not a typo :-)
  - weland 11y ago
    Oh. Crap. Joke's on me.

cbd1984 11y ago

Pointers are only real if you ignore MMUs and cache lines and imagine that C actually gives a good model of real modern hardware.

weland 11y ago
> Pointers are only real if you ignore MMUs Which is true on architectures without MMUs, which probably account for about 90% of the computing devices in use. Okay, maybe 85% since tablets and smartphones became important. And is also obviously true in MMU code. And then they're just pointing at an imaginary address that the MMU "projects", so they're still very real in the sense that the author is using (i.e. in one form or another, we're going to keep having to write arbitrary values at arbitrary addresses that mean something until someone figures out a better way to talk to devices). I don't think that better way doesn't exist. Like anyone who ever found himself wishing PDP-11 would just fucking die already, I even have a few ideas of my own about a better way. Alas, I'm probably wrong about them and I don't know of any commercially-available processor that has a better way of doing that. > ...and cache lines Which you can generally do as long as you remember to account for it when it comes to timing and you don't have a buggy cache. I know a guy who spent about an year and a half chasing a bug that got traced to a bug in the IP. It would occasionally decide to flush the cache, even though it didn't. Talk about dedication. > and imagine that C actually gives a good model of real modern hardware. It never really did, not even on the PDP-11, but that's hardly the point. LISP didn't really give that good a model of the LISP Machine either, but it provided an abstraction that was close enough to be useful and allow you to reason about what you had to do.