Comment by masklinn | Hacker News Reader

Comment by masklinn | Hacker News Reader

Parent Full thread

Wasn't bitc trying to do some of that stuff?

An other option you might want to look into is Rust[0], especially since the language is still in its early days (0.1) and the developers are more than willing to fix things which don't work.

* It does not have bit fields or bounds-checked arrays (which it calls vectors) at this point I think

* A bit of GC: it has a reference-counted pointer type, which is task-local, which might be possible not to use at all (not sure) if you don't want it. It also has unique pointers (reclaimed when they vanish out of use) and stack allocation.

* HoF, unicode-native strings (although they're char vectors so maybe not ideal), pointers cleanups (and more than one pointer type which you may or may not agree with), "tasks" ("green processes"), absolutely trivial C interop (so you should be able to easily use pthreads I think), structurally typed records, tuple types, lots of pattern-matching love (for dispatching and unpacking), explicit mutability marker

[0] http://www.rust-lang.org/

We're working on improvements to the language (namely, regions and dynamic arenas) to make it possible to not use the reference-counted pointer type at all if you don't want it, while retaining the type safety. Regions have their own set of costs, as we're finding out (mostly due to the annotation burden if you start doing complicated stuff), but I think we'll be in a nice sweet spot. Rust gives you three basic options:

(1) Regions, when you want safe, low-overhead allocation. The downside is a more complex type system. (Usually you don't see the complexity unless you're returning pointers that contain references to the stack, at which point you have to convince the typechecker that you aren't creating dangling pointers by doing so.)

(2) Safe, garbage collected heap allocation. This gives you maximum flexibility at the cost of runtime overhead.

(3) Unsafe pointers. This lets you manage your memory manually, like C++. Of course, this is unsafe.

Also, I suspect we're going to add fixed-length vectors; we've been discussing this quite a bit lately and I think there's general consensus that they should be present in the language in some form.

Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust:

Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java.

I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for making it an excellent language for a database.

The non-optional runtime overhead that I have to imagine is endemic to the purported feature-set would seem to be a non-starter for systems (kernel, driver, embedded) programming.

Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.

> I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven.

Yeah that's about what I'd expect considering the language's goals.

> Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.

Rust has the `unsafe` escape hatch for this, unsafe blocks can do whatever the hell they want and are "unsafe function" and "unsafe pointer" types which are known to bypass Rust's safety mechanism and can only be used in unsafe blocks.

Then it might work out fine, I don't know.

In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete.

If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established priorities of safety and concurrency.

I'm not saying Rust will "fail" like Go seems to be doing so far, I'm just saying I don't think they're going to prioritize making Rust useful for driver development[1].

[1] Which I think is brilliant anyway. It's solving a very hard problem that needs solved.

Your hunch is correct, Rust's developers have stated that Rust isn't aiming to be a language with which to implement kernels or device drivers.[1]

It's interesting to see that the domain of "systems" programming languages appears to be splitting into "kernel-level" domains and "perfomance-critical application-level" domains. In this light, it seems more like C++ is the one caught straddling the gap. Should be interesting to watch this space for the next decade or so.

[1] https://github.com/mozilla/rust/wiki/Doc-project-FAQ

I'm not saying Rust will "fail" like Go seems to be doing so far

I think it's way too early to tell if Go is failing or not; it was announced less than three years ago. How successful was, e.g. , Ruby in '98?

Go isn't failing. It's actually doing quite well. I disagree with the design and implementation of almost every part of the language, but credit where credit is due: Google has created a language that a lot of people like.

So we basically use the runtime for three things: (a) the task system, which features lightweight threads like Go or Erlang; (b) stack checks and growth; (c) garbage collection. We used to use it for more, but lately more and more stuff has been moved out of the runtime to be written in Rust itself.

I'd like to see a "runtime-less Rust" myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.

If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help.

Reply on news.ycombinator.com