
Operating System Development in Rust - krenoten
https://github.com/rust-lang/rust/wiki/Operating-system-development
======
Animats
Somewhere in this direction lies the post-C era. The post-buffer-overflow era.
And do we need it.

 _It has been 6 days since the last CERT advisory for a buffer overflow
security hole._

~~~
userbinator
The era of unrootable devices, unbreakable DRM, and inescapable walled
gardens? Considering that this will basically be "trusted computing done
right", I'm quite frankly more scared than anything...

I'm not saying that security holes are nothing to worry about, as I am no less
irritated by buggy programs than anyone else, but the alternative might be
worse.

~~~
tatterdemalion
Restrictions placed on Turing machines by their producers are ultimately a
political problem and not a technical one. We will indeed have to solve it one
day once those restrictions are not buggy.

~~~
userbinator
It is a political problem, but I think it's one that has to be solved _very
very soon_ , because the majority of the population seem to acquiesce quickly
to these new restrictions and "safer" (against them) systems without thinking
much of the negative aspects. To let it reach the point when freedom is
completely associated with malware, terrorism, or whatever else is used to
frighten the population into comformity, it may be too late to oppose.

------
krenoten
Many people seem to be confused by Rust's lack of limitations imposed on you
as a programmer. In particular, the fact that so much of what is thought of as
a runtime is provided as optional libraries. You can run tasks similar to
Goroutines, which are provided as a library. You can use certain types of
garbage collection as a library. You have dramatic freedom and accessible
choices. The possibilities are incredibly inspiring.

~~~
SwellJoe
In my tinkering with both Go and Rust, and liking the looks of both, I get
vague feelings like Go is to Python as Rust is to Perl. This may be damning
praise for some folks, but it makes me lean slightly toward Rust more than Go
(slightly). There seems to be almost an anti-library culture in Go (i.e. "use
the standard library" is almost a mantra in Go) whereas in Rust, there's more
than one way to do it (even this early in its existence).

That said, in many ways neither language is like the one I've compared it to,
probably in enough ways that it's not a useful comparison for much other than
this one metric (the TIMTOWDIness of the language). But, it's how my head is
processing these two quite novel (to me) languages; which would make sense, as
I've written more code in Python and Perl than probably anything else, so
they're the known things I compare these unknown things to.

~~~
thirsteh
You could say that Go is Python and Rust is Haskell, because, well, Rust is
basically Haskell cleverly disguised as a C-style language so as to not scare
away imperative programmers.

~~~
detrino
> Rust is basically Haskell cleverly disguised as a C-style language so as to
> not scare away imperative programmers.

This comment is very condescending. It makes it seem as if C programmers are
ignorant and Haskell programmers are enlightened. Haskell is a garbage
collected, lazy, pure language which makes it unsuitable for many of the
domains C-style languages are used in. These are also qualities not shared by
Rust, which may explain why there is less resistance in its uptake by C
programmers.

~~~
naasking
> Haskell is a garbage collected, lazy, pure language which makes it
> unsuitable for many of the domains C-style languages are used in.

Don't be so sure! [1] You could simply use Haskell as a metalanguage to
generate a C program that does what you need, just like they did with copilot.
No Haskell runtime needed.

[1] [https://github.com/leepike/copilot-
discussion](https://github.com/leepike/copilot-discussion)

------
thom
Also worth checking out:

[http://rust-class.org/](http://rust-class.org/)

Or maybe this, if UEFI is palatable to you:

[http://blog.theincredibleholk.org/blog/2013/11/18/booting-
to...](http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/)

------
cmsd2
For bootstrapping a kernel, I had trouble with cross compiling. My kernel
doesn't yet support a libc hosted environment, so I use a i686-pc-elf gcc
target with -ffreestanding. rustc works niceley if your target environment is
similar enough to your dev environment, or if you are developing for android
for which there's an sdk and rustc port already. I initially tripped up on
this because i'm developing on osx currently, but targetting gnu. I just need
the rustc equivalent of -ffreestanding. Alternatively I'll have to wait until
I've got a proper i686-myos gcc and libc port.

