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

Re: Integrating "safe" languages into OpenBSD? (2017)

marc.info

Post reply on HN
Print view View original

41–50 of 400 posts

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#41

Post by tomku »

yalogin wrote: post #27

> Rust cannot compile itself. This seems worth fixing. I think this is his main point. There is also the bigger question if and why the core utilities should be re-written in Rust. Given that safety is the main value proposition of rust it may be makes sense, but it’s a much bigger discussion.

The "on i386" part that you stripped out when quoting is actually the important bit. Rust does not care about having a self-hosting 32-bit x86 toolchain, while the lack of one is a deal-breaker for OpenBSD.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#42

Post by loup-vaillant »

skrebbel wrote: post #17
jcranmer wrote: post #8

> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

You make valid point, but you can't fault Theo for predicting a different future in 2017.

https://github.com/uutils/coreutils/commit/d4e96b33e34373399...

I read 2013, Theo de Raadt's email is from 2017, over 4 years later. I think we can fault him for being overconfident and not checking his facts.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#43

Post by otterley »

empath75 wrote: post #23
jeffbee wrote: post #16

Earlier quoted context omitted.

rg is great but it isn't a drop-in replacement for POSIX grep, which means even if you have rg you still need to ship another grep so all your existing scripts and programs that expect to be able to invoke POSIX grep don't break.

Yeah and there are multiple drop in replacements for grep— he was implying those alternatives didn’t exist because rust wasn’t capable of handling them or people weren’t interesting in writing them, but I think that’s been proven wrong many times over at this point. https://github.com/redox-os/extrautils/blob/master/src/bin/g...

Was this true in 2017, when the statement was written?

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#45

Post by asveikau »

jcranmer wrote: post #8

> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

Some substantive comments I read from the mail:

* It takes a long time for a rewrite to be fully compatible and a good implementation. This project says it uses the busybox tests and that seems like a good start. Is it good enough though? Busybox itself is quite good for certain embedded niches but it would be absurd to replace a good chunk of OpenBSD userland with that, the usability would suffer a lot.

* OpenBSD needs to compile itself, in reasonable time, and at the time of the writing rust was slower than C at this and could not self host on 32bit x86 due to address space limitations. Has it been fixed?

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#46

Post by anthk »

adamnemecek wrote: post #38

If you can write C as well as the OpenBSD people, be my guest, keep writing C. It might take you like 20 years to get somewhere interesting.

Like OpenSSH? PF? Clang? All of the modern compilers and languages made in C?

Maybe you can create something more widespread in Rust and not being a single part of a browser.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#47

Post by pjmlp »

jcranmer wrote: post #8

> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

Not only that, there are several POSIX implementations in Ada.

They just don't get exposure in FOSS land.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#48

Post by pjmlp »

skrebbel wrote: post #17
jcranmer wrote: post #8

> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

You make valid point, but you can't fault Theo for predicting a different future in 2017.

There are POSIX implementations in Ada since the mid-80's.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#49

Post by damnyou »

ryanlol wrote: post #30

So whats the point of rewriting coreutils in rust? If you’re passing attacker controlled inputs into grep you’re probably doing something wrong anyway. It doesn’t seem like there’s much to be gained here. Network facing software is where the big wins are.

Speed. It's normally trivial to parallelize your programs.

edit: rough crowd today. Check out Send, Sync, rayon and ripgrep.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#50

Post by lmilcin »

There's something to it, but I don't thing the future is as grim as that.

Rust is a stepping stone. It is a proof of concept that shows a lot of problems can be solved at compile time without adding huge bloat at runtime.

Yes, Rust has problems. Some of them are just because the language is new and you feel not yet fully built.

The compile times are more more insidious side effect of Rust's properties. I think, realistically, it will take some time but the problems will be resolved either in future Rust or in another language based on it. And it will be very worth the wait.

High level languages are fun and important, but it is not possible that all system code is going to be built in high level languages. As we run stuff that is more and more demanding of CPU we need a good low level language that will also tick some important checks of reliability.

Post reply on HN