>>6
Also a C ABI compatible compiled language really can't fail. The main reasons that popularity in a language is good is that:
- it brings more libraries (irrelevant because such a language can just use C libraries)
- it increases the install base of the runtime or interpreter (irrelevant; it can run anywhere gcc can (see gdc))
>>10
The type system is really good. I like ML's better but there is a tradeoff in this space. The closures aren't especially ruby-esque in any sense other than syntax.
>>16
WFM. If you really want to build it, try the release tarball. It eats about an hour of CPU time to build on a modern Intel so supply -j8 (or however many CPU threads you have) to make.
>>25
THEN WHY THE FUCK DID YOU MAKE THIS POST YOU IDIOTIC POMPOUS LOGICALLY INCONSISTENT LITTLE BITCH?
Name:
Anonymous2012-11-03 21:27
>>22
I think you're missing the part where Rust's type system is married to its memory model. You can't get ML's type system in Rust, and you don't have Rust's memory model in any 'ML that I'm aware of.
Name:
Anonymous2012-11-03 21:40
It eats about an hour of CPU time to build on a modern Intel so supply -j8 (or however many CPU threads you have) to make.
Good grief, I'm not looking forward to this language's creations finding itself in my ports tree. Building updates to things relying on boost is bad enough as it is.
>>28
Remain calm! It takes so long because the build process is not streamlined (it's built 3 times during compilation for bootstrapping and other reasons.)
There's talk of fixing the build time soon. I think someone said they had a build down to 8-12 minutes, which I believe is total CPU time. Not bad at all.
The only thing I'm seeing that isn't in ocaml is the syntax for owned and shared pointers, which is an abomination that ought to stay contained within C++. I see what you mean though. That complicates things a little bit. Although I don't see how it can't be solved with making all reference types implement a virtual destructor.
>>32
There's a lot of stuff you're missing then. But I'll give you this, if it weren't for the concurrency and C ABI there would be no need to go the Rust route, with the possible exception that it is familiar to C++ people (yet manages to get things right), and has better objects in a sense than OCaml does. Note, you can't produce a C-library in OCaml but the expectation is that you will be able to in Rust (no GC, no runtime at all.)
On a related note: JoCaml is an interesting language, but I don't envision it addressing my needs.
Note, you can't produce a C-library in OCaml but the expectation is that you will be able to in Rust (no GC, no runtime at all.)
That's nice. But I hope it doesn't require too many constructs in the language that encourage premature optimization. The compiler should determine if the program depends on a GC or not and this should be possible for any high level language, including ocaml. But whether or not that is provided is a matter of what implementations are out there.
Name:
Anonymous2012-11-04 1:02
I hope it doesn't require too many constructs in the language that encourage premature optimization
I try not to worry about problems until they become evident. Actually, it is a small problem in OCaml (eg. favouring arrays over lists for speed.)
In Rust's case you'll write allocations conservatively anyway. Being over-conservative is certainly not encouraged any more than using stack allocations exclusively is in C. However, I think I read something by one of the devs saying that allocations in the the core library are effectively considered bugs. The idea is you still have a library to depend on when you eschew the runtime. Say what you will, Rust has an impressive amount of forethought put into it and they're not afraid to experiment.
and this should be possible for any high level language, including ocaml
Not without changes to the memory model, in OCaml and probably most others too. Sure that's possible, but it in no way resembles the state of things. Not yet for Rust either, but they talk about it like they have every intention of doing it. I don't know if they intend to do it automatically, and I want to have a compiler flag to enforce it.
:= is a superior assignment operator. It removes the hackish need for "==" to mean equality like we're all used to from math. Plus this also allows the potential to make ``backwards assignment'' like so:
Sorry, I didn't mean to say anything negative about rust, and I'm excited about it. I guess the first responses where about the lack of global type inference. But honestly it's a lot of work and it's debatable if that is even a good feature to have in a language.
However, I think I read something by one of the devs saying that allocations in the the core library are effectively considered bugs.
I wish I worked there.
Not without changes to the memory model
It's possible if a large set of hard optimizations are used to determine the relative life times of objects. Ideally, they should all function with no hints provided in the language. In order for to optimizations to really be effective, the life time calculation would need to be aware of the entire program at once. It might be possible to make this scale, but it would be hard. I don't know of any projects going for something like this (other than rust), but if it could exist without hints it could be applied to all high level garbage collected languages.