51–60 of 133 posts
If you rewrite the Linux kernel in Rust, one module at a time, you'll just end up with C written in Rust syntax, with raw pointers all over the place.
Earlier quoted context omitted.
Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is https://github.com/ckkashyap/nimxv6 which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things…
Do you get anything with him? I was under the impression dereference safety wasn't a priority.
Earlier quoted context omitted.
Ongoing, but BEAM is no longer part of my day job (though Rust is), so it's slower going and only moves occasionally forward between the hours of 12am and 3am when the rest of my family is asleep.
Thank you. I was just reading your comments and found this one: >Erlang: the general disinterest of Ericsson and the hapless stewardship of Erlang Solutions. Is that related to the reason that BEAM is no longer part of your day job? The reason I ask is that I am thinking of starting a new project with BEAM, maybe some Rust or C++ and wondering whether Elixir has taken over from Erlang due to the disinterest of Erics…
Erlang is by far my favorite language and environment to use, and for a whole slew of things I'd still grab it for production projects/products.
I moved into the world of autonomous vehicle runtime software, and tools closer to the metal with deterministic timing characteristics are a requirement.
Earlier quoted context omitted.
Ongoing, but BEAM is no longer part of my day job (though Rust is), so it's slower going and only moves occasionally forward between the hours of 12am and 3am when the rest of my family is asleep.
Don't suppose your work is online? I'd be interested to read your patchsets.
This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.
Rust doesn't have downsides of C++ by design.
Earlier quoted context omitted.
Thank you. I was just reading your comments and found this one: >Erlang: the general disinterest of Ericsson and the hapless stewardship of Erlang Solutions. Is that related to the reason that BEAM is no longer part of your day job? The reason I ask is that I am thinking of starting a new project with BEAM, maybe some Rust or C++ and wondering whether Elixir has taken over from Erlang due to the disinterest of Erics…
Nope, not the reason. My "go-to" language when prototyping most things is still Erlang. Erlang is by far my favorite language and environment to use, and for a whole slew of things I'd still grab it for production projects/products. I moved into the world of autonomous vehicle runtime software, and tools closer to the metal with deterministic timing characteristics are a requirement.
From what you write, it sounds like in production that, if one is attracted by the BEAM, there is less risk in choosing Erlang than Elixir.
One thing that concerns me for production use is the combination of the Erlang license and the possibility of Ericsson "doing a Sun" by selling the technology to Oracle, which might lead to an Android like situation.
Earlier quoted context omitted.
Nope, not the reason. My "go-to" language when prototyping most things is still Erlang. Erlang is by far my favorite language and environment to use, and for a whole slew of things I'd still grab it for production projects/products. I moved into the world of autonomous vehicle runtime software, and tools closer to the metal with deterministic timing characteristics are a requirement.
Thank you for the useful clarification. From what you write, it sounds like in production that, if one is attracted by the BEAM, there is less risk in choosing Erlang than Elixir. One thing that concerns me for production use is the combination of the Erlang license and the possibility of Ericsson "doing a Sun" by selling the technology to Oracle, which might lead to an Android like situation.
It's trivial to include Erlang in an Elixir project, it's slightly less simple to go the other way, but it's still doable. In either case I don't think you have much in the way of risk regarding Ericsson pulling a Sun. When I say Ericsson is "disinterested" I just mean they're not inclined to promote or progress the language with the kind of pace and/or hype required to keep a thriving and active Silicon Valley shaped community going.
It's a tool that works well at exactly what it was designed for. There's no driving force trying to move it further to take over the general purpose programming world like Java had or Go has.
Anyway, we're epically off topic :-) I think my email is in my HN profile, so happy to take this offline.
Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome. Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it bein…
Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is https://github.com/ckkashyap/nimxv6 which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things…
Perhaps Nim can be used to write kernel modules already.
Earlier quoted context omitted.
Thank you for the useful clarification. From what you write, it sounds like in production that, if one is attracted by the BEAM, there is less risk in choosing Erlang than Elixir. One thing that concerns me for production use is the combination of the Erlang license and the possibility of Ericsson "doing a Sun" by selling the technology to Oracle, which might lead to an Android like situation.
Well... Elixir has a thriving community around it right now. Erlang has a lot of really mature libraries and frameworks. It's trivial to include Erlang in an Elixir project, it's slightly less simple to go the other way, but it's still doable. In either case I don't think you have much in the way of risk regarding Ericsson pulling a Sun. When I say Ericsson is "disinterested" I just mean they're not inclined to promo…
Sorry and thank you again - was very interested in your experience.
Earlier quoted context omitted.
If there were a fork and the fork were to gain momentum it might be not be up to Linus. A project like this might attract new developers because it might be less intimidating than joining the Linux kernel proper. There would also be the attraction of learning Rust in a very real world context. edit:s/in/it
This is a good argument if a massive amount of effort was piled into this with lots of refactoring on top of it. Meanwhile, it doesn't have a snowball's chance in hell of accomplishing anything.
One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux.
Linus has stated that he isn't particularly interested in security bugs. Other people take a different view. Eg. [1], [2]
Another incremental step to improved security in Linux after a Rust fork might be to take the lessons learned to create a conservative set of Rust inspired extensions to C without all the hoariness of C++.
[1] https://news.ycombinator.com/item?id=2539839
[2] https://www.schneier.com/blog/archives/2015/11/linus_torvald...
edit 1: removed apparently dead link to original source http://lkml.org/lkml/2008/7/15/296
edit 2: clarify that one wouldn't use the name Linux for the fork