Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

151–160 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#151
post #51

Earlier quoted context omitted.

> go needs go, haskell needs haskell, rust needs rust And C needs C, or for more recent compilers, C++ needs C++. You just don't notice it because these two languages are already part of the base system.

But a C compiler is part of basically every Unix system. That matters. For example, one of the perks of my job is that I do occasionally get to play with real nice hardware (such as a Cray with a couple thousand nodes at one point). The downside of that is that the owners won't give me root access and because there are lots of other people working with it, stability of the system is more important than getting the ne…

> There are a few notable exceptions that only require a C compiler, no internet access during their build, and build in an acceptably short time:

most any scheme/lisp compiler as well

requiring internet access and binary bootstrap toolkits thing for the core piece of an ecosystem (e.g. the language compiler) is decidedly new-school, rooted in overly commercial projects, and for the worst, imho.

ps: lawn.

Re: Integrating “safe” languages into OpenBSD?

#152

Earlier quoted context omitted.

I think this misunderstands the OpenBSD philosophy. The more likely it is "everyone else" disagrees, the more likely it is Theo is choosing the right course for the project. The system being secure is a secondary benefit to it being comprehendible and coherent to an individual. It's not enough for the output of a magic box to be a better widget, even if the widget is better in every measurable way. The box itself mus…

"But I'm not brilliant, and I don't have a lot of energy, and so I'm also grateful there exists an operating system I can understand, and other people who continue to work to make that operating system useful." Writing correct, efficient C takes more years to master than people take to learn Rust that I've seen. Also, the C compiler and many other parts of OpenBSD are black boxes to their developers. Your worries app…

My impression is that the Rust developers and community are firmly in the practical camp. They will keep plowing at Rust and its ecosystem. They will improve and optimize every nook and cranny they can find.

I wouldn't be too worried about Rust, it will have a niche at least as big as Ruby's is and IMO it will be way more entrenched since its target domain moves way slower and the barriers to entry are way higher than for scripting languages and web frameworks, IMO.

Re: Integrating “safe” languages into OpenBSD?

#153

Theo is completely ignorant here. I also saw him spout similar inaccuracies in this video: https://youtu.be/fYgG0ds2_UQ?t=2112 Uutils and Redox are setting out to provide POSIX compatible coreutils, and Redox builds from scratch in less than 30 minutes.

> Theo is completely ignorant here.

perhaps, in one sense - or, alternatively is busy not spending all his time chasing the latest 5000 fads and 100000 not-yet-implemented projects which may or may not ever end up being completed...

Re: Integrating “safe” languages into OpenBSD?

#154

Earlier quoted context omitted.

The performance of the compiled code is great, and the performance of the compiler is something they have identified as a major issue to fix, and are working to solve it.

So did the now-dead game companies. Performance is like money: it's easy to squander and hard to acquire.

> Performance is like money: it's easy to squander and hard to acquire.

In this case, there were several decisions to not care about performance right now in order to emphasize correctness and shipping faster, while making sure there are no technical obstacles to making compilation faster in the future. The main time sink in Rust compilation is that all the abstractions in the Rust code get compiled into the initial bytecode representation passed to the LLVM side, and they are only reduced there, instead of cutting down on the hierarchies on the Rust side. This costs performance in several places -- the creation of all the bytecode, the copying of it, and then LLVM parsing it all in. The upside of doing it this way is that it makes the Rust-specific compiler much simpler and easier to implement, and that the optimizations that remove the towers of abstraction on the LLVM side are extremely well tested.

As Rust matures, optimizations that reduce the complexity of the created initial LLVM bytecode can be, and probably will be done on the Rust side.

Re: Integrating “safe” languages into OpenBSD?

#155

Earlier quoted context omitted.

He has a point though... As we get more CPU/ram we as programmers don't even bother to check how many resources we are using. Personally, I don't know whether its a good thing or a bad thing. Also in terms of systems languages I believe only rust has some potential to truly replace C. Although, a large part of C usage still takes place in the embedded world where rust has yet to be ported to many embedded processors.…

> He has a point though… Does he? He "stat[es as] fact" that > There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. which as xwvvvvwx notes is categorically wrong, then points out that rustc can't compile itself on i386, which is relevant… how?

> then points out that rustc can't compile itself on i386, which is relevant… how?

I'm actually gobsmacked this is the case. There used to be a saying, only half-joking, that a language that can't host/compile/bootstrap itself is nothing more than a toy. As others have more eloquently pointed out, it shouldn't have to be explained why people who write operating systems and compilers would consider that a no-go.

Re: Integrating “safe” languages into OpenBSD?

#156
post #88
post #51

Earlier quoted context omitted.

> go needs go, haskell needs haskell, rust needs rust And C needs C, or for more recent compilers, C++ needs C++. You just don't notice it because these two languages are already part of the base system.

C has a large advantage: you can write a compiler in machine language (not assembly, raw machine language) in a week. Not a good compiler: it will produce horrid, unoptimized code. You just need enough to build a good C compiler. From there you can build a c++ compiler, which in turn can build the C++ compiler you want. Every time you add a new language feature you increase them time to write your bootstrapping compi…

> large advantage

How is this a large advantage? When was the last time someone actually did this?

Re: Integrating “safe” languages into OpenBSD?

#157
post #151

Earlier quoted context omitted.

But a C compiler is part of basically every Unix system. That matters. For example, one of the perks of my job is that I do occasionally get to play with real nice hardware (such as a Cray with a couple thousand nodes at one point). The downside of that is that the owners won't give me root access and because there are lots of other people working with it, stability of the system is more important than getting the ne…

> There are a few notable exceptions that only require a C compiler, no internet access during their build, and build in an acceptably short time: most any scheme/lisp compiler as well requiring internet access and binary bootstrap toolkits thing for the core piece of an ecosystem (e.g. the language compiler) is decidedly new-school, rooted in overly commercial projects, and for the worst, imho. ps: lawn.

To be clear, rustc and Rust projects generally do not require the internet to build. It's a hard requirement of many projects, like Debian or Firefox.

Re: Integrating “safe” languages into OpenBSD?

#158
post #46

Earlier quoted context omitted.

He's talking specifically about OpenBSD base. Unless you can point to a rust binary in OpenBSD that Theo forgot about, he's not wrong. i386 is relevant because OpenBSD supports i386.

> He's talking specifically about OpenBSD base. No, he is very explicitly saying that > There has been no attempt […] provide replacements for base POSIX utilities. Which once again is categorically false, a github repository purporting to do exactly that has been provided. > i386 is relevant because OpenBSD supports i386. i386 is supported, the issue is compiling the compiler on i386 .

> i386 is supported, the issue is compiling the compiler on i386.

which is required for the system to be self hosting

seriously - what is being said is this:

" oh hey lets throw away the functional and perfectly good entire base set of utilities for this 1/2 complete project on github using a language that doesn't even natively build on all of our supported platforms and wouldn't even remove the need for a C compliler in base, and further complicate the base toolchain, not to mention breaking all kinds of other builds which use shell utilities expecting certain behavior, etc ,etc, etc, because somone thought it would be 'neat' to do this. And whyyyy aren't you taking me serously??? "

every few days (hours?) some noobish person desides to ask some fantasy question about whatever topic of interest they are noobing about on openbsd (and other OS) discussion lists, and then gets whiny when they are being called out for being 'green' about life itself. this is another of those cases, and I have no idea why it got crossposted here or upvoted.

Re: Integrating “safe” languages into OpenBSD?

#159

I remember I stopped frequenting /r/programming when it became this weird Haskell echo chamber. It was a bubble where a small but vocal faction inside the community seemed to over react to any criticism. They methodically and tirelessly responded to every comment with an endless litany of "facts" showing how Haskell could do anything from os kernels to game programming. They touted every industry mention of Haskell u…

I just want to say that that comic is absolutely wonderful. Made my morning :)

Re: Integrating “safe” languages into OpenBSD?

#160

Earlier quoted context omitted.

Okay, there's a lot of misunderstandings here. Theo is right about some things, and wrong about some things. And people are misunderstanding what things he's right about. The things he's wrong about are very minor. Rust absolutely works on 32-bit platforms, though we often use the i686 target rather than an i386 one. Platform support list is here: https://forge.rust-lang.org/platform-support.html Theo is talking abou…

If compilation of rustc runs out of memory it represent an upper limit on the complexity of actually viable Rust programs, and given how much software is larger than a compiler it is a discouraging performance level.

True, but we're talking about 32 bit systems. Chrome stopped being able to compile on 32 bit systems years ago, as a C++ programs. I think Firefox is in the same situations.

It does sound kind of bad for Rust, but the competition isn't doing much better :p (weak excuse, I know)

Post reply on HN