Hacker News Reader

Given the Mesa/Cedar system a Xerox PARC, Oberon at Swiss Federal Institute of Technology and Modula-3/SPIN at Olivetti, doing OS work in GC enabled systems programming languages is quite possible.

The problem is how to move OS vendors away from C's influence.

Use micro-kernels.

Exo-kernels might be a better alternative.

https://en.wikipedia.org/wiki/Exokernel

It is a matter of willingness, not technology.

> Still I agree with you that it is very likely that Rust will follow a parabolic trajectory. The advantages as perceived by the industry compared with C++11/14 will be too few.

Rust is memory- and type-safe (as in: the compiler will not let you write a dangling reference, invalidate an iterator, or write exception-unsafe code without opting into an unsafe dialect). The security benefits alone of that are enough to justify the language for our use cases, and, from what we've seen, for many others. Safe zero-cost abstractions are a niche to its own.

Facebook have deep pockets ... Yep, Facebook is using D for some stuff.

A large or well-known company merely using a programming language, and maybe even contributing back to it and its community, isn't the same as the company truly supporting or championing it.

What you describe is very different from, say, how Sun pushed Java, or Microsoft pushed C#, or how Apple will likely push Swift, or how a huge portion of the entire software industry pushed C and C++.

Facebook's Hack language is probably a much better example than D is of a language that they're actively supporting. It's a creation of theirs, rather than just a creation of somebody else's that they find useful in some limited cases.

>At the same time it [Rust] does not have the ecosystem

Try watching new projects pop up at Rust CI [0] for a few days. With the possible exception of Node (which is not even a PL), I've never seen a language ecosystem grow this vast, and I'm a PL afficionado.

I think in a year's time, the question of Rust's stability and ecosystem will be entirely moot. It's a tough wait meanwhile, but I'm still investing the time in learning Rust (and it's a significant investment).

0. http://www.rust-ci.org/projects/

Is Rust CI really the best evidence to use in this case?

When I last looked at it, probably 40% to 50% of the projects listed had builds that were in the "failing" or "error" statuses.

That indicates that one or more of at least a few things are happening:

1. The Rust language and its standard libraries are changing at a pace that results in previously-compiling code needing to be modified before it will compile again with a newer version of the language/implementation, perhaps a very short time after the code was initially written.

2. The Rust compiler or other tooling is crashing or failing in some way while compiling these projects.

3. The projects themselves aren't being maintained on an ongoing basis.

4. The projects themselves were never building properly in the first place.

5. The projects' developers are targeting different versions of Rust (which probably means there will be interoperability problems for anyone trying to use them in a larger projects, especially when it comes to libraries).

And while there may be a lot of these projects, I've never found the quality to be very good. Many of them are extremely limited or incomplete. Many of them are little more than casual experimentation. Many of them are only developed by a single person, who often has appeared to have lost interest.

Those factors are disconcerting, especially for somebody who wants to use Rust for serious product development. It does no good if there are hundreds of libraries available for use, but half of them don't even build, and the ones that do are very incomplete.

>Many of them are extremely limited or incomplete. Many of them are little more than casual experimentation. Many of them are only developed by a single person, who often has appeared to have lost interest.

Yes, I completely agree, and this is an entirely normal part of the language ecosystem development cycle. Rust is at the tail end of the experimentation stage, and as it converges on 1.0, more people will undertake serious projects.

I'm not at all worried about the quality of Rust projects. I'm just happy to see so much enthusiasm. I have no doubt that all this enthusiasm will transfer into some powerful libraries as Rust continues to stabilize and reaches 1.0.

But yes, it's still to early to use Rust for production unless you're willing and able to write your own libraries.

Then again, the "batteries included" approach of Rust's standard library leaves not much to be desired outside of domain-specific libraries.

I would also say that D did itself irreparable harm with the whole v1-v2 standard library debacle. Right when it was receiving the most attention, it came right out and said to anyone who might have considered it, "we have two incompatible versions of the standard library: one which we don't support anymore and one you can't use yet."

That was then and this is now, there is one standard library and the language has come on leaps and bounds. D is a great language.

I'm not arguing otherwise. But as the saying goes, you only get one chance to make a first impression, and D's first impression was of a train wreck.

Yeah, that certainly hurt D's reputation. People still bring it up even though it's been resolved for years.

Could you be specific about what in D isn't useable without the GC? You can use manual memory management in D. It has Unique (unique_ptr) and RefCounted (shared_ptr). It has Array. It has malloc and free. None of these use the GC.

People complain about the GC being available to use while simultaneously complaining that to avoid it you have to manage your memory yourself. You can't have it both ways. There is no memory allocation strategy that works best in every situation. Sometimes ref counting is best, sometimes stack allocation, sometimes RAII, sometimes memory pools, sometimes its the GC.

Rust has done some cool work with memory but even it doesn't free the programmer from having to consider and choose which memory allocation/ownership option is going to deliver the best performance on a case-by-case basis.

You're right about Rust and Go having much deeper pockets. D isn't backed by any corporation. It's 100% a community project. Maybe it won't ever gain a significant market share because of this. I don't know.

It took python (which also doesn't have a deep-pocketed company backing it) about 15-20 years before it saw widespread adoption.