- cross-posted to:
- opensource@lemmy.ml
- cross-posted to:
- opensource@lemmy.ml
This isn’t Linux, but Linux-like. Its a microkernel built from the rust programming language. Its still experimental, but I think it has great potential. It has a GUI desktop, but the compiler isn’t quite fully working yet.
Has anyone used this before? What was your experience with it?
Note: If this is inappropriate since this isn’t technically Linux, mods please take down.
You must log in or register to comment.
I’m not against Rust, per se, the idea of a systems programming language with some more advanced memory safety features sounds nice, but what is with the emphasis on creating a Rust version of everything? Like why should we want an OS written only in Rust?
Eh, I welcome the iteration. It gives people a reason to practice and hey, who knows, maybe they’ll come up with something neat while rewriting curl or something
Some thoughts:
- Testing the capabilities of rust and proving what rust is capable of.
- Seeing what rust is not capable of and proposing improvements for the rust language and ecosystem.
- Trying new OS concepts. Linux for example is strongly backwards compatible. Starting a new OS is the opportunity to do things different and maybe better.
- Maybe it will turn out, that the memory safety will improve OS’. We will only know for sure, if we try it.
This is one of my main gripes with the rust community. What programming language you used shouldn’t be of any concern to the end-user, let alone be put in the tagline.
Rust is a very good and capable language and I enjoy using it. I can’t wait for the day it overtakes C or C++. But I want to know more about the program I’m using other than that it was written in a popular language.
“Written in rust” is basically a meme at this point.
This is typical of when a language is the new hotness. It eventually dies down, either because the language becomes endemic or it fades away.
not necessarily about the language, but things periodically getting rewritten or re-implemented is a useful exercise. it’s a moment for reflection and analysis of the structures and systems as a whole
Languages are easier to work with the bigger the ecosystem.
I’ve been installing a lot of things written in rust recently, and I’ve noticed a trend between them. They’re all stable, fast, and very user-friendly. I don’t really have to fiddle with them nearly as much. I think there’s a lot that goes into this, but it really boils down to: rust is safer and prevents huge categories of bugs, it’s incredibly stable and requires less debugging and maintenance, it has extremely high level abstractions to make development quick and less verbose, and it has the best tooling I have seen for any language. It enables developers so effectictively that the things that are usually tedious and difficult become easy and potentially mandatory, and so you just get better software.
I know that sounds pretty abstract and opinionated, but having used the language for several years now, and especially coming from Java, I have really felt an incredible difference - I stopped having to constantly fix breaking Gradle builds and JVM version management, I stopped getting null pointer exceptions, and I had much more powerful tools for building abstractions. When you see how much control and power rust gives you while still keeping you safe, it’s just night and day compared to the especially old languages like C.
Basically, anything written in rust will be better if it can enable developers to spend their time working on useful features instead of fixing bugs, fiddling with build systems and fragile legacy infrastructure cobbled together from dozens of third party tools.
I don’t understand the obsession with rust.
From my personal experience I can tell you 2 reasons. The first is that this is the first general purpose language that can be used for all projects. You can use it on the web browser with web assembly, it is good for backend and it also is low level enough to use it for OS development and embedded. Other languages are good only for some thing and really bad for others. The second reason is that it is designed around catching errors at compile time. The error handling and strict typing forces the developer to handle errors. I have to spend more time creating the program but considerably less time finding and fixing bugs.
That sounds pretty great. I get sick of having to switch gears for every layer. As a hobbyist it is tough to remember five or six languages well enough when only coding something a few times a year.
Since I do embedded, scripting, web front and back end this is sure tempting.
I have been hesitant to try to learn yet another language (this would make…ummm… idk I lost count ages ago). But with all the hype I may break down and give it a whirl.
Sounds like python may be a better fit if its supported on the embedded devices you use as it will cover scripting and backend too. Rust has quite a learning curve and can be rather verbose.
I do use python quite a bit for scripting and backend, app, and I’ve used MicroPython a little bit, preferring C, C++ for embedded. It’s pretty great for what I need.
I might mess around with Rust out of curiosity anyway, though the downsides you mention make it less compelling for me, personally. I’m not a big fan of verbose languages (e.g., Java, though I have used it for some apps).
If you are curious definitely do check it out! It’s a really cool language to learn and you’ll start to enjoy the fight the compiler puts up.
Sorry but I don’t see the reasoning backing the enthusiasm for python. Sure, it is great for scripting (this includes machine learning), but why for anything else?
An easy language that works everywhere? This person is writing code a few times a year.
Wdym
I feel like C++ is as competent as Rust for any project and it’s definitely older.
Before using Rust I was using C++ for most projects and while it is a really powerful language there were some big problems:
- no standard build system, most projects use cmake or meson and vendor dependencies with the projects. These build systems were really hard to learn (especially cmake, meson is easier). There are package managers these days such as conan and vcpkg but there is not really one standard way to build programs like in rust.
- error messages were really hard to understand, especially when the project uses templates
- it felt like 3 languages in one, projects written before c++11 differ greatly from c++11 and up
- some of the new language features have really weird syntax, for example lambdas
- some people say that rust is hard, but modern c++ is considerably harder to learn, just look at the list of modern c++ features: https://github.com/AnthonyCalandra/modern-cpp-features, you have to know the different pointer types (unique_pointer, shared_pointer etc.), templates, rvalue references and move semantic, exceptions, constexpressions and the list goes on
At least it won’t complain about rigid, skolem or occurrence check.
Rust was created because c++ was so bad. Just take a look at crates they need a whole lot less maintenance because less bugs.
My point wasn’t that C++ is good. My point was that C++ can and is used everywhere (desktop applications, web applications, OSs,…) and is older than Rust. So I feel that “this is the first general purpose language that can be used for all projects” is false. Probably “this is the first general purpose language that I (and many others) like to use for all projects” is true, but is a different claim.
TLDR: You said Rust was first language capable of system, app and web, it isn’t.
It is good and rust improves on its gaping weaknesses.
Yeah I never made that claim the threads OP did.
I know the evangelists can be somewhat overwhelming, but its popularity is not unwarranted. It’s fairly easy to pick up, has an incredibly enthusiastic and welcoming community. People like it because it’s incredibly performant, and its memory safe. In terms of DX it’s really a joy to work with. It just has a LOT going for it, and the main drawback you’ll hear about (difficulty) is really overblown and most devs can pick it up in a matter of months.
The main difficulty I have with Rust (what prevents me from using it), is that the maintainers insist on statically compiling everything. This is fine for small programs, and even large monolithic applications that are not expected to change very often.
But for the machine learning projects I work on, I might want to include a single algorithm from a fairly large library of algorithms. The amount of memory used is not trivial, I am talking about the difference between loading a single algorithm in 50 MB of compiled code for a dynamically loadable library, versus loading the entire 1.5 GB library of algorithms of statically linked code just to use that one algorithm. Then when distributing this code to a few dozen compute nodes, that 50 MB versus 1.5 GB is suddenly a very noticeable difference.
There are other problems with statically linking everything as well, for example, if you want your application to be written in a high-level language like Python, TypeScript, or Lisp, you might want to have a library of Rust code that you can dynamically load into the Python interpreter and establish foreign function bindings to the Rust APIs. But this is not possible with statically linked code.
And as I understand, it is a difficult technical problem to solve. Apparently, in order for Rust to optimize a program and guarantee type safety and performance, it needs the type information in the source code. This type information is not normally stored into the dynamically loadable libraries (the
.soor.dllfiles), so if you dynamically load a library into a Rust program its type safety and performance guarantees go out the window. So the Rust compiler developers have chosen to make everything as statically compiled as possible.This is why I don’t see Rust replacing C any time soon. A language like Zig might have a better chance than Rust because it can produce dynamically loadable libraries that are fully ABI compatible with the libraries compiled by C compilers.
Is it not possible for Rust to optimize out unused functions as with C? That seems …like a strange choice if so.
Is it not possible for Rust to optimize out unused functions as with C?
No Rust can do dead code elimination. And I just checked, Rust can do indeed do FFI bindings from other languages when you ask the compiler to produce dynamically linking libraries, but I am guessing it has the same problems as Haskell when it produces
.soor.dllfiles. In Haskell, things like “monad transformers” depend pretty heavily on function inlining in order to achieve good performance.So I am talking more about how Rust makes use of the type system to make decisions about when to inline functions which is pretty important when it comes to performance. You usually can’t inline across module boundaries unless modules are all statically linked. So as I understand it, if you enable dynamic linking in your Rust program, you might see performance suffer a lot as compared to static linking, and this is why most Rust people (as I understand it) just make everything statically linked by default.
Do you need inlining if you just use fixed monad transformers?
Do you need inlining if you just use fixed monad transformers?
I am not sure what you mean by “fixed” monad transformers, if you mean writing your own
newtypewhere the functor variable is the only type variable, essentially what you are doing is hand-inlining the monad transformer, and so no, if you inline by hand, then the compiler doesn’t need to do it.Haskell inlines all
newtypedefinitions automatically, so if your monad transformer has all of the type variables bound (except for the functor variable, because that is a special case the Haskell compiler is specifically designed to handle) the compiler will usually reduce those to ordinary lambda expressions automatically, and lambda expressions usually optimize to the most efficient machine code.The only time the compiler cannot reduce a
newtypeto an efficient lambda is if the non-functor variables, e.g. the state type variable or the exception type variable, are unbound. Those values could become anything at all at its call site, limited only by the constraints set by the type context. So the type context information, a lookup table of type class instances, must be associated with that lambda expression, and in order to do that, the compiler must create a closure around those values. Creating closures allocates values on the heap, and this is much, much slower than efficient lambda expressions, and no faster than allocating a data constructor as with Free Monads.Alexis King did a presentation on it where she explains all of this extremely well, if you are interested: https://youtu.be/0jI-AlWEwYI
It is a bit long, but at 17:40 or so she starts talking about strategies for how monads and effects can be implemented in the GHC intermediate code, and compares Free Monads and effects to monad transformers. At 21:15 or so she begins to explain how
newtypetypes can be optimized away completely,newtypeconstructors don’t exist at all in the low-level code, they are a “zero-cost abstraction.” On the other hand,dataconstructors (used for Free monads and effects) always allocate something on the heap which is an order of magnitude slower.Then at around 27:45 she begins to show how
newtypeswith type variables cannot be inlined across module boundaries for the reason I explained above (type context tables associated with closures), and so monad transformers cannot be optimized across module boundaries.Yep, I mean like
newtype MyT m a = MyT (ReaderT MyEnv (StateT MyState m) a). But one can useReaderT MyEnv (State MyState m) adirectly as well.I found the MTL style (tagless final) a bit problematic anyway, so I wanted to comment about this.
It is and it does.
And the fucking MIT License
Yes, as much as I appreciate memory safety and rust in particular. I’m very worried by this pivot away from copyleft and GPL. Specially the rewriting in rust phenomenon of fundamental stuff. It’s safer, yes, but they’re all pretty much non GPL and it seems very risky to me. Make no mistake, the industry is riding this wave to move away from copyleft to permissive licenses.
I wish that people understood the importance of FSF and GNU
Well that is rather insidious. Crap. They probably understand the reasons for the GPL very well. Doesn’t mean they support them.
I’m sure there’s some community pull as well, because most of the rust ecosystem seems to be converged on MIT. But what despairs me is the wilful sidelining of GPL and everything GNU by some open source community members/corporate people. So yeah, you’re probably right
It’s a system programming language that isn’t C or C++.
Edit to add: How did Go get on that page? That’s a stretch.
deleted by creator
- breaks compatibility
- breaks compatibility
- breaks compatibility
- hard to add without breaking compatibility
Then we arrive at Rust as a natural outcome.
And it’s of course possible to migrate to Rust from C or C++ progressively, fish has almost got it done.
Guaranteed memory saftey
Idk what the iso fuck up and I don’t code enough to appreciate whatever technical debt exists in either so I am probably sound like an idiot but…
Since I do infosec, the glaring issue for me is not being memory safe.
The idea is less bugs due to stricter rules when developing and compiling. You can understand that.
Then, also more access to build tools and high level programming without changing languages.
If you have no need for that, then just know others do and it’s a great thing.
I’ve used it in a VM just to mess around. I’d like to install it on an old ThinkPad and try to compile some applications.
Oh my god they rewrote Linux in Rust. Amazing.
Kinda. Redox uses a microkernel architecture and tries to keep only the most important functionality in ring 0 while they push everything else in userspace. It’s great.
I wouldn’t say it’s inappropriate as there is more and more rust making it into the native kernel. I’ll definitely throw this on my Ventoy usb and see if I can get it to boot
Having some hardware mentioned on the site that is supported and ready for use could be helpful if someone wants to try it (say raspberry pi), There are probably people who are worried to will make their computer explode.
https://gitlab.redox-os.org/redox-os/redox/-/blob/master/HARDWARE.md
It can be found from the “Quick Start” page
Linked in the faq : https://gitlab.redox-os.org/redox-os/redox/-/blob/master/HARDWARE.md
Shame they don’t have a list of the packages they offer.
It’s a bit hidden in the FAQ, but here you go.
Linked in the faq : https://static.redox-os.org/pkg/x86_64-unknown-redox/
Slap a Firefox on top (and time travel to when ff is all rusted) and we’ll be coming for ChromeOS. But will windows be completely rusted first? 🙃
I think the main reason Firefox isn’t on there is because redox os doesn’t use Wayland and x11. Porting firefox would be a massive effort unfortunately.
If it weren’t “written in rust” nobody would give a shit.
Do you think other people do things simply because they think you will care?
