Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

311–320 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#311
post #309

Earlier quoted context omitted.

It does not. I think your parent must have been doing something strange; if you have a *const T, one that's null will still be a Some. It's &T, which cannot be null by definition, that uses the null value as None, since it cannot be null.

I was actually using mut/ const and got this bug, I don't think I used &T since I was handling raw memory addresses.

Hm, then I don't know what happened, as I just checked and it's definitely not doing the optimization, as it shouldn't!

If you can reproduce you should file a bug.

Re: Integrating “safe” languages into OpenBSD?

#312
post #309

Earlier quoted context omitted.

I was actually using mut/ const and got this bug, I don't think I used &T since I was handling raw memory addresses.

Hm, then I don't know what happened, as I just checked and it's definitely not doing the optimization, as it shouldn't! If you can reproduce you should file a bug.

It might help to know that I was writing an UEFI application, so basically kernel mode.

Otherwise, I've redesigned the affected subsystem so I'm not sure I could reproduce the behaviour

Re: Integrating “safe” languages into OpenBSD?

#313
post #31
post #5

Earlier quoted context omitted.

People are still using i386? I'd assume even if they are, it's such a tiny minority that it shouldn't be an excuse to hold everyone else back.

OpenBSD supports a wide variety of hardware platforms, including machines with Alpha, PA-RISC, and SPARC64 processors. On each of them, the base system is able to compile itself. If rustc cannot even build itself on i386, what kind of support can we expect for other platforms with an even smaller user base? On a project such as OpenBSD they cannot suddenly drop platforms and only support amd64 as portability is one o…

> OpenBSD supports a wide variety of hardware platforms, including machines with Alpha

Can confirm, spent many happy hours hacking on an AlphaStation running OpenBSD!

Re: Integrating “safe” languages into OpenBSD?

#314

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…

One thing proggit has over HN is there's much less political discussion. I find the constant political debates and drivebys here incredibly tiring. Only about one-third the links on the frontpage here of any interest to me as a 'hacker'.

I have to agree. There seems to be more and more political/economic discussions here with which most of the posts seem to be from another planet. The more non-technical the discussions, the more strongly and obnoxiously held the positions seem to be.

Re: Integrating “safe” languages into OpenBSD?

#315

Earlier quoted context omitted.

> I don't think anyone is arguing that we should throw everything out, however for all my greenfield stuff Rust has been a welcome breath of fresh air. If you can write things from scratch in a clear room fashion, perhaps. C++ is very good, when you need to integrate a lot of 'low-level' libraries (that are alredy in C or C++) together in a meaninful way, like for instance, browsers do. Like the capacity to 'talk' wi…

I mean this in the most non-confrontational way: have you actually used/looked at Rust? The reason I ask is just about every item you laid out I've had the opposite experience. Talking with C/C++ is trivial with bindgen and clang. Embedding in C++ is likewise straightforward. I mean Firefox is one of the larger C++ codebases out there. The package manager is great and makes dropping in things much less painful. On th…

I have used Rust occasionally on weekend projects.

Rust toolchain still fails support on mixed mode debugging.

With C++, I can have a mixed .NET, JS and C++ solution and without problems debug and single step across all languages, regardless of targeting desktop, server or UWP.

Similar applies to Java or Android tooling.

Additionally if one is into native desktop coding, bindings to Gtk and Qt are still work in progress, and there isn't nothing that would match something like Blend.

Finally, the borrow checker still hinders some programming patterns that are quite common on GUI code, a few of them will be tackled with NLL.

Ah, and cargo does not support binary libraries although rustc can handle them, which is an issue for companies selling libraries.

I am aware all these issues will be eventually fixed, it is just as I see the situation currently.

Re: Integrating “safe” languages into OpenBSD?

#316
post #240
post #88

Earlier quoted context omitted.

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…

That so called advantage is how Niklaus Wirth did all his compilers, and many other language designers, it is not unique to C.

I didn't mean to imply it was unique to C, though in hindsight I did. This can be done in many languages.

I believe that Niklaus Wirth created his first self hosting implementation in a small subset of the language and expanded from there. Anyone thinking about doing this for a non-trivial language should consider following that example.

Re: Integrating “safe” languages into OpenBSD?

#317
The problem "safe" languages have in this context is that they really truly are no better than C, for the simple sake of them throwing out performance and resource considerations from the get-go. Additionally, if you take even just a day to read up on UNIX and C history, you'd quickly find the two are essentially intertwined, and that to usurp C, you'd have to nix UNIX, too.

I've yet to see anyone with serious industry experience come out and say sane things about replacing C. It's just not going to happen. Not in my lifetime, unless someone decides to write a new operating system, and Linux subsequently loses footing.

Re: Integrating “safe” languages into OpenBSD?

#318
post #243

Earlier quoted context omitted.

As for the point about how nobody is working on replacements, that's wrong. There's (partial) replacements for most coreutils written in rust, and a whole kernel has been under active development for years now. I acknowledge the strong pull to go and re-implement existing standards like POSIX in a new language like Rust. But, having had to again deal with all the corner cases of signal handling and threads for a Linu…

I find your post quite funny in the context of the topic..

I totally respect (and have donated to) the OpenBSD project, and ran it for years for my firewall machines. Though these days I'm running containerized Linux firewalls for ease of upgrades. Anyway...

I do understand OBSD's objections to using a new implementation language for their core utilities. And I understand their philosophy for what they're doing and how they're doing it in the general case.

But the fact remains that POSIX, as it has evolved (or not, in some cases) makes writing correct programs harder than necessary. Especially modern multi-threaded programs.

I'd like to see something better and simpler. And maybe written in something other than C.

Re: Integrating “safe” languages into OpenBSD?

#319

Earlier quoted context omitted.

It's become clear to me that a lot of the Rust fanatics don't actually know how C++ works and and Rust is their first low-level language. The ones I'm talking about know enough to make them sound like they know what they're talking about unless you actually know what they're trying and failing to accurately describe. It sounds and seems like a language worthy of more investigation on my part, but I have to agree that…

It sounds and seems like a language worthy of more investigation on my part, but I have to agree that the militant, presumptive attacks on any language besides their Chosen One has left a bad taste in my mouth. This 100 times over. It's a language that seems novel and strong enough to stand on its own merits - but there's a section of the community that makes me want to stay away. I wish they'd spend less effort re-w…

> I wish they'd spend less effort re-writing already working tools in C and more effort writing new, better tools.

Is this really a thing? Folks keep pointing out this bugbear of folks going out and asking projects to rewrite in Rust and ... there aren't that many examples of this.

If anything most of the more famous Rust projects (ripgrep, redox, etc) are clean-slate.

Re: Integrating “safe” languages into OpenBSD?

#320

Earlier quoted context omitted.

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.

What languages do you come from? What is fast compilation for you? The compilation phase can take hours in C++. Up to a day when compiling huge projects will all the optimization flags. Live that for some time and it will quickly prove you that you were wrong. Compilation time matters.

I don’t think people are saying compilation doesn’t matter. Certainly, I would consider C++ to be a language that is at the high performance end of the spectrum. High performance languages, high level languages like C++, Rust, Ada, Haskell, Ocaml, And Swift have relatively long compile times but I would classify them as languages suitable for applications requiring high performance. Go is an interesting exception in that it produces pretty high performance results without long compile times.

But you do have a point. Things are so much better now than when I started programming 50 years ago. Machines and languages are so much better. Programming is a dream compared to back then.

Post reply on HN