Linked by Thom Holwerda on Fri 15th May 2015 21:00 UTC
General Development

Today we are very proud to announce the 1.0 release of Rust, a new programming language aiming to make it easier to build reliable, efficient systems. Rust combines low-level control over performance with high-level convenience and safety guarantees. Better yet, it achieves these goals without requiring a garbage collector or runtime, making it possible to use Rust libraries as a "drop-in replacement" for C. If you'd like to experiment with Rust, the "Getting Started" section of the Rust book is your best bet (if you prefer to use an e-reader, Pascal Hertleif maintains unofficial e-book versions as well).

Order by: Score:
Bill Shooter of Bul
Member since:
2006-07-14

I tend to get annoyed by over glowing reviews of various technologies. There are always trade offs. It helps to have a good idea what those are before diving in.

http://www.viva64.com/en/b/0324/

Reply Score: 3

shmerl Member since:
2010-06-08

Author called it a toy. I lost respect to his review after that sentence.

Reply Score: 2

TheMadShatter Member since:
2015-05-16

If you had actually read the review, you'd very quickly discover that "toy" is not being used as a pejorative. It's being used to describe Rust as it actually is compared to real programming languages: it is a toy. It lacks the capabilities and functionality that we'd expect from a serious systems programming language.

Instead of knee-jerk overreactions due to you incorrectly perceiving something as an insult, next time you should calmly finish reading the entire article. Then you would know that what you thought was an insult was actually a very appropriate description.

Reply Score: 4

Alfman Member since:
2011-01-28

If you had actually read the review, you'd very quickly discover that "toy" is not being used as a pejorative. It's being used to describe Rust as it actually is compared to real programming languages: it is a toy. It lacks the capabilities and functionality that we'd expect from a serious systems programming language.


...such as?

Instead of knee-jerk overreactions due to you incorrectly perceiving something as an insult, next time you should calmly finish reading the entire article. Then you would know that what you thought was an insult was actually a very appropriate description.



Well this is interesting, because if the situation were reversed and Rust were the incumbent industrial language standard, don't you think that C/C++ as a new comer would be the "toy" language for not having correctness verification built in? BTW I'm a fan of C/C++ myself, but I can still acknowledge it's weaknesses. One of the things I like best about Rust is that in contrast to so many of the other modern languages being developed (ie particularly those that achieve correctness by being "managed"), rust brings us compile-time correctness without the tradeoffs of managed languages.

Edited 2015-05-16 17:12 UTC

Reply Score: 3

shmerl Member since:
2010-06-08

I red the whole thing. He has some valid points, but his tone is not professional, and the "toy" title highlights it.

Reply Score: 1

ssokolow Member since:
2010-01-21

<span>I tend to get annoyed by over glowing reviews of various technologies. There are always trade offs. It helps to have a good idea what those are before diving in.

http://www.viva64.com/en/b/0324/


There are two main trade-offs:

1. It can be somewhat difficult to internalize the rules the borrow checker uses to determine whether to allow the code to compile in more complex cases.

2. If you want to implement something that falls outside the paradigm (eg. the Rc<T> reference-counting generic from the standard library), then you have to use unsafe {} blocks and the code inside those blocks is much closer to C in terms of what the compiler will let you screw up.

Also, as people on /r/rust/ already pointed out, that post is published by a company that makes their money selling a C/C++ static analysis tool. Not exactly an unbiased source.

Edited 2015-05-15 22:37 UTC

Reply Score: 6

shmerl Member since:
2010-06-08

Yes, he even mentions it in the article trying to downplay that as a good feature in Rust, which caught my attention. In C++ it's done with external tools which is a downside, not a benefit.

Reply Score: 0

Alfman Member since:
2011-01-28

Bill Shooter of Bul,


From your link...

It is crystal clear for every sane programmer that C/C++ is not going to die in the nearest future. No one is going to rewrite almost all of the existing desktop applications, operating system kernels, compilers, game and browser engines, virtual machines, databases, archivers, audio and video codecs, tons of other C-libraries, and so on and so forth, into other languages. This is a huge mass of fast, debugged, and time-proven code...


With this point the author is wrong...dangerously wrong. While there are some truths in there, time has proven over and over again (and again ad infinitum) that C/C++ code is dangerous. Many of the serious system vulnerabilities we see are the consequence of using languages without compile time code validation. Yes in theory humans can do this job, given sufficient time, resources, and motivation. However there's an endless trail of evidence showing that despite having intelligent and well meaning developers hammering out our C code, year after year we still end up with swiss cheese software leaving many of our systems vulnerable to attack (*1).

This is a serious ongoing problem for all core software built in C, both proprietary and open source. It will continue to happen for as long as C is in use. C exploits are so notorious that we've designed techniques like ASLR to make exploits more difficult. Unfortunately this is just a bandaid for incorrect code, and doesn't fix the core problem. Languages like rust are able to prevent data/pointer overflows, making techniques like ASLR unnecessary.

The beauty of rust is that unlike VM/managed languages, it manages to provide these checks at compile time, giving us important safety benefits without compromising on the performance and low level control that makes C desirable.


*1 A very serious attack against QEMU-based hyper-visors (affecting many cloud hosting providers) was disclosed just yesterday:
http://venom.crowdstrike.com/
I submitted an article on this but OSNews decided not to post it for some reason.

Edited 2015-05-16 01:55 UTC

Reply Score: 9

Luminair Member since:
2007-03-30

that guy is smart but too religious about c/c++ to be a useful source of information on this topic

dear pope, how are the muslims today

Reply Score: 2

ssokolow Member since:
2010-01-21

that guy is smart but too religious about c/c++ to be a useful source of information on this topic

dear pope, how are the muslims today


Here's the /r/rust/ post where they went into more detail on the shortcomings and issues with that review:

https://www.reddit.com/r/rust/comments/35pn5a/

Reply Score: 4

galvanash Member since:
2006-01-25

I would point out the contention that Rust is "far from fast" in the article you linked is somewhat misguided, at least if it is based solely on the particular benchmark that was presented. I'm not saying it is incorrect, just that it is leaving out some relevant details.

If you actually look at the individual scores on that benchmark:

http://benchmarksgame.alioth.debian.org/u64/rust.php

You will notice that on most of them Rust is very close to C compiled with GCC. Faster on one, fairly close on most (within 2x), and at most 3x slower on one or two.

On one particular benchmark, however (regex-dna), it is 12x slower, which drags it's median down considerably... It is slower on this benchmark mostly because of some acknowledged deficiencies in the Rust regex library that are being addressed:

https://github.com/rust-lang/regex/issues/66
https://github.com/rust-lang/regex/issues/68

I think in light of that saying "I sincerely hope that programmers will find a way to speed it up in time" is kind of misleading. Its already pretty damn fast already in most respects, it just has a couple of rough spots that need to be ironed out, things that don't really have any connection to either the compiler's behavior or the language design itself, i.e. library issues. If you look at a comparison to Java you can see what I mean - that lone benchmark sticks out like a sore thumb:

http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=rust&l...

Anyway, I'm not saying Rust will end up being faster than C or C++, but it is arguably (even with the regex problem) in the same ballpark. It don't think saying "it is comparable to Java, Go, and Haskell regarding performance" is going to be accurate for much longer.

Edited 2015-05-16 06:08 UTC

Reply Score: 7

safety
by le_c on Sat 16th May 2015 09:18 UTC
le_c
Member since:
2013-01-02

I like the idea of Rust but every time I look into the doc it just looks ugly and very complicated. Has it any safety advantage over Nim? Nim looks much nicher and simpler compared to Rust!

Reply Score: 1

RE: safety
by ryak on Sat 16th May 2015 09:47 UTC in reply to "safety"
ryak Member since:
2015-04-20

I like the idea of Rust but every time I look into the doc it just looks ugly and very complicated. Has it any safety advantage over Nim? Nim looks much nicher and simpler compared to Rust!


I like Nim, but it's basically a one-man show and that one man doesn't always listen well to input. The libraries is of highly varying quality.

Rust takes more effort to learn, but it has a really amazing type system that makes it well worth it. And it has the advantage of a much larger community.

Reply Score: 2

RE: safety
by ssokolow on Sat 16th May 2015 13:23 UTC in reply to "safety"
ssokolow Member since:
2010-01-21

I like the idea of Rust but every time I look into the doc it just looks ugly and very complicated. Has it any safety advantage over Nim? Nim looks much nicher and simpler compared to Rust!


Nim is more a competitor for Go than Rust.

1. Nim is a GCed language in the same way that D is a GCed language: You can turn off the GC but, if you do, you lose so much of the standard library that it's unfeasible.

Since you really don't want to try to get two GCs to play nice in the same memory space, that means you can't feasibly embed a scripting language like JavaScript or Python in Nim without rewriting them Rhino/Jython-style. It also massively constrains your ability to write libraries for use by anything with a C FFI. (Rust makes an excellent alternative to tools like Cython for offloading your hot loops to compiled code.)

2. By design, Nim's syntax attempts to provide a more performant way to get the looser, more "do what I mean" experience of a scripting language. Rust aims for explicitness in everything for the sake of maintainability across multiple generations of contributors.

The big safety advantage Rust has over Nim is on the "humans make mistakes" side of things. (eg. Inspired by Rust's strict, explicit type checking, the Hyper HTTP library for Rust combines Rust's expressive type system and time inferrence to produce an API that does compile-time correctness checking for the HTTP protocol itself. (eg. It'll catch "set headers after send" and header typos at compile time)

Edited 2015-05-16 13:33 UTC

Reply Score: 4

Re:
by kurkosdr on Sun 17th May 2015 17:54 UTC
kurkosdr
Member since:
2011-04-11

What kind of name is "Rust"?

Were the names "Bit Rot" and "Goes Bad Over Time" taken or something?

PS: Yes I know, programmers are highly rational individuals and don't judge technology based on the name, but the PHBs who -on some companies- have the final say, or even worse don't even bother asking anyone who is an implementor, aren't so.

Reply Score: 3

RE: Re:
by Alfman on Sun 17th May 2015 18:05 UTC in reply to "Re:"
Alfman Member since:
2011-01-28

kurkosdr,

Hahaha, your post put a picture in my head of a corporate meeting where project managers are choosing the technology to use based on how good they sound ;)

It's probably not that far from the truth either!

Reply Score: 2

RE: Re:
by shmerl on Sun 17th May 2015 18:30 UTC in reply to "Re:"
shmerl Member since:
2010-06-08
Comment by motang
by motang on Mon 18th May 2015 00:01 UTC
motang
Member since:
2008-03-27

Is this one that is developed by Mozilla? If so that means the new mobile browser that is co-developed by Samsung shouldn't be too far behind.

Reply Score: 2

Welcome to 1978
by deathshadow on Tue 19th May 2015 12:40 UTC
deathshadow
Member since:
2005-07-12

I had the feeling I was dealing with something VERY "special" the first time I saw the syntax and language definition for Rust... unfortunately that's "special" in the same way some Olympics are "special".

The moment I saw they were too lazy to type the full word "function" whilst at the same time bringing back "LET" from the dark ages of ROM BASIC programming... then there's this "boxing" garbage that reeks again of line numbered basic... fancy way of bringing us back to the hell that was DIM.

Then of course for a language that seems to want to use needlessly pointlessly cryptic reserved words, it then goes and uses a ridiculously long form "let if else" instead of the classic ternary operator style condition... MAKE UP YER BLOODY MIND!!!

The needleslly pointlessly cryptic garbage seems to extend language wide -- it's handling of conditional compilation seeming to be as intentionally obtuse and addle-minded as possible, the cargo asshattery reeking of the same "how many separate files can we create for no good reason" thinking that's pissing all over websites when people use things like frameworks or the pain in the ASS that are 'make' or '.h" files.

I've not seen a programming language this malfing idiotic since I looked at Ruby or the gibberish the scripttards vomit up with the mouth-breathing idiocy known as jQuery.

But what do I know, I'm a Wirth kind of guy... who started out hand assembling my own machine language on a RCA 1802. I'd sooner hand assemble 8k of Z80 machine language than to try and debug 100 lines of C++ code; hence why I'm not convinced that this:

https://www.gnu.org/fun/jokes/unix-hoax.html

... is actually a joke.

Rust, the programming language for people who think that C++ is a little too verbose and clear for their tastes; which is a bit like making your own terrorist group because Hezbollah and the Taliban were too warm and fuzzy.

Reply Score: 2

RE: Welcome to 1978
by CapEnt on Tue 19th May 2015 20:47 UTC in reply to "Welcome to 1978"
CapEnt Member since:
2005-12-18

Perl 3 choose to have a baby with OCaml. Rust born.

I'm seriously appalled by Rust syntax and inclined to agree with you.

Twenty five years ago, compiler designers at least had the excuse that computers were not fast enough when designing write-only languages.

Reply Score: 2

RE[2]: Welcome to 1978
by ssokolow on Wed 20th May 2015 15:36 UTC in reply to "RE: Welcome to 1978"
ssokolow Member since:
2010-01-21

Twenty five years ago, compiler designers at least had the excuse that computers were not fast enough when designing write-only languages.


Mind elaborating on that?

Rust was designed to be less "write-only" than C++ and, in my opinion, they succeeded.

Edited 2015-05-20 15:37 UTC

Reply Score: 2

RE: Welcome to 1978
by ssokolow on Wed 20th May 2015 15:31 UTC in reply to "Welcome to 1978"
ssokolow Member since:
2010-01-21

I had the feeling I was dealing with something VERY "special" the first time I saw the syntax and language definition for Rust... unfortunately that's "special" in the same way some Olympics are "special".


I'm honestly not sure if you're trolling here or just very immature but I'll give you the benefit of the doubt since I feel that, before this comment thread goes into "archived" mode, there should at least be some attempt to counter what you said.

The moment I saw they were too lazy to type the full word "function" whilst at the same time bringing back "LET" from the dark ages of ROM BASIC programming... then there's this "boxing" garbage that reeks again of line numbered basic... fancy way of bringing us back to the hell that was DIM.


Rust has strong origins in the world of functional programming where, inspired by math notation, you generally either write "fn" or something like Haskell's "->" and "=>" (In fact, the compiler was originally written in Ocaml)

Maybe I'm just becoming a UNIX greybeard decades early, but, if I have to choose between erring on the side of cryptic vs. erring on the side of verbose, I'll take
fork() (POSIX) over ZwCreateProcess() (Win32)
and
"let input = io::stdin()" (Rust) over "Reader input = new BufferedReader(new InputStreamReader(System.in))" (Java)
any day.

...and it's not as if they could use C's solution. They explicitly wanted to avoid "the lexer hack"

https://en.wikipedia.org/wiki/The_lexer_hack

As for "let", it came about as a way to balance three needs:
1. Making the point of declaration explicit (Can't just use 'foo = "bar"' with no garbage collector)
2. Allowing type inference (which rules out "int foo = 5")
3. Being simple for the lexer to parse (Again, see "the lexer hack")

Would you have preferred "var"? I believe they ruled it out because the only objective difference between "let" and "var" is that "let" allows the statement to feel a bit more natural when read aloud.

As for "boxing", that's just their term for heap-allocating things. They used to have about half a dozen different sigils like ~ and @ for different types of pointers and, after moving Rc<T> into the standard library and shelving Gc<T> for more thought, they decided that their type system and optimizer working together were powerful enough that "owning pointer to the heap" could also be made a generic without increasing CPU or memory load in the compiled result.

"Box<T>" is literally just Rust's equivalent to C++'s "std::unique_ptr" and "Rc<T>" is Rust's equivalent to C++'s "std::shared_ptr" (If you want manual memory management with *, &, and Rust's malloc equivalent, you can do that by adding the "unsafe" keyword to a block or function.)

They called it "Box" to focus attention on the non-optional pointer indirection that it incurs compared to stack-allocated variables.

Then of course for a language that seems to want to use needlessly pointlessly cryptic reserved words, it then goes and uses a ridiculously long form "let if else" instead of the classic ternary operator style condition... MAKE UP YER BLOODY MIND!!!


I get the impression you've never programmed in an expression-oriented language before.

In C, the ternary operator exists because if/else is a statement and can't return a value.

In Rust, there's no need for a separate ternary operator because if/else is an expression which returns a value, just like "thing == 5"

Given that they avoided duplicate syntax wherever possible, would you really want to see

thing == 5 ?
do_something()
:
do_something_else()
;

whenever it's not being used as an expression?

The needleslly pointlessly cryptic garbage seems to extend language wide -- it's handling of conditional compilation seeming to be as intentionally obtuse and addle-minded as possible, the cargo asshattery reeking of the same "how many separate files can we create for no good reason" thinking that's pissing all over websites when people use things like frameworks or the pain in the ASS that are 'make' or '.h" files.


I honestly have no idea what you're talking about. If anything, I find it LESS cryptic than an equivalently powerful C or C++ build system.

(Are you complaining about compiler directives and macros operating lexically rather than as raw string substitution? Look up "hygienic macros" for the rationale behind that.)

As far as "how many separate files can we create for no good reason" goes, I seriously doubt you've read the docs:

1. You can put an arbitrary tree of namespaces into a single file using mod{} blocks. The only restriction is that a new file must create its own namespace, just like in every other modern language.

2. The "use" keyword has a form equivalent to Python's "from foo import *" or Java's "import com.java.io.*" and you can use the "pub" modifier to mark them for re-export to produce a single namespace built from multiple files.

Rust, the programming language for people who think that C++ is a little too verbose and clear for their tastes


Rust, the programming language by experienced C++ programmers from Mozilla who got fed up with having to either read horrendously long "your error lies somewhere in this chain of generics" error messages or track down mistakes that C++ gleefully allowed them to make because there's no way to make the older, less compile-time-checkable stuff opt-in.

Edited 2015-05-20 15:38 UTC

Reply Score: 2