Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

91–100 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#91
post #3

Earlier quoted context omitted.

That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

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

I think it is important for us to think more on the resources, for programs we write consume, when: they are compiling, they are executing and when they are just "dormant" on persistent memory. Experience and history shows that the bigger the program is, the more resources it needs to function, the more bugs it has, which consequently makes it more difficult to debug and prone to failure.

Re: Integrating “safe” languages into OpenBSD?

#92
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…

Rust's first compilers were written with OCaml. We don't provide bootstrapping from C because no C-based toolchain has ever existed. However, it may in the future; see my link upthread.

[deleted]

Re: Integrating “safe” languages into OpenBSD?

#93

Earlier quoted context omitted.

> This seems like a bit of a trite point unless many rust developers are actually working inside i386. Though the compiler itself might not work very well in i386. Trite point? OpenBSD supports 1386[1] if they pull a rust compiler into base and start rewriting things in rust, then they can't support 1386. Dropping a supported platform is not a "trite point". [1]: https://www.openbsd.org/plat.html

At this point i386 is legacy for most of the world. OpenBSD is an ultra-conservative, orthodox project, therefore they will probably support i386 for years into the future - I mean, they supported VAX until 2016. That is a choice they are entitled to make, the trade-off being it would appear to make most modern technologies a poor fit for adoption in OpenBSD - that's the price they have to pay. It is a problem of the…

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

Re: Integrating “safe” languages into OpenBSD?

#94
post #74
post #44

A bit incendiary: I fail to see what advantage rewriting existing and proven tools with a new language would bring. Shouldn't the main value new tools bring to be enable writing of new things? Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value?

> I fail to see what advantage rewriting existing and proven tools with a new language would bring. This is not the first rewrite, and won't be the last one. Earlier environments were very memory-constrained, which led to optimizing for memory usage; a rewrite with less memory constraints can focus on speed (as mentioned in the GNU coding standards: "For example, Unix utilities were generally optimized to minimize me…

> The current challenge is the "end of Moore's law" leading to an increasing use of multiple cores, instead of faster cores. Developers will have to focus on parallelism instead of raw speed, and new languages can help.

Moore's law is indeed nearing its end, but this also ends the multiple core trend.

If you're betting on multiple CPU cores taking off more than they did already, don't.

Re: Integrating “safe” languages into OpenBSD?

#96

Earlier quoted context omitted.

Considering the complete lack of viable competition in the space, that day is a long way off.

Why is Redox not viable competition?

I feel like you should add a disclosure about being the creator of Redox.

Re: Integrating “safe” languages into OpenBSD?

#97
post #82
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.

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

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

Unless you are talking about an architecture which doesn't have llvm backend, it takes the same effort as nim to port rust and haskell.

> Did they write the first compilers with Assembler?

Rust was written in Ocaml first, bootstrapping from C need decent amount of effort. I don't know the origins of haskell.

Re: Integrating “safe” languages into OpenBSD?

#98

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.

Really? I'm pretty sure for most game companies, shipping is king and everything else is secondary.

Also, have you seen gameplay footage of in-development titles, particularly older ones before the days of Unity and UE4? Usually they're choppy as hell because the engine is under development at the same time as the game, and devs prioritize getting a golden but slow codepath working first so that the artists have something to go off of, and all the optimizations are shoved in to recover framerate in the months right before release.

Re: Integrating “safe” languages into OpenBSD?

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

Apparently Redox developers disagree :) https://github.com/redox-os/coreutils

These are even based on BSD coreutils.

Re: Integrating “safe” languages into OpenBSD?

#100

Earlier quoted context omitted.

Are you implying that Rust isn't performant?

If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.

Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.
Post reply on HN