Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.0: Status report and final timeline

blog.rust-lang.org

Post reply on HN
Print view View original

101–110 of 128 posts

Re: Rust 1.0: Status report and final timeline

#101

Post by jroesch »

TwoBit wrote: post #87

Some language guy told me that Rust's ownership system is untenable. He said that researchers tried the same thing years ago and it was concluded to be impossible to work well. I know that's vague, but he claimed to know what he was talking about.

Researchers will often say things like this about techniques they couldn't get working as a way to explain away their failures. Often times some one will come along a couple years later and do exactly what they claimed was impossible or untenable. I've heard people claim that improvements on their techniques are impossible, and that proposed improvements "won't work" when it in fact does (source: I've seen this happen in the research community more than once).

Re: Rust 1.0: Status report and final timeline

#102

Post by jroesch »

cw0 wrote: post #88

Is it safe to assume that anyone wishing to learn Rust can, by alpha2, study The Rust Programming Language and Rust By Example and not need to relearn anything within that scope after 1.0 lands?

The core language is almost completely fixed, and the only real changes will be in unstable areas like associated types. There might be some small API changes but all APIs are marked with stability levels so you should be able to figure out what is stable, and what is not.

Re: Rust 1.0: Status report and final timeline

#103

Post by jroesch »

cw0 wrote: post #88

Is it safe to assume that anyone wishing to learn Rust can, by alpha2, study The Rust Programming Language and Rust By Example and not need to relearn anything within that scope after 1.0 lands?

The core language is almost completely fixed, and the only real changes will be in unstable areas like associated types. There might be some small API changes but all APIs are marked with stability levels so you should be able to figure out what is stable, and what is not.

Re: Rust 1.0: Status report and final timeline

#104

Post by jpgvm »

nostrademons wrote: post #91
gnuvince wrote: post #85

Earlier quoted context omitted.

As far as I know, Rust now has an LL(1) grammar, which means that writing parsers for it can be done by hand (or with the more powerful LALR(1) and LR(1) parser generators). This is very important for humans too, because it means more people are likely to write tools to process Rust code. If you hope to have automatic indentation, auto-completion, refactoring, formatting tools, etc. keeping the syntax simple is reall…

Can't they just expose the parser as a library? Actually, it looks like they did, with the rustc crate. Hand-writing a parser for some other language leads to madness - just ask the folks who've done SWIG, GDB, or most IDE syntax-checkers. You'll inevitably get some corner-cases wrong, or the language definition will change underneath you long after you've ceased to maintain the tool. Instead, the language should jus…

You missed the whole point.

By making the language simple you can easily implement your own parser. This opens up the ability to write native parsers in other languages, say vimscript. By keeping it super simple there -are- no corner-cases.

There are many benefits to this (like the formatters etc that others have alluded to) from things like IDE integration (imagine lifetime elision visualisation, invalid move notifications, etc) static analysis tools and more. None of these tools then need to be written in Rust. It also means it's easier to implement support in pre-existing multi-language tools.

Don't underestimate the necessity of a simple parseable grammar. Besides, people have endured much worse slights in syntax (see here Erlang).

Re: Rust 1.0: Status report and final timeline

#105

Post by Retra »

tarblog wrote: post #86
pcwalton wrote: post #17

Earlier quoted context omitted.

The natural thing to want in a C-like syntax is the "arrow function" closure syntax (like ES6 or C#), but that required too much lookahead to parse. Having a keyword discourages functional style, which would be a shame in a language with a powerful iterator library. So Rust went with the Ruby/Smalltalk-style bars, which are nice, concise, and easy to parse.

How much worse is it? Can parsing actually be so expensive that it dictates the syntax of the language?

Parsing a context free grammar in general is O(n^3), but parsing an LL(1) grammar is O(n). That's a pretty huge difference, if you're not careful. Imagine you've got a million lines of code to parse.

Re: Rust 1.0: Status report and final timeline

#106

Post by snake_case »

jarrettc wrote: post #11

Even though 1.0 isn't out yet, today you can use Rust for many real projects. I'm unsure whether I'd bet my business on it yet, but I'd be open to the idea. And I'm usually a very late adopter. I've been building a 3d game with Rust and OpenGL, ported from a C++ codebase. So far, my experience has been very positive. Despite Rust's supposed immaturity, it feels more polished than C++ in many ways. Forward progress ha…

Since you ported from a C++ codebase, how have you handled situations in your game where a lot of inhetitance was used? You may not even use inheritance much in the first place however, just curious about your rust-like solutions for typical c++ game development practices.

Re: Rust 1.0: Status report and final timeline

#107

Post by Animats »

mbrubeck wrote: post #29
doctoboggan wrote: post #23

Earlier quoted context omitted.

I am not a Rust user and maybe I am reading the post wrong but it seems that syntax has been deprecated: > Closures: Rust now supports full capture-clause inference and has deprecated the temporary |:| notation, making closures much more ergonomic to use.

That's talking about something different. For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move. Now that this is inferred in all cases, closure arguments can just be written as |args| in all cases, just as they were before the current Fn* traits were introduced.

I wish they also had the option of a pure lambda that isn't a closure. You can't pass a pure lambda to an argument expecting an ordinary function.

Re: Rust 1.0: Status report and final timeline

#108

Post by nwmcsween »

breckinloggins wrote: post #48
pcwalton wrote: post #44

Earlier quoted context omitted.

> The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynamic dispatch, you suddenly have vtables. But who decides what those vtables look like? Where do they reside in memory? What's the layout of that? If a struct suddenly has an is-a pointer, where is that mentioned in the code? Now my struct isn't just a struct. 1. We already have vtables through trait objects (though no…

> Garbage collection and virtual dispatch are completely different things; having one in no way moves us closer to the other. Right, of course not. The comparison was philosophical rather than technical. My point was that I believe there's a "sweet spot" for a language that is expressive and convenient and modern, but also tries hard not to stray too far from C's spartan abstract machine model (and when it does, it e…

Rust will not replace c, rust is a more refined c++. If you want something to replace c have: a better type system, raii, better macros, better lifetime management, etc but keep it simple and don't layer it.

Re: Rust 1.0: Status report and final timeline

#109

Post by Animats »

AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

Closeout is always difficult. Destructors don't handle errors well. Neither does Go's "defer".

Python's "with" clause seems to do the best job of making sure closeout is handled properly. Take a careful look at the extra arguments to a __exit__ function in Python,s "with". It's one of the few closeout methods where things such as an exception during closeout (an I/O error during file close, for example) is handled in a way that doesn't interfere with other closeouts.

Re: Rust 1.0: Status report and final timeline

#110

Post by Animats »

TwoBit wrote: post #87

Some language guy told me that Rust's ownership system is untenable. He said that researchers tried the same thing years ago and it was concluded to be impossible to work well. I know that's vague, but he claimed to know what he was talking about.

I was one of the people who proposed something like that, back in 2001, as a "strict mode" for C++.[1] I wrote "The basic concept is that pointers and references explicitly declared as auto can't be used in ways that would let the data they contain outlive the scope of the auto variable." This is what Rust calls "borrowing". (That was written before C++ repurposed the "auto" keyword for other languages call "let".)

As a retrofit to C++, that idea wasn't going to work. It would have either been too restrictive or unsafe. It had to be built into the language at a deeper level. That's what Rust does.

[1] http://www.animats.com/papers/languages/cppstrictpointers.ht...

Post reply on HN