11 ms·
> the syntax is almost as noise-free as exceptions No. const USAGE: &'static str = "usage string"; I did rewrite it in Rust. I rewrote a small low level comm
by CalChris 9y ago
> the syntax is almost as noise-free as exceptions
No.
const USAGE: &'static str = "usage string";
I did rewrite it in Rust. I rewrote a small low level command line app in Rust. I really wanted to like Rust going in but I freaking hated it going out. They had a few good ideas but they never knew how to say no. The part I hated the most was the Rust macro language. And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C.
Go is pretty minimal. They knew how to say no. I like modern C (C99 and C11). It has most of the good ideas from C++.
- steveklabnik 9y agoAs of the most recent release, that's now const USAGE: &str = "usage string"; and there's talk of maybe making it const USAGE = "usage string"; > The part I hated the most was the Rust macro language. We don't like it either; there's a replacement coming. We reserved the "macro" keyword before 1.0 and made the current one use the less-good "macro_rules" to help ease the eventual transition.
- GrayShade 9y ago> We don't like it either But.. but.. Scheme macros are so nice!
- steveklabnik 9y agoTotally! It's not about the fundamentals, it's about things like "macros are global" and "almost entirely hygienic but sometimes not", stuff like that. Stuff that would be backwards incompatible to just fix.
- Rusky 9y agoThe comment was about error handling syntax, not constant declaration syntax. The comparison being made is between `result = foo(); if (!result) { ... }`, `foo();`, and `foo()?;`. > And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C. Sounds wrong to me. People have done things like booting up x86 with all of the hardware bit-twiddling behind safe interfaces (for example: https://os.phil-opp.com/ https://os.phil-opp.com/).
- CalChris 9y agosetjmp wasn't even supported. I had to use an LLVM intrinsic. This only barely worked if I put the setjmp and the longjmp in separate files.
- Rusky 9y agoWhy is setjmp such a major issue for you? It's a C language feature, not a "real low level to the metal systems programming" requirement.
- CalChris 9y agoIf you are calling C or assembly and there is any sort of processor exception, you need to establish a signal() handler and you will need setjmp/longjmp to re-establish a safe stack frame. Yes, this is a C/assembly thing. But it is also a Linux/BSD/Unix thing. You really cannot call Rust a systems programming language if signal/setjmp/longjmp are not fully supported. It just goes with the territory.
- Rusky 9y agoLinux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority. And for now, there are definitely ways to handle signals using libraries.
- lossolo 9y ago> Linux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority. Do you have any source that can confirm that? Because what you wrote seems really wrong. I see linuxes/bsd/unix EVERYWHERE (Android/iOS/OSX/almost all backend servers etc.)
- Rusky 9y agoI'm thinking of embedded systems and desktop machines- the first tends not to use an OS nearly that big (if any at all), and the second tends to use Windows.
- GrayShade 9y ago> And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C. You might want to take a look at this series: http://blog.japaric.io/fearless-concurrency/ http://blog.japaric.io/fearless-concurrency/ .