Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewrite Linux Kernel in Rust?

dominuscarnufex.github.io

Post reply on HN
Print view View original

121–130 of 133 posts

Re: Rewrite Linux Kernel in Rust?

#121

Post by vog »

tom_mellior wrote: post #115
vog wrote: post #93

Earlier quoted context omitted.

> C code compiles fine after decades Early C code doesn't compile on modern systems at all. Speaking of early C code, every vendor had their own version. C standardization had to go a long way. Even today, writing portable C code is hard. Need a portable 128-bit integer? Good luck on Windows. Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when…

> Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of pointers change.

Whoops. I meant 16-bit versus 32-bit integers, when switching from 16-bit to 32-bit systems. Sorry for the confusion. Fortunately, they didn't repeat that mess for 32/64 bits, at least not for integers, but "decades old code" is still affected.

Re: Rewrite Linux Kernel in Rust?

#122

Post by tom_mellior »

vog wrote: post #121
tom_mellior wrote: post #115

Earlier quoted context omitted.

> Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of pointers change.

Whoops. I meant 16-bit versus 32-bit integers, when switching from 16-bit to 32-bit systems. Sorry for the confusion. Fortunately, they didn't repeat that mess for 32/64 bits, at least not for integers, but "decades old code" is still affected.

Ah, yes. I agree, that was a mess!

Re: Rewrite Linux Kernel in Rust?

#123

Post by youdontknowtho »

Retra wrote: post #102
youdontknowtho wrote: post #85

I guess one of the things that always comes to mind when someone brings up "Rust all the things" is that it assumes that anything that can be expressed in C can be expressed in Rust with the safety features enabled . Rust wouldn't have a mechanism to do unsafe code otherwise, right? I think it might be more complicated than we might think initially. I personally think that someone should probably spend some more time…

Safe rust clearly cannot express everything that can be expressed in C. It cannot even express everything that is safe in general. But "the safety features of Rust" includes drawing a barrier between the safe parts of your code and the unsafe parts. There is significant value in that compartmentalization. Moreover, you are assuming that things written unsafely in C should be written identically in rust, when there ve…

There are modern ways to express something safely that is written unsafely in C. What Rust evangelists seem to forget is that there have been ways to do that for a long time.

The article actually has very little safe Rust in it. It makes me wonder what we are gaining? If the idea is that introducing Rust means that later you can go back and add type and memory safety...why not use C++ in a type and safe by construction way? Why not use Safe D?

I'm personally just looking forward to the hype dying down. I'm tired of hearing about it, and most of the time I just click "hide" on Rust articles because I'm not interested and people are starting to sound pretty shrill.

Re: Rewrite Linux Kernel in Rust?

#124

Post by wtetzner »

FrozenVoid wrote: post #96
dbaupp wrote: post #91

Earlier quoted context omitted.

Rust has had backward compatibility since 1.0: https://blog.rust-lang.org/2014/10/30/Stability.html

Servo and most projects use nightly which breaks it all the time.

Servo might use nightly, but do you have evidence that most projects do? Especially after custom derive landed in stable, most of the reason for sticking with nightly dissappeared.

Re: Rewrite Linux Kernel in Rust?

#125

Post by rurban »

gorthol wrote: post #101
devdoomari wrote: post #61

Earlier quoted context omitted.

pardon my ignorance, but wasn't "safe-and-performant" impossible before rust? Isn't choosing a GC-language some trading off performance for safety?

I think it was "safe and performant without a GC" because both Nim and D have C++ level performance while being memory safe as any GCd language is.

You forgot about pony, which is memory safe plus concurrency safe plus faster than C/C++. Nim, D, Rust won't offer that. M# does because it followed the same principles.

Re: Rewrite Linux Kernel in Rust?

#126

Post by the_why_of_y »

FrozenVoid wrote: post #90

>Rewrite Linux Kernel in Rust? Rust has no backward compatibility: C code compiles fine after decades. It would be a waste of time to rewrite Linux in Rust when the resulting code has a lifetime of few months until it won't compile and start breaking everywhere.

> C code compiles fine after decades

... and then hilarity ensues at runtime due to latent UB that happened to "work" in the C implementation the original author used.

Re: Rewrite Linux Kernel in Rust?

#127

Post by Jach »

jholman wrote: post #117
Jach wrote: post #109

Earlier quoted context omitted.

It's a common misconception that GC languages must be slower than languages without one. Where that misconception probably comes from is that it's pretty easy to write performant code in C, and hard to write terribly slow code, whereas in languages with GC in some instances you can do as good or better but it's often harder. These days if you're comparing Java and C++, it's not unusual for the Java code to be faster.…

You mentioned the determinism tradeoff, which is one the gamedev community talks about endlessly. I'm no low-level expert, but my understanding is that determinism isn't all you lose. My understanding is that the big tradeoff is against RAM usage. You can have relatively-low-RAM-usage JVM programs, and you can have fast JVM programs, but you usually cannot have both. Keeping the total cost of GC low is done by amorti…

You're right that total memory can be a tradeoff since any GC will necessarily have some space overhead, the question is how much, and whether you can accept some time tradeoff in exchange for less space. So again it all really depends on the GC implementation (or implementations, e.g. standard Java can swap implementations too). Remember that Java was originally designed to run on embedded systems, Lisp has been used on very tiny hardware, and GC theory has been developing from at least the 60s. Memory is plentiful compared to those days.

My go-to reference when getting into GCs is http://gchandbook.org/ and it covers all this in the beginning. One old study tried a particular GC algorithm with Java and some various program benchmarks and found to match perfect manual allocation time (which will be better than in practice) you'll need about 5x the minimum memory, 3x gives you 17% overhead. I think anywhere from 1.5x to 3x is normal in practice since it depends on the application itself. There are tradeoffs everywhere and it's great Rust offers another one.

I thought JVM startup time was a dead horse. :) Sure native beats it, so does Python, but not by much these days.

Re: Rewrite Linux Kernel in Rust?

#128

Post by nickpsecurity »

delhanty wrote: post #119
nickpsecurity wrote: post #105

Earlier quoted context omitted.

"One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux" That's already hard given how many commits go into Linux. One must always remember it's not just some volunteer project: most of the commits are by paid programmers working at companies. That's where the labor comes from. You'd need a lot of volunteers to keep up with the paid programmers. Even Linux…

So we agree about something at least ;-) Slight tangent: I started my programming career in 1989. The product was Parasolid and the language was AGA - a C inspired language that preceded C++. I vaguely remember the following extensions: * built in logging with Undo * overloaded operators leading to vector and interval types that worked better than C++ * a proper module system

Interesting. Never heard of it. The main safe language from that time was Ada. It's been updated regularly. The neat thing about it is how it was systematically designed to mitigate errors in about every operation.

http://www.adacore.com/knowledge/technical-papers/safe-and-s...

There's also a variant called SPARK that can automatically prove the absence of errors like buffer overflow in a way that would normally take a theorem prover.

https://en.wikipedia.org/wiki/SPARK_(programming_language)

Re: Rewrite Linux Kernel in Rust?

#129

Post by pavement »

jholman wrote: post #118
pavement wrote: post #106

Earlier quoted context omitted.

It's a perfectly cromulent word, and embiggens every sentence and phrase that includes it.

Embiggens? I think the point of the word is to debigulate some sentences. I would say that it embetters phrases that include it; maybe that's what you meant.

Double plus good point.

Re: Rewrite Linux Kernel in Rust?

#130

Post by Retra »

youdontknowtho wrote: post #123
Retra wrote: post #102

Earlier quoted context omitted.

Safe rust clearly cannot express everything that can be expressed in C. It cannot even express everything that is safe in general. But "the safety features of Rust" includes drawing a barrier between the safe parts of your code and the unsafe parts. There is significant value in that compartmentalization. Moreover, you are assuming that things written unsafely in C should be written identically in rust, when there ve…

There are modern ways to express something safely that is written unsafely in C. What Rust evangelists seem to forget is that there have been ways to do that for a long time. The article actually has very little safe Rust in it. It makes me wonder what we are gaining? If the idea is that introducing Rust means that later you can go back and add type and memory safety...why not use C++ in a type and safe by constructi…

Have you ever written anything in Rust?
Post reply on HN