5 ms·

> By "the embedded space" do you mean "devices running Linux with Rust in userspace?" No, I mean TockOS with the Hail dev board: https://www.tockos.org/blog/20

> By "the embedded space" do you mean "devices running Linux with Rust in userspace?" No, I mean TockOS with the Hail dev board: https://www.tockos.org/blog/2017/introducing-hail/ https://www.tockos.org/blog/2017/introducing-hail/ > Rust is way more complicated than it should be People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock. > Rust also has the shiny fad status working against it IMO. Rust is 2 years into it's stable life. It's young, will it ever exceed the number of lines written than C or C++, almost definitely not, but I wouldn't dismiss it off-hand because people like it, there might be a good reason for that. > If, say, 5% of C hackers understand low level programming and/or kernel hacking, then maybe 0.5% of Rust hackers do (if that). I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%. > C is boring I've met more undefined behavior that makes me not agree. > and straightforward. :/

geocar 9y ago
> > Rust is way more complicated than it should be > People often make this statement, but I don't know exactly what it means. I can't speak for op, but you're right: people often make this statement. I'll try to explain what I might mean: C is way more complicated than it should be. The things we want in a language are tools that allow us to tell the computer what to do, but because people are bad at that, language design is taking us in the direction of telling the computer what we mean so it can tell us whether we're talking gibberish or not. I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. I have a good idea what kind of machine code the compiler is producing, and yes: I often objdump to make sure. If I need a FSM, I'll use erlang. If I need any kind of data processing, I'll probably use K/Q where I can. I can write some fast stuff in C where I need it. If I just need to bosh some stuff together I have perl. Maybe I want to fantasize about a DSL? It'll probably be a lisp or a forth. If I wanted a strong type system for units I want to get from some model nerds, I'll use OCaml. I don't see the point in Rust when doing these things takes more code and runs slower, and worse: > Rust is 2 years into it's stable life. It's young. I got burned by Python when it was" two years into its stable life" sometime around 1.5 and again around 2.2, and so I hesitate even looking at rust unless in a decade it can still run and compile rust programs written today. This whole "let's rewrite everything in rust" is good practice. I'm watching you guys do it, and I know afterwards you'll try to beat the performance I'm getting in other languages. Once you're writing programs that are smaller and faster than me, then we'll probably talk. > C: I've met more undefined behavior that makes me not agree. I don't write C like most people, so perhaps I don't have trouble with it like most people. My C programs don't leak memory or crash, and I tend to use a belt+braces approach to security that is very difficult in languages without good multiprocess support.
- Gaelan 9y ago
  I use butterflies.
- hota_mazi 9y ago
  > I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. No, you don't. Regardless of your skills and seniority (I'm guessing pretty junior with this kind of hubris), there will come a time where you will make mistakes that can be caught by a good compiler. You want this compiler at your side, and the more statically typed your language is, the more robust your code will be. > Once you're writing programs that are smaller and faster than me, then we'll probably talk What a strange metric. Assembly language would probably meet these requirements but surely, you would not consider it.
  - mining 9y ago
    > I'm guessing pretty junior with this kind of hubris If you check their profile their site suggests that have ~15 years of experience.
    - geocar 9y ago
      That's just management experience. I've been programming professionally for almost thirty years at this point. That's admittedly long enough to get some peculiar ideas about programming, but there's a certain kind of person that thinks "statically typing" is a panacea for programming mistakes -- or even that there's a single solution for anything at all...
      - hota_mazi 9y ago
        I wouldn't trust anyone who thinks a solution is a panacea in the software field, but having type annotations demonstrably leads to not just more correct code but also code that can be understood better by its surrounding tooling, thereby enabling automatic refactorings, auto completion, smart browsing, optimizations, etc... Static typing is not perfect but it's better in all respects than dynamic typing.
davemp 9y ago
OP is talking about a bare-metal world where you might care about things like: - how many instructions execute between an interrupt trigger and your vector getting executed - if some piece of data is getting stored in text, data, or runtime space (harvard v single address spaces can make things weird) - minimizing or not using a stack to avoid clobbering your puny memory - other misc. things that even hardware vendors don't make easy (or sometimes possible) to find Honestly I don't think that even C is great for these things, but I mostly blame hardware vendors/architects for this situation. They all like to roll their own standards for documentation, language interfaces, etc. Sometimes it feels like a competition to see who can come up with the worst.
Sir_Cmpwn 9y ago
>No, I mean TockOS with the Hail dev board: https://www.tockos.org/blog/2017/introducing-hail/ https://www.tockos.org/blog/2017/introducing-hail/ So more of the "Arduino like" embedded space. That also has little to do with the design constraints of a general purpose operating system. >People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock. Rust gets new features daily [1]. C gets new features every decade if we're lucky. >I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul... https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%. Embedded space != kernel hacking, as I've already pointed out. [1] https://github.com/rust-lang/rfcs/commits/master https://github.com/rust-lang/rfcs/commits/master
- bluejekyll 9y ago
  > That also has little to do with the design constraints of a general purpose operating system. Does it not? It's the same issue around no-stdlib, stricter sense of allocated memory, etc. If it isn't something that I can extrapolate from you'll have to explain better why. It's been a while since my CS courses on operating systems. > Rust gets new features daily [1]. C gets new features every decade if we're lucky. Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that. It's reasonable to say that the language isn't ready for your use, but the features that are being gained are all related to areas around ease of use of the language, making it easier to get started and lower the initial learning curve. They seem important. By the way, you linked to the RFC repo instead of the language repo: https://github.com/rust-lang/rust/commits/master https://github.com/rust-lang/rust/commits/master. The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable. > Embedded space != kernel hacking, as I've already pointed out. I thought we were talking about low-level programming, not explicitly Kernel hacking. Yes, Arduino and it's ilk are definitely not full OS'. For actual Kernel hacking in Rust, there is: - https://github.com/redox-os/redox https://github.com/redox-os/redox - https://intermezzos.github.io/book/ https://intermezzos.github.io/book/ - https://os.phil-opp.com/ https://os.phil-opp.com/ All of those projects seem very interesting. For Linux drivers, there was this exploratory project I saw a while back: https://github.com/tsgates/rust.ko https://github.com/tsgates/rust.ko (hasn't been touched in a while). So people are doing it and seem to be enjoying it.

geocar 9y ago

> > Rust is way more complicated than it should be > People often make this statement, but I don't know exactly what it means. I can't speak for op, but you're right: people often make this statement. I'll try to explain what I might mean: C is way more complicated than it should be. The things we want in a language are tools that allow us to tell the computer what to do, but because people are bad at that, language design is taking us in the direction of telling the computer what we mean so it can tell us whether we're talking gibberish or not. I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. I have a good idea what kind of machine code the compiler is producing, and yes: I often objdump to make sure. If I need a FSM, I'll use erlang. If I need any kind of data processing, I'll probably use K/Q where I can. I can write some fast stuff in C where I need it. If I just need to bosh some stuff together I have perl. Maybe I want to fantasize about a DSL? It'll probably be a lisp or a forth. If I wanted a strong type system for units I want to get from some model nerds, I'll use OCaml. I don't see the point in Rust when doing these things takes more code and runs slower, and worse: > Rust is 2 years into it's stable life. It's young. I got burned by Python when it was" two years into its stable life" sometime around 1.5 and again around 2.2, and so I hesitate even looking at rust unless in a decade it can still run and compile rust programs written today. This whole "let's rewrite everything in rust" is good practice. I'm watching you guys do it, and I know afterwards you'll try to beat the performance I'm getting in other languages. Once you're writing programs that are smaller and faster than me, then we'll probably talk. > C: I've met more undefined behavior that makes me not agree. I don't write C like most people, so perhaps I don't have trouble with it like most people. My C programs don't leak memory or crash, and I tend to use a belt+braces approach to security that is very difficult in languages without good multiprocess support.

Gaelan 9y ago
I use butterflies.
hota_mazi 9y ago
> I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. No, you don't. Regardless of your skills and seniority (I'm guessing pretty junior with this kind of hubris), there will come a time where you will make mistakes that can be caught by a good compiler. You want this compiler at your side, and the more statically typed your language is, the more robust your code will be. > Once you're writing programs that are smaller and faster than me, then we'll probably talk What a strange metric. Assembly language would probably meet these requirements but surely, you would not consider it.
- mining 9y ago
  > I'm guessing pretty junior with this kind of hubris If you check their profile their site suggests that have ~15 years of experience.
  - geocar 9y ago
    That's just management experience. I've been programming professionally for almost thirty years at this point. That's admittedly long enough to get some peculiar ideas about programming, but there's a certain kind of person that thinks "statically typing" is a panacea for programming mistakes -- or even that there's a single solution for anything at all...
    - hota_mazi 9y ago
      I wouldn't trust anyone who thinks a solution is a panacea in the software field, but having type annotations demonstrably leads to not just more correct code but also code that can be understood better by its surrounding tooling, thereby enabling automatic refactorings, auto completion, smart browsing, optimizations, etc... Static typing is not perfect but it's better in all respects than dynamic typing.

davemp 9y ago

OP is talking about a bare-metal world where you might care about things like: - how many instructions execute between an interrupt trigger and your vector getting executed - if some piece of data is getting stored in text, data, or runtime space (harvard v single address spaces can make things weird) - minimizing or not using a stack to avoid clobbering your puny memory - other misc. things that even hardware vendors don't make easy (or sometimes possible) to find Honestly I don't think that even C is great for these things, but I mostly blame hardware vendors/architects for this situation. They all like to roll their own standards for documentation, language interfaces, etc. Sometimes it feels like a competition to see who can come up with the worst.

Sir_Cmpwn 9y ago

>No, I mean TockOS with the Hail dev board: https://www.tockos.org/blog/2017/introducing-hail/ https://www.tockos.org/blog/2017/introducing-hail/ So more of the "Arduino like" embedded space. That also has little to do with the design constraints of a general purpose operating system. >People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock. Rust gets new features daily [1]. C gets new features every decade if we're lucky. >I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul... https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%. Embedded space != kernel hacking, as I've already pointed out. [1] https://github.com/rust-lang/rfcs/commits/master https://github.com/rust-lang/rfcs/commits/master

bluejekyll 9y ago
> That also has little to do with the design constraints of a general purpose operating system. Does it not? It's the same issue around no-stdlib, stricter sense of allocated memory, etc. If it isn't something that I can extrapolate from you'll have to explain better why. It's been a while since my CS courses on operating systems. > Rust gets new features daily [1]. C gets new features every decade if we're lucky. Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that. It's reasonable to say that the language isn't ready for your use, but the features that are being gained are all related to areas around ease of use of the language, making it easier to get started and lower the initial learning curve. They seem important. By the way, you linked to the RFC repo instead of the language repo: https://github.com/rust-lang/rust/commits/master https://github.com/rust-lang/rust/commits/master. The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable. > Embedded space != kernel hacking, as I've already pointed out. I thought we were talking about low-level programming, not explicitly Kernel hacking. Yes, Arduino and it's ilk are definitely not full OS'. For actual Kernel hacking in Rust, there is: - https://github.com/redox-os/redox https://github.com/redox-os/redox - https://intermezzos.github.io/book/ https://intermezzos.github.io/book/ - https://os.phil-opp.com/ https://os.phil-opp.com/ All of those projects seem very interesting. For Linux drivers, there was this exploratory project I saw a while back: https://github.com/tsgates/rust.ko https://github.com/tsgates/rust.ko (hasn't been touched in a while). So people are doing it and seem to be enjoying it.