Live data from Hacker News

Re: Integrating "safe" languages into OpenBSD? (2017)

marc.info

101–110 of 400 posts

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#101
post #8

> 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. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

There is no gatekeeping. To actually achieve POSIX-compliance is not an easy task and requires lots of testing. If you don't do it then your replacement will break everyone's scripts. A distro maintainer will also want to retain compatibility with their supported GNU/BSD extensions so that's more work to add on. I would still agree with his statement at least as far as BSD is concerned. Outside of Redox I haven't see…

Rust dependencies are just compilation units. Do people complain when a coreutils-scale project ultimately depends on 400 .c (and/or .o) files?

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#102
post #94

Earlier quoted context omitted.

Bizarre that he thinks a language or compiler is doomed unless it can compile itself on each platform it supports. Microcontrollers and cross-compilation wouldn't exist if that were the case.

I think it was more the implication that requiring more than 2GB of RAM to compile itself was an indication of its profligate resource usage.

How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#103
It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution.

Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go's primary use case), or a company that only cares about a single massive binary containing the OS itself (the browser), but it stops "being cool" very quickly on a typical *nix system if you plan to have hundreds of rust tools lying around.

Size _matters_ once you have a few thousands binaries on your system (mine has short of 6k), think about the memory requirements of caching vs cold-starting each, and running those and how patching for bug or vulnerabilities will pan out. There's a reason dynamic linkage was introduced and it's _still_ worth it today.

And rebuilding isn't cheap in storage requirements either: a typical cargo package will require a few hundred megabytes of storage, likely for _each_ rebuild.

Two days ago I rebuilt the seemingly innocuous weechat-discord: the build tree takes about 850mb on disk, with a resulting binary of 30mb. By comparison, the latest emacs binary from git rebuilds in a 1/10 of the time with all the features enabled, the build tree weights 150mb (most of which are lisp sources+elc) with a results in a binary of 9mb, not stripped.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#104

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement or judgment on Rust. At most there's an interesting point on it's value proposition: > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 1…

Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact loc…

Agreed on a hundred thousand.

I used to feel sheepish defending npm and the whole node package ecosystem against its critics, but once I started trying to run deep learning applications or WebRTC media servers I quickly realized that some of the critics are probably coming from a much worse package management system that they’ve merely grown familiar with.

Want to have two pieces of software on one computer that rely on... idk, two different versions of libwebsockets? Yeah, you’ll need either docker/overlayfs, or some filesystem or pkgconfig hack that I’m sure a comment reply will helpfully mention if you want two have to versions of a library installed for two different executables.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#106
post #102
post #94

Earlier quoted context omitted.

I think it was more the implication that requiring more than 2GB of RAM to compile itself was an indication of its profligate resource usage.

How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.

Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#107
post #8

> 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. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

He's a maintainer, gatekeeping is literally his job. He's the one who decides what makes it in or not.

His reply is not great, but IMO posting to some venerable old project's ML saying, in the abstract and without actually having made any effort to analyze the issue in depth "Under what conditions would you consider replacing one of the current C implementations with an implementation written in another, "safer" language?" comes off as rather rude and not very productive IMO. I can understand him shutting it down immediately instead of wasting his time arguing with programming 101 students who cargo cult Rust without understanding the reality of maintaining something as complex as OpenBSD.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#108

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement or judgment on Rust. At most there's an interesting point on it's value proposition: > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 1…

I like bat more than cat, not because it’s memory safe, but because it’s benefiting from the entire Rust ecosystem and provides features I enjoy that cat does not have. It’s not always security, but that’s always a plus (though I have no idea if bat is any more secure than cat). I can make the same statement about exa and many of the other tools that are getting better in the Rust suite of CLI tools.

Indeed, I came here to say that I’ve replaced many such standard tools with more functional equivalents which happen to be written using Rust - bat, git-delta etc.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#109
post #69

Earlier quoted context omitted.

This is pretty much a judgment of Rust: Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Consider me a skeptic -- I think these compiler ecosystems face a grim bloaty future. I would think that OpenBSD developers/users would care about security, since that's pretty much the value-proposition of OpenBSD.

Bizarre that he thinks a language or compiler is doomed unless it can compile itself on each platform it supports. Microcontrollers and cross-compilation wouldn't exist if that were the case.

Well OpenBSD has this "dumb" rule that snapshots/releases are never cross compiled and be done on real hardware. So it's pretty much a rule that every hardware platform has to be self hosting.

Microcontrollers are the exception, but then they don't run a full blown OpenBSD stack anyways.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#110
post #75

"For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space." I don't want to be harsh, but who the hell is compiling anything on i386 now? Real question, is anyone even making fresh i386 hardware that might be used by consumers, or deployed in datacentres?

OpenBSD is. Just because you can't think of a use case doesn't mean they don't exist.
Post reply on HN