Hacker News Reader

Comment by praveenperera | Hacker News Reader

I've never seen the original introduction of Rust from Graydon Hoare before seeing the link in this post: http://venge.net/graydon/talks/intro-talk-2.pdf

The original vision for Rust sounds a lot like a typed Erlang without the BEAM.

View on HN

I started following it when he first started working on it back then, but I actually lost (some) interest once it became more about the memory safety features.

It's not that I don't think the borrow checker etc. stuff is really awesome. I just find the original concept very appealing and incremental. Essentially an OCaml for systems level programming.

A sane C++.

I feel like Rust is making its moves slowly into that territory, but that the memory safety pieces have made it more difficult, even if the long-term payoff is better.

All that said, I'd like a job programming in Rust

I'm just curious, feature-wise, what keeps OCaml from being an OCaml for systems level programming?

I'm sure for some uses it would be fine. But typically the concern is garbage collection. Manual memory allocation and the ability to deal directly with pointers etc. is important for driver and OS development, as well as embedded systems work.

OCaml is a GC language. It does have a fairly direct translation into assembly though, and is not a pure functional language.

The GC and the GIL.

The GIL is not problematic if one uses processes, not threads, for parallelism. And for system-level programming it may be even better long-term solution as one can sandbox child-processes.

But GC is really problematic.

1. Control of memory layout is a big one. Ocaml has a very lisp-like object representation except without a cons-cell special case. If you try to directly translate some ocaml to rust (and the types are ok), you will gain from having fewer pointer dereferences and likely more cache-friendly shallow data structures in the standard library. There are some plans to make the compiler better for layout control (look for “unboxed types”)

2. Parallelism. There is currently a python-like lock so that only one thread may run ocaml at a time. There is a long-running project (multicore) to fix this

3. (Opinionated) lack of control of mutability: it is easy to have everything immutable or an object with fields that are always mutable, but you can’t easily have something like rust’s mut, which only sometimes allows mutation. Some changes to this may come with/after algebraic effects which come after multicore, but these are mostly about avoiding atomically where possible rather than making things const.

4. The compiler just isn’t as good as a c++ compiler and it needs to be better to undo a deeper stack of abstractions. I think it’s particularly bad for not really doing monomorphisation. On the other hand, it’s fast.

5. (Opinionated) it isn’t great for writing generic code, but maybe modular implicits will fix that.

That said, it is possible to write fast systems level programs in ocaml (you can be careful and avoid allocation in critical sections, or just have gc because for most systems it doesn’t matter that much. You can split things into multiple processes if necessary.) You could look at mirage for an example of something big and low level written in ocaml.

Having taken a stab at getting into that language, I can tell you the package landscape is freakish. Either you get on the Jane Street Train, or you slum it with packages from 2003 that don't have support (and probably dont build anymore anyway) Good luck getting things working on Windows. Honestly even Haskell is a better choice in that language space even though its getting eaten by Rust (and for good reasons).

If you can stomach a GC enabled by default, a D is a good attempt at sane C++. The syntax is instantly familiar for a C++ programmer, and the templates are very similar to C++ (although saner).

I really feel like D is in a tough spot these days. In the early 2000 I remember being interested in it but I dismissed it because of the licensing issues that existed back then.

Now it's sorted out but I think it crippled the language early on and now it's sandwiched between other "managed" languages with far better adoption and better support on one side (Java/JVM languages, C#, Go) and low level system language with better adoption and no GC on the other (C++/Rust in particular).

While I personally find D interesting and vastly better designed than some of the competition (cough go cough) it's very hard for me to imagine it getting big in the mainstream without some massive industry backing.

Rust hasn't had a much bigger adoption until a while ago. It had a better open source presence perhaps, but not necessarily adoption. It changed now obviously.

I guess the question is, does it really need to be mainstream to be usable? As long as it works for the usecases you need it for, popularity isn't a necessary factor.

I have to say though that D has some issues that prevent it's wider adoption, both historical and current. Some are obvious, such as unnecessary two standard libraries conflict (I missed out on it, but the OOP person in me would have preferred Tango over Phobos).

Yeah agreed. While they're improving some of the usability around it, it is still a bit hard to understand.

But I think it is beating C++ at its own race. The C++ weirdness is just... Bureaucratic and verbose.

Rust is clunky at times but even then it is smoother than C++

C++ has massive adoption and billion of lines of codes in active use. IMO Rust is already superior syntax-wise in almost every area but C++ is going nowhere any time soon.

I'm sure some C++ codebases will outlive everybody posting in this thread.

Have you looked at Pony?(https://www.ponylang.io/)

Here's what Graydon Hoare had to say about it:

"It's very similar to earlier versions of rust. In terms of actor local GC, language provided scheduling of actors, separated function and async invocation system, mixed structural and nominal types, and an overabundance of language supported reference qualifiers. I think they did a good job at it, certainly much better than I did, but I'd be nervous about the cognitive load of the reference qualifiers (capabilities). See this page for example, or the previous few in the tutorial. We had that sort of cognitive load on variables early on and people basically rejected the language because of it, as well as associated compositionality problems. The many years of design iteration had a lot do to with factoring that space into fewer, more essential and general qualifiers. Slow, tedious, world breaking refactoring work. I hope for pony's sake this doesn't happen to them too -- it looks really nice -- but that's my biggest worry for it."

http://www.reddit.com/r/rust/comments/34rszb/pony_type_and_m...

Reply on news.ycombinator.com