
The Rust programming language - arman0
http://lambda-the-ultimate.org/node/4009
======
chipsy
Rust sounds very promising in a lot of ways. It has a whole host of useful
compiler technologies that we've known about for a long time, yet have not
applied to industry languages.

~~~
Xavi
I agree, TypeState seems especially interesting. This paper from one of the
comments does a good job describing it:
[http://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestat...](http://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestate.pdf)

------
stevejohnson
All the pages about it at this link and at its project page give me zero help
in figuring out if it's something I want to use, because none of the pages
show any syntax whatsoever.

This is like the flat feature lists of the smartphone wars that matter exactly
not-at-all.

~~~
neilk
Be careful not to ascribe your own narrative onto this. They're not calling
you to the site because they want you to use it or buy into it. It's a
progress report / unveiling of an experimental project.

The primary author (Graydon Hoare) is IMO a frickin' genius, but even so he is
at pains to reduce expectations for Rust at this time. So, go easy on Rust for
now.

------
__bjoernd
Google came out with Go some months ago, now Mozilla presents Rust. Both
languages seem to be targetted at the same audience, I fear it's mere
corporate politics that prevent both from using the same language, isn't it?

Addon-question, don't know if it fits: Has Google's Go gained publicity apart
from having a vibrant community on Google's mailing list?

~~~
alnayyir
>I fear it's mere corporate politics that prevent both from using the same
language, isn't it?

If anyone is guilty of NIH, it's Google. Google didn't use LLVM, didn't follow
the example of some more thorough and less facile concurrency models, didn't
exercise the necessary discipline re: mutable data structures, and didn't
appear to have been keeping up with any lang research that has gone on since
the 90s.

Whereas

Rust is made by a known language implementor, the impetus of the project was
not in fact Mozilla's motives (they're merely supporting it after the fact),
and it targets LLVM with the bootstrapping OCaml->RS implementation.

So by all means, explain to me why the non-gcc implementation (6g, 8g) for
Google Go not being LLVM somehow isn't classic NIH.

With Go, Google based the language design upon what they'd _like_ (Python with
coroutines for systems programming), rather than actual research, restraint,
or even using the existing best of class tools for implementation.

Edit:

>Has Google's Go gained publicity apart from having a vibrant community on
Google's mailing list?

It got some mentioned on various tech news streams, nothing mainstream or
substantial. I've seen (very) occasional posts on YC News of little toy
projects in Go, but again, nothing I'd really notice or care about.

I'd say Node.js has gotten a much faster start than Go, and don't give me any
guff about JavaScript being older, it doesn't matter, server-side js hadn't
been done properly before Ryan Dahl.

~~~
kaib
> So by all means, explain to me why the non-gcc implementation (6g, 8g) for
> Google Go not being LLVM somehow isn't classic NIH.

Disclaimer: I know a bit about the background to the choice, I wasn't involved
but I've seen the consequences having worked with the 5g arm compiler.

The code generation part of 5g/5l is on the order of 10k lines of C, the whole
8g/6g/5g compiler suite is ~115k. I don't know how to break down LLVM but the
whole project looks like ~270k lines of C++ so the code generation is probably
more than 10k.

Now imagine you are tasked with writing a compiler for an experimental
language where one of the key features is blazingly fast compilation. The
plan9 compilers are fast, you wrote them yourself so you know their strengths
and weaknesses. The plan9 compilers are also reasonably small and written in C
which you know well.

You know nothing about LLVM. It could be good but it would take some time to
find out. You also don't know too much C++ and it would take some time to get
up to speed.

I would be very interested in understanding why this is NIH as opposed to
reasonable management of risk?

~~~
alnayyir
>where one of the key features is blazingly fast compilation

Oh come on. That's one of the banal [excuses|priorities] I've ever heard. I
was aware of it, I just couldn't believe someone would invoke it with a
straight face.

>I would be very interested in understanding why this is NIH as opposed to
reasonable management of risk?

When you ignore the prime project that has the most labor, most corporate
support and funding, the most data, and the most documentation as a competitor
to gcc, _and_ it's BSD licensed, _and_ it's perfectly available for
compilation/testing to see if it's appropriate to your needs...

...that's classic NIH.

You've outlined basic FUD fueled by lack of knowledge of the alternatives.
Management of risk? The code is BSD licensed, _spare me_! If you want to take
the code and run off with it in the sunset, you're perfectly able to do so.
Instead of at least re-using/borrowing code from LLVM, they decided to embark
on a rather laborious and difficult aspect of language development themselves
with zero input from other projects.

The cognitive dissonance required to believe that when you reach that kind of
decision-chain, that what you're doing is anything other than pride/fear/NIH
must be immense.

I understand that Google has a fetish for the academic/open source elite in
their hiring practices, but that doesn't get them a wholesale license to chuck
common sense out the window and disregard the work of all others.

ARM compatibility, gee, that does make depending on other compiler
infrastructures tricky since you can't trust anyone to support anything other
than x8---- wait a tick.

"An easily retargettable code generator, which currently supports X86, X86-64,
PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, PIC16 MIPS, MSP430,
SystemZ, and XCore."

\--- <http://llvm.org/Features.html>

I'm not buyin' what you're selling. Was I involved in the production of Go?
No, but I've been tracking it since it was publicized and unless there's some
detail/issue/licensing matter/temporal rift involved that I'm made aware of,
I'm just not going to swallow the notion that it was anything other than NIH
muddled by incomplete information.

~~~
kaib
> If you want to take the code and run off with it in the sunset, you're
> perfectly able to do so. Instead of at least re-using/borrowing code from
> LLVM, they decided to embark on a rather laborious and difficult aspect of
> language development themselves with zero input from other projects.

I think there are two separate concerns, both which I'm disagreeing with you
on. First, my understanding is that when ken wrote the initial compilers he
wanted to focus on the frontend and re-use a backend. So he picked the plan9
compilers which he knew well (they predate LLVM by 10 years and he mostly
wrote them). There was very little original work going into the code
generation.

Second, I think you are grossly underestimating the initial cost of
integrating with an open source project unkown to someone. The first Go
compiler frontend was written in a few weeks or months. I'm guessing that
having to pick up a new unknown backend (LLVM) and language (C++) would have
set the project back enough to make it miss it's window of opportunity.

It seems to me that your argument is that an incorrect _choice_ was made in
what to re-use. That seems like a very different thing than NIH.

> ARM compatibility

ARM compatibility had nothing to do with the decision to re-use the plan9
compilers. I'm a compiler neophyte and when I wanted to add ARM support to Go
it was an easy choice to go with the existing framework (there was a solid
plan9 C compiler for ARM). If I had tried to port the system to LLVM at the
same time as adding ARM support my skills would probably have failed me.

> fast compilation

One of the distinctive features of the optimizers ken wrote for plan9 C, which
are used in Go, is that they are much simpler and faster than normal
optimizers but produce less optimal code. The GCC Go compilers are slower and
slightly less comprehensive but produce code of higher quality. LLVM would
undoubtedly produce better code as well. I'm happy to go into more technical
detail if you want to, it would help if you'd let me know how much practical
compiler writing experience you have?

------
rnicholson
From the PDF:

 _Rust is a curly-brace, block-structured statement language. It visually
resembles the C language family, but differs significantly in syntactic and
semantic details._

I'm not a programming language buff, but why curly-braces and C-style still in
2010?

~~~
makmanalp
What exactly is about curly braces that implies outdatedness? Because some
other old languages use it?

~~~
jamesbritt
Or the reverse: RPG and FORTRAN had it, so in what way is significant white
space a marker of modernity?

~~~
riffraff
ditto for begin/end

------
StrawberryFrog
Why rust? does it never Sleep();

------
kunjaan
Why is Dave Herman called one of the "heroes-to-the-Internet"?

~~~
mbrubeck
The LtU crowd knows Dave Herman from his academic PLT work and his
standardization work on EcmaScript. I believe he also is or was a contributing
editor on LtU.

<http://www.ccs.neu.edu/home/dherman/>

------
TheSmoke
What Rust has that the D programming language doesn't have?

~~~
grogers
In rust there is no global mutable state. All mutable state is local to a
process. This means that GC happens per task (similar to erlang) instead of
per process. This emphasizes safety over performance. You can still drop into
C to get back to your shared mutable state if you want.

That being said, looking over some of the core features, D seemed very similar
in spirit.

------
adamilardi
Please no more languages world!

~~~
adamilardi
Thank you for the downmods.

~~~
gnuvince
The reason you were downmodded is because there is a _lot_ of research that's
been available for years and hasn't been tried in practice. New languages that
try new features and new avenues may or may not end up being used, but
sometimes they influence later (or existing) languages. New languages are a
good thing, embrace them.

