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

141–150 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#141

Post by masklinn »

liveoneggs wrote: post #112
progman wrote: post #82

Earlier quoted context omitted.

> go needs go, haskell needs haskell, rust needs rust That's painful. It's one big point which Nim [1] does better. It compiles to C and bootstraps from C. That makes porting to other platforms much easier. I don't understand why Haskell and Rust don't provide bootstrapping from C. Did they write the first compilers with Assembler? > You just don't notice it because these two languages are already part of the base sy…

haskell was C-bootstrap-able many versions ago, but you need the previous version to build the next from that point forward so it's quite a dance. There is also no effort to maintain the "old" version as a strict "bootstrap" since everyone just has binaries of the previous version lying around. :)

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.

Re: Integrating “safe” languages into OpenBSD?

#142

Post by emidln »

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.

486s and 586s are still sold for usage as embedded systems. They are well understood and some of them managed to pass certification decades ago.

Re: Integrating “safe” languages into OpenBSD?

#143

Post by rbehrends »

cesarb wrote: post #51
liveoneggs wrote: post #47

The bootstrap problem is real and getting worse: go needs go, haskell needs haskell, rust needs rust; it's nasty. There are already "better" and "safer" languages that could easily replace the entire unix userland. Heck, awk can do half of it, but all of that C code is already written...

> 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 newest software installed. Oh, and this also sometimes means restricted internet access.

So, bootstrapping matters to me, and the bootstrapping story for anything involving LLVM isn't very good (I'm actually having some problems with a language other than Rust in this regard).

Interpreters you can generally build fairly easily from source (Lua, Ruby, Python, Tcl, for example). But when it comes to compilers, bootstrapping is generally a much bigger obstacle. 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:

* OCaml bootstraps from C via a bytecode interpreter, which is then used to build the native compiler. On my laptop (using four cores), I can actually do that in under a minute (two minutes if I want flambda).

* Nim compiles to C and hence builds in half a minute on the same machine from C sources.

* LuaJIT builds in a few seconds, assuming a dynamically typed language with a JIT compiler is sufficient for you.

Re: Integrating “safe” languages into OpenBSD?

#145

Post by progman »

microtonal wrote: post #129
progman wrote: post #90

Earlier quoted context omitted.

> I fail to see what advantage rewriting existing and proven tools with a new language would bring I think code safety is not an issue here because the Posix tools (and Unix/Linux as a whole) have already proven their extreme reliability. The only real advantage to rewrite the Posix tools is motivation. A rewrite in a modern language like Rust will likely keep maintainance longer alive than old C code that no one lik…

There is basically no technical reason to replace the X server which works very well to this day. There is, the architecture is not made with the modern-day world in mind: an X11 application can read all keystrokes, mouse event, and do screen grabs of other windows. An X11 application can emulate your screen locker to grab your credentials. X11 does not support different scaling on different monitors that are connect…

> an X11 application can read all keystrokes

I like that because I use key desktop macros heavily.

> and do screen grabs of other windows.

I like that since it enables me to make screen shots of any application.

> X11 does not support different scaling on different monitors that are connected to your computer.

I use two monitors with different resolutions, one horizontal, and one in portrait mode. They work perfectly, also with virtual screens. What you possibly mean is that X doesn't support that by default. Nevertheless, it's possible if the graphics vendor provides appropriate drivers.

Re: Integrating “safe” languages into OpenBSD?

#146

Post by steveklabnik »

simias wrote: post #128
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…

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…

To be clear, you can take it from me: yes, don't go tell people to re-write things in Rust. Agree 100% that it's presumptuous and disrespectful.

At the same time, I don't see it actually happening as much as people say that it happens. Maybe I just don't see those things. If I did, I'd tell them to cut it out.

Re: Integrating “safe” languages into OpenBSD?

#147

Post by sgift »

simias wrote: post #128
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…

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 language on earth.

Language advocacy is far older than Rust. And many language advocates are far more obnoxious than what I read on HN with regard to Rust. I actually have the feeling that the C++ crowd is just a bit sad that the usual defense of "well, yeah, other languages do those things better, but the code they produce is far too slow for our problem, so they're useless!" doesn't cut it anymore.

Re: Integrating “safe” languages into OpenBSD?

#148

Post by mfukar »

mcguire wrote: post #110
mfukar wrote: post #78

Earlier quoted context omitted.

go-coreutils is abandoned, and not POSIX compliant. It was meant to be a proof-of-concept, and it kind of was, in a negative way.

What was the problem?

I have no idea. I have been watching 5-6 similar Go projects (some with the same name) which lost interest (some stopped after first commit), tried to create their own versions of coreutils (incompatible), never saw adoption, testing, or support, and they all tanked.

Re: Integrating “safe” languages into OpenBSD?

#149

Post by cat199 »

AtticusTheGreat wrote: post #144

It would be interesting to try to cobble together a Linux distribution with a rust userland, using coreutils ( https://github.com/uutils/coreutils ) and over time building more and more of the userland/interface in rust.

whyy couldn't they pick a different name for this project?

rustutils? coreutils-rust?

name collision like this is how we have millions of people running around thinking that vim is vi while they bash emacs for having bloat as compared to the 'minimalism' of 'vi'..

Re: Integrating “safe” languages into OpenBSD?

#150

Post by steveklabnik »

HelloNurse wrote: post #135
steveklabnik wrote: post #76

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.

Rustc is more than just a Rust program; we compile LLVM from scratch, for example. Is the OOM in the Rust code, or in the LLVM code, or in the final linking, or what? It's not clear.

The compiler is one of the largest Rust programs that exist. Last I checked, it was three quarters of a million lines of Rust, but a quick loc shows 1.5 million lines of Rust, 2.3 million lines of C++, and 900,000 lines of C (again, mostly LLVM and jemalloc).

Servo is also very large, and they don't report having OOMs, though I'm not sure if they build on 32-bit or just cross-compile.

Post reply on HN