Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.
Is this true anymore or just a history note?
Re: Integrating "safe" languages into OpenBSD? (2017)
31–40 of 400 posts
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#32Rust is good at preventing memory leaks. It doesn't matter (as much) for a command line utility that runs for one second then exits. Of course, there are now utilities written in Rust. https://github.com/samuela/rustybox
I think Theo's reply was a bit excessive in some regards but I can also understand him being frustrated when you've been working on a very complex project for decades and somebody comes around and say "uh, why don't you rewrite it in ?". It's seldom a very interesting or constructive discussion. If you think Rust has something to bring to some project then you should at least take the time to write a decent proof of…
I don’t think Linux or bsd will ever be rewritten in rust nor should they. I do think eventually there will be an os written in rust that surpasses them in popularity, but probably on the time frame of decades.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#33I have been using bat and exa along with alacritty for a while. All of them are pretty good https://github.com/alacritty/alacritty https://github.com/sharkdp/bat https://github.com/ogham/exa
Throw in those, + fd[0] and rg[1]
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#34> 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…
The post was written in 2017. How far along was the project in 2017. Also, I am a bit confused about the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic. ? Which line in the e-mail stated that?
The gatekeeping is strongly implied by this statement:
> As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts.
Which I read in the tone of "go play with your toy language somewhere else, and let the real programmers program with real languages. Additionally, there's the allusions to the fact that the ls/grep-replacements in Haskell aren't POSIX-compliant, which I again read in the tone of "they can't be taken as serious replacement efforts."
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#35Earlier quoted context omitted.
No need to speculate, if you follow the GitHub link you'll see that the project is older than 2017.
How many utilities were rewritten and shipped at the time of the post?
79 by my count, but I'd be happy to have someone correct me.
https://github.com/uutils/coreutils/tree/ef4d09ee3c067c280ba...
It looks to me like the only changes in that table since November 2017 are that `join` and `df` were moved from 'todo' to 'semi-done'.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#36> 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…
BSD does not use GNU coreutils. Is it really unexpected that the developer of a BSD project might have been unaware at the time of a project attempting to replace it, or simply found it incompatible with the stated requirements-- POSIX compliant base utilities. OpenBSD does not care about compatibility with GNU, for example longopts do not work for many utilities, with exceptions to permissive replacements to historically used GNU utilities (grep example).
It also does not address the concerns of higher build times compared the contemporary C counterparts, which also support far more platforms than Rust.
The use of cargo for example suggests that at least a few uu utilities makes network connections at build time to fetch dependencies!
For example something as simple as chown:
https://github.com/uutils/coreutils/blob/master/src/uu/chown...
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#37> 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…
I think it's OK for platforms to have principles and if those principles are going to yield anything of value you have to be fairly consistent and ruthless about them.
There was a little bit of editorializing there but if 'base builds base' is table stakes then start working on that coreutils project first.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#38If 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.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#39> 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.
I've heard about this from the Guix context: https://guix.gnu.org/blog/2018/bootstrapping-rust/
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#40> 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…
> the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic.
He's not gatekeeping in that way by saying that Rust isn't used to create OS utilities (which as an aside is what he actually says. He doesn't say anything about building an OS) and therefore isn't a serious language and therefore shouldn't be included in OpenBSD*. He's saying it's not used for making OS utilities and therefore has no specific use in OpenBSD that requires it to be in the toolchain. Very different points with the latter being pretty reasonable, imo.