Linked by Thom Holwerda on Mon 23rd Jan 2012 22:10 UTC
General Development "Today Mozilla and the Rust community are releasing version 0.1 of the Rust compiler and associated tools. Rust is a strongly-typed systems programming language with a focus on memory safety and concurrency. This is the initial release of the compiler after a multi-year development cycle focusing on self-hosting, implementation of major features, and solidifying the syntax. Version 0.1 should be considered an alpha release, suitable for early adopters and language enthusiasts. It's nifty, but it will still eat your laundry."
Order by: Score:
Very Promising
by Rooki on Mon 23rd Jan 2012 23:02 UTC
Rooki
Member since:
2011-05-12

It's like they've taken all the good bits from Haskell and thrown them into a C-like language making them not hurt your (my) brain so much. The new interfaces they've added is especially cool.

See http://doc.rust-lang.org/doc/tutorial.html for a overview of the language.

Edit: Also the fact that the authors are dogfooding the language by writing the compiler in it speaks volumes to me.

Edited 2012-01-23 23:07 UTC

Reply Score: 4

RE: Very Promising
by shmerl on Mon 23rd Jan 2012 23:26 UTC in reply to "Very Promising"
shmerl Member since:
2010-06-08

Interesting, they are using generics as well. Unlike Java which ignored it until later, which resulted in convoluted and limited generics design and implementation.

Reply Score: 2

RE: Very Promising
by kragil on Tue 24th Jan 2012 18:23 UTC in reply to "Very Promising"
kragil Member since:
2006-01-04

Agreed.
At first I thought that Go is everything Rust is, but when you take a closer look you see that they both serve different purposes.
Go is a full on relaunch of what a systems language should be and do, while Rust seems to be a migration target for C++ projects and programmers. If they really eventually write parts of Firefox in Rust it could earn its laurels and prove that it is production ready. And it might even pick up steam.
You need lighthouse/beacon projects that can propel a language into mainstream. You also need a major backing. Mozilla (like Google) can provide that. (Crack, Clay, D etc will have a much harder time convincing people)

I personally really wish Qt would get something more modern than C++, GTK has Vala, but for Qt it is either slow Python or hard-to-learn C++.

Side note, OSnews is a great website, because here people see the potential in new technologies. On Slashdot everybody seems to act like whining little bitch each time something new comes along that might encompass change.(OSnews has those too, but they aren't the majority it seems)

Edited 2012-01-24 18:25 UTC

Reply Score: 3

RE[2]: Very Promising
by Alfman on Tue 24th Jan 2012 19:25 UTC in reply to "RE: Very Promising"
Alfman Member since:
2011-01-28

kragil,

"You need lighthouse/beacon projects that can propel a language into mainstream. You also need a major backing."

I agree one needs major backing to push a new language into the mainstream. These days, the modern language market is so crowded & fragmented, with no compelling advantages over the other, that they all hurt each other's chances at displacing the incumbent languages regardless of merit. I think this is the main reason why older languages have lasted so long in spite of being rough around the edges and falling behind feature-wise.


"On Slashdot everybody seems to act like whining little bitch each time something new comes along that might encompass change.(OSnews has those too, but they aren't the majority it seems)"

At the risk of being so labeled, we are often subjected to technologies that are merely superficially new without contributing anything substantial to the state of the art.

I would like to see new languages becoming unified to gain momentum and overtake older languages, but I'm not counting on that happening.

Reply Score: 3

RE[2]: Very Promising
by renox on Wed 25th Jan 2012 11:29 UTC in reply to "RE: Very Promising"
renox Member since:
2005-07-06

I personally really wish Qt would get something more modern than C++, GTK has Vala, but for Qt it is either slow Python or hard-to-learn C++.


There are quite a few other bindings such as QtAda.
Now, the question is how good are these bindings?
I don't know..

Reply Score: 2

RE[3]: Very Promising
by shmerl on Wed 25th Jan 2012 16:42 UTC in reply to "RE[2]: Very Promising"
shmerl Member since:
2010-06-08

It would be very interesting, if something like Qt Rust would emerge.

Reply Score: 2

Design document...?
by pepper on Tue 24th Jan 2012 00:21 UTC
pepper
Member since:
2007-09-18

Where is the design document? Do they have any goal and/or justification of features? It seems like an attempt for a modern "safe C", which in itself is not so bad. But then why not Go?

Reply Score: 3

RE: Design document...?
by shmerl on Tue 24th Jan 2012 00:37 UTC in reply to "Design document...?"
shmerl Member since:
2010-06-08

Here is a good talk about it:
http://www.aminutewithbrendan.com/pages/20101206

Rust was actually started before Go, so the question "why not Go" isn't really correct.

Edited 2012-01-24 00:39 UTC

Reply Score: 3

RE[2]: Design document...?
by gan17 on Tue 24th Jan 2012 01:52 UTC in reply to "RE: Design document...?"
gan17 Member since:
2008-06-03


Thanks for sharing this.

Reply Score: 1

RE: Design document...?
by moondevil on Tue 24th Jan 2012 18:00 UTC in reply to "Design document...?"
moondevil Member since:
2005-07-08

... But then why not Go?


Because Rust appeared in 2006 and as such is older than Go.

Second because Go in its current form is too simple, leaving behind decades of computer science research, along with features that most mainstream languages offer.

Anyway I find difficult to introduce new systems programming languages as long as an OS vendor does not pick them up.

For the business application development area there are already many languages available, reducing system programming languages to the use cases where close interaction with the OS and hardware is required.

Unless new systems programming languages get somehow a spotlight in a specific OS, they will never replace existing ones.

I am still hoping that it will happen though.

Reply Score: 3

on the heels of clay
by bnolsen on Tue 24th Jan 2012 03:42 UTC
bnolsen
Member since:
2006-01-06

Last week clay announced version .1 as well. In my opinion it's a much better systems language. rust has to compete with 'd' and 'go' and all other garbage collected languages.

Reply Score: 3

RE: on the heels of clay
by l3v1 on Tue 24th Jan 2012 08:59 UTC in reply to "on the heels of clay"
l3v1 Member since:
2005-07-06

From what I saw, rust isn't garbage collected.

Reply Score: 3

RE[2]: on the heels of clay
by shmerl on Tue 24th Jan 2012 15:36 UTC in reply to "RE: on the heels of clay"
shmerl Member since:
2010-06-08

Garbage collection is optional there.

Reply Score: 3

RE[3]: on the heels of clay
by bnolsen on Tue 24th Jan 2012 23:56 UTC in reply to "RE[2]: on the heels of clay"
bnolsen Member since:
2006-01-06

Rust does do include garbage collection. it's just that reference counting is "preferred" (clay only supplies explicit reference count semantics).

Reply Score: 2

Yet another system programming language
by viton on Tue 24th Jan 2012 08:51 UTC
viton
Member since:
2005-08-09

http://lambda-the-ultimate.org/deca

The Deca programming language is "a language designed to provide the advanced features of sophisticated, high-level programming languages while still programming as close as possible to the bare metal. It brings in the functional, object-oriented, and generic programming paradigms without requiring a garbage collector or a threading system, so programmers really only pay in performance for the features they use."

Edited 2012-01-24 08:53 UTC

Reply Score: 3

bnolsen Member since:
2006-01-06

deca is still more vapor than something like clay. there's papers and work on BNF, etc for deca, but no known implementation. the clay guys are the other side of the coin. I asked a few time (on irc) if they had any BNF, etc and was explicitly ignored. There's something to be said for an inbetween approach (move forward with experimentation, back fill BNF to check for stupid mistakes, etc).

Reply Score: 2

viton Member since:
2005-08-09

deca is still more vapor than something like clay. there's papers and work on BNF, etc for deca, but no known implementation


Vapor? It should not be hard to click the link.
http://code.google.com/p/decac/source/checkout

Reply Score: 2

bnolsen Member since:
2006-01-06

okay not fully vapor but not functional either. Read the recent updates. I'm sure its in production now just like rust and clay are (not).

http://code.google.com/p/decac/updates/list

Reply Score: 2

Ah yes, rust
by deathshadow on Tue 24th Jan 2012 11:45 UTC
deathshadow
Member since:
2005-07-12

... because there are people out there for whom C isn't cryptic enough; which is akin to the Puritans coming to Boston in 1630 because the CoE was a bit too warm and fuzzy for their tastes.

"aggressive abbreviation in the keywords" being geekspeak for "how much more difficult can we artificially make this language" -- treading into the territory of the old joke about Unix and C being a hoax.

http://www.elsop.com/wrc/humor/unixhoax.htm

I know, I know... Wirth elitist checking in... as if verbose code is somehow the ultimate evil. But as I've said a dozen times I'd sooner hand compile 8k of Z80 assembly than have to deal with 1k of C source... as if it needs an obfuscation contest given what the code looks like when NOT trying to be unnecessarily vague.

Programming languages like this seem to exist for the sole purpose of making programming difficult.

Reply Score: 4

RE: Ah yes, rust
by shmerl on Tue 24th Jan 2012 15:00 UTC in reply to "Ah yes, rust"
shmerl Member since:
2010-06-08

Yes, I didn't understand the need for aggressive abbreviation there. Does it really help anyone?

Reply Score: 2

RE[2]: Ah yes, rust
by oinet on Wed 25th Jan 2012 15:50 UTC in reply to "RE: Ah yes, rust"
oinet Member since:
2010-03-23

1) In earliest days of UNIX it was probably harmless when APIs (let alone commandline utilities) where few and hence collisions were unlikely. But things have grown since then, making it a necessity to avoid abbreviations for the sake of avoiding collisions...at least.

2) "Everything should be made as simple as possible, but no simpler." -Albert Einstein

3) "Give me a pot, i don't feel well!" -My mind

Edited 2012-01-25 15:51 UTC

Reply Score: 1

Mingw revenge
by fithisux on Tue 24th Jan 2012 14:51 UTC
fithisux
Member since:
2006-01-22

While their flagship products support only the cygwin+cl build system on windows this time they use pc-mingw32.

It seems that their flagship products are intentionally crippled against clang/gcc on windows.

Please re-consider your position. Clang/GCC are strong on windows and there is no excuse to avoid them

More importantly the mingw cross-compile from linux is out of the question and building on ReactOS is also impossible.

Reply Score: 2

What is the motivation?
by fithisux on Wed 25th Jan 2012 10:30 UTC
fithisux
Member since:
2006-01-22

Last night I decided to give a spin on my msys/mingw system (half of my OS :-) actually )

I found out that they depend on LLVM. While running the configure script I decided to take a more careful look at their web-page. In this page they hope that one day parts of Firefox could be written in the future in Rust.

That made me wonder. Why D is not suitable? Why they do not back LDC2?
In D they could start immediately replacing parts of FF with minimal to moderate performance lost. They could port their wrappers from Rust to D and have a better environment.

Moreover D has ide support and syntax highlighting support. And it seems that it does exactly what they need.

Google Go also has these features in a smaller degree but it could also offer simplified concurrent programming facilities.

But D has been tested in real apps (like Entice/Poseidon/Bud-build) and other projects. Personally I have used Go to port a network frame grabber from C++. I reached the same speed with one file that compiled on windows and a minimally modified counterpart for Ubuntu. It was a very fun / painless experience. I can recommend it but I do not have GUI experience in Go. It seems not mature. OTOH, D also supports conditional compilation. It is a killer feature.

IMO, LDC2 is an effort that Mozilla should back.

Reply Score: 2

RE: What is the motivation?
by darknexus on Wed 25th Jan 2012 11:04 UTC in reply to "What is the motivation?"
darknexus Member since:
2008-07-15

That made me wonder. Why D is not suitable?


I might be wrong about this, but aren't there some convoluted licensing issues around D that would cause problems for them? I was under the impression that, while version 1 of the D language specification is open (though the official compiler is not), version 2 wasn't. I could be wrong about this. I researched it once and I remember getting a headache trying to wrap my brain around the licensing. Anyone more knowledgeable than me on this care to clarify or correct me, please?

Reply Score: 2

RE[2]: What is the motivation?
by Not2Sure on Wed 25th Jan 2012 12:41 UTC in reply to "RE: What is the motivation?"
Not2Sure Member since:
2009-12-07

I might be wrong about this, but aren't there some convoluted licensing issues around D that would cause problems for them? I was under the impression that, while version 1 of the D language specification is open (though the official compiler is not), version 2 wasn't. I could be wrong about this. I researched it once and I remember getting a headache trying to wrap my brain around the licensing. Anyone more knowledgeable than me on this care to clarify or correct me, please?


I'm not sure what you mean by an "open" specification. People use the term in so many ways anymore.

If by "official" compiler you mean the digitalmars one, the frontend is available under a dual license, Artistic and GPL. The source for the digitalmars backend remains proprietary afaik but how that would affect the Mozilla foundation I have no idea. There are also GCC and LLVM backends available under GPL and BSD respectively.

Reply Score: 1

RE[2]: What is the motivation?
by moondevil on Wed 25th Jan 2012 15:05 UTC in reply to "RE: What is the motivation?"
moondevil Member since:
2005-07-08

"That made me wonder. Why D is not suitable?


I might be wrong about this, but aren't there some convoluted licensing issues around D that would cause problems for them? I was under the impression that, while version 1 of the D language specification is open (though the official compiler is not), version 2 wasn't. I could be wrong about this. I researched it once and I remember getting a headache trying to wrap my brain around the licensing. Anyone more knowledgeable than me on this care to clarify or correct me, please?
"


All those issues are long gone. There are three implementations available:

- DMD - Official one from Digital Mars
- GDC - D implementation for GCC. It will be made part of GCC official languages in the 4.7 or 4.8 release.
- LDC - LLVM backend implementation

Please note that nowadays D means D2. D1 will no longer be supported by end of 2012.

Reply Score: 2

RE: What is the motivation?
by Not2Sure on Wed 25th Jan 2012 12:49 UTC in reply to "What is the motivation?"
Not2Sure Member since:
2009-12-07

I am also on the D bandwagon but the lack of momentum or interest for ARM support is problematic.

Reply Score: 1

Hope it fails.
by reduz on Wed 25th Jan 2012 16:51 UTC
reduz
Member since:
2006-02-25

When the documentation of a language starts by showing all the cool stuff you can do which isn't possible in other languages (like mixing up stataments/expressions so wildly) the language usually sucks. Stuff such as:

let x = if the_stars_align() { 4 }
else if something_else() { 3 }
else { 0 };

Is not useful, it's unreadable language programmer ego masturbation.

I'd rather a language intentionally AVOIDS from allowing you to do all this stuff and forces you to write more code, that is more to the point and readable. After all, programmers don't spend most time writing code but thinking what to write.

Edited 2012-01-25 16:52 UTC

Reply Score: 2

RE: Hope it fails.
by AnyoneEB on Thu 26th Jan 2012 00:43 UTC in reply to "Hope it fails."
AnyoneEB Member since:
2008-10-26

I am not sure what your problem is. That if expression is nearly identical to the equivalent OCaml, which makes sense for a language trying to discourage the use of mutable variables.

Reply Score: 1