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

Integrating “safe” languages into OpenBSD?

marc.info

Post reply on HN
Print view View original

171–180 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#171

Post by simias »

lifty wrote: post #130
simias wrote: post #53

Earlier quoted context omitted.

Come on, I really like Rust but these types of comments are why people like Theo de Raadt don't take the evangelists seriously. You can't take a project like OpenBSD that has existed for more than 20 years, is being used right now to power all kinds of applications around the world on all kinds of architectures and say that Redox, an experimental x86-64 OS, is viable competition. What with the seven applications writ…

I love this. I think both of you are right, but your perspectives are for different time frames, with one side having an ideal view about a future time frame, while the other thinking about the now. This is the kind of situation that leads to innovation and how projects like Linux or neovim started. It's a natural way to progress. I hope jackpot51 gets pissed off and takes redox to the point where it proves the naysa…

I really hope that redox will eventually become a competitor to OpenBSD and other flagship OSs, I'd love to work on a Rust OS. That being said I still don't think it makes sense to label it a competitor at this stage though.

If I decided to start practicing Formula One next week that won't automatically make me competition for Lewis Hamilton. Redox has some way to go before people can seriously consider using it over OpenBSD for real world applications.

Re: Integrating “safe” languages into OpenBSD?

#172

Post by masklinn »

npsimons wrote: post #155
masklinn wrote: post #40

Earlier quoted context omitted.

> 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.

> I'm actually gobsmacked this is the case.

So gobsmacked you apparently couldn't even begin to attempt answering the question but felt you just had to go on a rant as irrelevant as you believe it's righteous, uh?

> 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.

Rust has been self-hosted for almost as long as it's existed. The boostrapping OCaml compiler was left behind back in 2011.

Re: Integrating “safe” languages into OpenBSD?

#173

Post by _jal »

reggieband wrote: post #116

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…

There is a sort of social game that seems to emerge at some point, combining the worst of in-group bullshit and logic-puzzlng as a substitute for actually attempting to help folks honestly seeking questions.

The game goes like this: start discussing something: say, including rust in OpenBSD.

- Assume it (here, using rust in oBSD) is a great idea.

- For each objection, explain why it is trivial. Your tools are your own reasoning and knowledge of programming, the ability to ignore, minimize or belittle any and all reasons why things are the way they are, assuming away any legacy issues, and remembering that all needs and use-cases in the world exactly match yours.

- When you get bored, just walk away. It isn't your problem, after all, and you were just trying to help. High-fiving your cohort optional.

It ends up simultaneously coming off as arrogant and clueless. Last time I had a small problem and the time to try something new, I started it in rust. After getting a series of jackass responses to a simple question[1], I wrote it in C, because I just don't care enough to put up with twits fluffing their own ego at the expense of newbies.

This problem is hardly unique to rust - unfortunately it happens everywhere nerds gather. But rust has a really bad case of it.

[1] Found the answer a few days later when I thought of a better search term.

Re: Integrating “safe” languages into OpenBSD?

#174

Post by steveklabnik »

_jal wrote: post #173
reggieband wrote: post #116

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…

There is a sort of social game that seems to emerge at some point, combining the worst of in-group bullshit and logic-puzzlng as a substitute for actually attempting to help folks honestly seeking questions. The game goes like this: start discussing something: say, including rust in OpenBSD. - Assume it (here, using rust in oBSD) is a great idea. - For each objection, explain why it is trivial. Your tools are your ow…

Where was this? If it was in an official Rust forum, we don't allow "jackass responses", and I'd like to take care of it.

Re: Integrating “safe” languages into OpenBSD?

#175

Post by blub »

sgift wrote: post #147
simias wrote: post #128

Earlier quoted context omitted.

I agree. It makes the community looks childish and inexperienced by association. I think I recall reading somewhere on Rust's website that telling project maintainers to switch to Rust was frowned upon, however I can't find it right now. Sometimes I feel like it should be written in a 20pt font on the home page. Or maybe written in blinking letters every time you run rustup. I always feel it's very presumptuous and s…

People have told me for the longest time that Java is a shitty language I shouldn't be using. Most of those people said C++ would be a far better idea without even bothering to show any reason why C++ would be more suited besides "Java is slow, huahuaha, it is shitty, huahahaha". So, I have to admit I take a bit of a pleasure of seeing those people getting challenged on their presumption that C++ is the greatest lang…

The Java community is a poor example to make your point, since it's always been vicious and obnoxious in relation to C++. It was partly built on tearing down C++.

The reaction of some parts of the Java community to Hypertable choosing C++ instead of Java was nothing short of embarrassing for instance, but it's not just that, over the years I have seen too many examples to list :)

Re: Integrating “safe” languages into OpenBSD?

#176

Post by masklinn »

liveoneggs wrote: post #170
masklinn wrote: post #141

Earlier quoted context omitted.

GHC is still C-boostrap-able. That's literally the only reason why the C backend still exists: > The C code generator is only supported when GHC is built in unregisterised mode, a mode where GHC produces 'portable' C code as output to facilitate porting GHC itself to a new platform.

so GHC can generate C code to bootstrap GHC?

GHC can compile GHC (or Haskell in general) to C, the main use case being bootstrapping GHC without cross-compilation, as the latter has historically been lacking:

> Support for cross-compilation works reasonably well in 7.8.1. Previous versions had various issues which are usually work-aroundable.

(7.8.1 was released in 2014, GHC itself is 25 years old)

Re: Integrating “safe” languages into OpenBSD?

#177

Post by JdeBP »

Paianni wrote: post #104
kps wrote: post #93

Earlier quoted context omitted.

“i386” is OpenBSD's label for the 32-bit Intel architecture (they don't actually support the 80386). Intel still sells these.

They support 486's though, which is quite rare for 2017.

There's a 32-bit x86 processor in every PC with the Intel Management Engine version 11 or later.

Re: Integrating “safe” languages into OpenBSD?

#178

Post by nickpsecurity »

nanolith wrote: post #161

I have spent a long time using alternative languages. I'm a compiler geek. However, most of these languages ultimately lead to disappointment. Not because they necessarily fail, but rather because the problem of writing software is not a problem of language or platform. It is a problem of thought and abstraction. So, the big promises that these new languages and platforms make will ultimately only be fulfilled for a…

You're missing high-level languages such as Modula-2 or Free Pascal that are safe-by-default while being close to the machine. They compile faster. They're easier to analyze. Someone who understands C could easily port it to one of these languages or even write a translator that converts them to C for easy integration of incrementally-rewritten pieces of the OS. They don't because they like C for non-technical reasons or want to do one piece of tooling work over another.

Another you might find interesting in alternate history where C programmers adopt better tech is Cyclone that tried to stick to C as much as possible. Rust's safety scheme took a lot of inspiration from Cyclone.

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

http://trevorjim.com/unfrozen-cyclone/

" There are excellent model checkers out there for C, and quite a few proof assistants are gaining the ability to check proofs on C code directly"

I agree. Further, just using Design-by-Contract with property-based and fuzz testing on those contracts would improve things by itself. There was also an academic who applied Frama-C to one of their smallest, battle-tested components in I think a string library. Although no coding flaw found, the exercise did show the documentation was incorrect. Gotta wonder what benefit might happen for less obvious stuff than string operations.

Re: Integrating “safe” languages into OpenBSD?

#179

Post by ghostly_s »

joshklein wrote: post #120
SCHiM wrote: post #15

The points made against switching to newer languages are valid. It will cost time, it will cost effort, it will take many years of work to convince stubborn maintainers to switch. But it will not stop _everyone_ from adopting better languages, and their efforts will eventually surpass the older, less secure systems. When there's feature parity, each and every new exploit will be called out: "this wouldn't have happen…

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…

> The system being secure is a secondary benefit to it being comprehendible and coherent to an individual.

This is a really interesting and compelling philosophy to me, but it’s the first time I’ve heard OpenBSD described this way! Why is this not mentioned on the project’s homepage?

Re: Integrating “safe” languages into OpenBSD?

#180

Post by MageSlayer »

steveklabnik wrote: post #168
MageSlayer wrote: post #164

Earlier quoted context omitted.

Agree. Moreover, Rust compiler contains some dark areas which nobody wants to deal with. See https://github.com/rust-lang/rust/issues/38528 for example. Basically it means that Rust compiler can suddenly take exponential time and space for compilation. That bug really bites hard any code heavy on iterators (Rust often praised feature!). It has reliable reproduce test-case, but still it's already year old and was down…

I mean, that thread has a comment less than a day ago, and Niko says: > I'm going to lower this from P-high to reflect reality. I'm still eager to investigate but haven't had time, and making it P-high is not helping =) P-high means someone is actively assigned and working on it, so yeah in some sense this is a down-prioritization, but only from "Someone is working on this, so put your work somewhere else" to "this i…

Well, yes. The last comment says the issue is still there :) I mean this bug alone in fact nullify the entire incremental compilation effort. It's kind of weird.

> The de-prioritization may lead to it getting fixed sooner, as Niko is a busy guy

And Niko put "medium" priority month ago :)

Post reply on HN