Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

221–230 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#221

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…

On the other hand part of the complaint in the main article is the lack of basic core utils at a standard that OpenBSD would consider. Or things that could be a base world dependency for them.

Re: Integrating “safe” languages into OpenBSD?

#222
post #12

Earlier quoted context omitted.

>Such ecosystems come with incredible costs. For instance, rust cannot >even compile itself on i386 at present time because it exhausts the >address space. Is cargo supported on i386 platforms? Also Rust complies itself, afaik there is no way to compile Rust/Cargo but to use previous version of it. If one of the past builds of Rust is backdoored, any version between then and now is backdoored, language is safe, envir…

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…

Travis is running containers, so even if you use a i686 rustc, you still benefit from a 64-bits kernel, meaning processes still have the full 4GB of address space. On an actual i386 linux kernel, this would be limited to 3GB. Maybe it's even less on openbsd (I don't know, but technically, it could be as low as 2GB). That could explain why it works for you and not for them.

Re: Integrating “safe” languages into OpenBSD?

#223
post #221

Earlier quoted context omitted.

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…

On the other hand part of the complaint in the main article is the lack of basic core utils at a standard that OpenBSD would consider. Or things that could be a base world dependency for them.

But that ties into what I'm saying - trying to 'oxidise' a system written in C that already works.

Re: Integrating “safe” languages into OpenBSD?

#224

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…

Travis is running containers, so even if you use a i686 rustc, you still benefit from a 64-bits kernel, meaning processes still have the full 4GB of address space. On an actual i386 linux kernel, this would be limited to 3GB. Maybe it's even less on openbsd (I don't know, but technically, it could be as low as 2GB). That could explain why it works for you and not for them.

Ah, right. Thanks.

I still thought that we generally kept it down to around 2GB of space, but maybe that's wrong.

Re: Integrating “safe” languages into OpenBSD?

#225

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…

Your comic is a really poor analogy. /r/programming is not your house. You are saying you want to be able to publicly denigrate other people, and have those people be prohibited from responding publicly. That's nothing like someone showing up in your house to correct you.

Re: Integrating “safe” languages into OpenBSD?

#226

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.

Fast compilation: less than a second (feels like not waiting at all)

Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time)

To have fast compilation even with big projects is hard. Go, C, and D are usually fast. Scala is usually slow.

I care about development builds primarily. The edit-compile-test loop must be really really fast. Optimization flags are irrelevant, because if performance matters you often must have them enabled for development as well.

Re: Integrating “safe” languages into OpenBSD?

#227

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…

>He's worried about compile times? Fix the compiler.

If it were that simple, the compiler wouldn't be slow in the first place. Rustc and ghc have both been too slow to be usable their entire lives. There doesn't seem to be any reason to believe they can be made fast enough to consider using.

Re: Integrating “safe” languages into OpenBSD?

#228
post #219

Earlier quoted context omitted.

How is Maven (or Gradle, but I prefer Maven) bad? I've never used npm, but I quite like Maven's use of XML for defining project dependencies etc. with clear structure.

I have very little experience with Maven, but I find it hard to understand and restricting. Maybe I should take the time to learn the fundamentals properly and maybe I would be enlightened, but it seems to work very different to other build tools. Example "Lifecycles" [0]. The documentation says "Maven is based around the central concept of a build lifecycle. What this means is that the process for building and distr…

Spot on. As a Java developer, i've bounced around between Maven, Gradle, and ad-hoc shell scripts (and Ant back in the day!), and just cannot understand how so many people still think Maven is any good. It's not the XML - that's a superficial annoyance. It's the elaborate but extremely rigid model of what a project is and what a build is, that makes even the smallest deviation from a completely vanilla project excruciatingly painful.

Gradle has all sorts of failings, and is overly complex in its own way, but at least it gets the meta-model right: provide fundamental tools for building a graph of tasks with dependencies between them, and ship a set of hopefully useful tasks built on top of that.

Re: Integrating “safe” languages into OpenBSD?

#229
post #175
post #147

Earlier quoted context omitted.

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 :)

The C++ world hasn't exactly been kind to Java either. The two languages have the kind of vitriolic contempt for each other that only siblings could have.

Re: Integrating “safe” languages into OpenBSD?

#230
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?

So does Theo. Base is where the core of the OS that's used to build everything (including base itself) lives. People are more than welcome to have Rust, Go, Java, Erlang, or whatever in the ports tree. There's no reason those are needed in base because they don't build what's in base now. If parts of base required one of those languages to build, that would be an argument for including that language.

It ends up being a bit chicken and egg, right? Don't put a language into base because base doesn't use it. Packages in base can't use it because the compiler's not in base. So effectively someone needs to recreate enough core tools in base in the new language that it's worthwhile pulling in the language tools themselves. And then one must justify any compiler performance and platform limitations before the PR is approved, too, potentially solving those upstream in the language community.

It's a major undertaking, and people keep asking why someone else doesn't do the work. That's why Theo wants people to show progress on code before asking for the tools to be put into base.

Post reply on HN