Rust 1.0 alpha released [LWN.net]

The alpha version of the Rust 1.0 release has been announced. There is a long list of new features added to the language; see the release notes for details. "The language is feature-complete for 1.0. While we plan to make many usability improvements before the final release, all 1.0 language features are now in place and we do not expect major breaking changes to them."

to post comments

Rust 1.0 alpha released

Posted Jan 10, 2015 0:08 UTC (Sat) by droundy (guest, #4559) [Link] (3 responses)

This looks exciting (especially the addition of associated types), but it's a little amazing that they are making such major changes so soon before a stable release. Of course, who knows how many alpha releases there will be...

Rust 1.0 alpha released

Posted Jan 10, 2015 3:54 UTC (Sat) by keeperofdakeys (guest, #82635) [Link]

Most of these changes haven't come out of nowhere, they've been in planning for half a year or more. These are the things that they wanted to improve/change about the language before they made 1.0. Now that most of them are ready, they are starting the 1.0 process.

Of course, there are many more features planned for after 1.0, but they add features instead of changing the language (like HKT and collection traits).

Rust 1.0 alpha released

Posted Jan 10, 2015 6:11 UTC (Sat) by b7j0c (guest, #27559) [Link] (1 responses)

In fairness, they've been very upfront about informing potential users of the potential for change, up to the point of suggesting that many developers simply stay away until things have settled

The next big hurdle will be advancing the cause of crates.io. The selection and coverage of packages is nowhere near what Go delivered even when it was a prerelease. I'm not sure I am totally at peace with core functionality like networking being relegated to package status....hopefully it will work out.

Rust 1.0 alpha released

Posted Jan 15, 2015 5:31 UTC (Thu) by wtanksleyjr (subscriber, #74601) [Link]

In theory, the fact that core functionality can be provided as a plugin is promising, since it means you can build a runtime using only what you actually need. And networking isn't as core as GC or range checking.

Of course, we all know that "promising" isn't the same as "delivering". :-)

Rust 1.0 alpha released

Posted Jan 11, 2015 8:45 UTC (Sun) by joib (subscriber, #8541) [Link] (106 responses)

Awesome! Rust looks really nice, I hope it succeeds. Next, the small matter of reimplementing all that security-critical infrastructure code written in C, C++, and other languages lacking memory safety, and save the world (from buffer overflows, at least).. ;-/

(Closer to my own interests, another newish have-your-cake-and-eat-it-too language, Julia, also looks awesome. Exciting times..)

Rust 1.0 alpha released

Posted Jan 12, 2015 1:26 UTC (Mon) by torquay (guest, #92428) [Link] (7 responses)

(Closer to my own interests, another newish have-your-cake-and-eat-it-too language, Julia, also looks awesome. Exciting times..)

I'm not really sure what scientific niche the Julia language is trying to fill. It seems everything is already well occupied. If speed is the target, then C++ linear algebra libraries such as Armadillo or Eigen already do a fine job. If rapid development and ease of visualisation are the targets, then we already have Octave and Python (with numpy), which is getting faster thanks to PyPy. There is also the widely used R language, easily sped up thanks to Rcpp.

Perhaps it would be more useful to put a LLVM-based JIT into Octave rather than write a new language (Julia) from scratch? Alternatively, port one of the existing C++ linear algebra libraries to Rust?

Rust 1.0 alpha released

Posted Jan 12, 2015 3:56 UTC (Mon) by rillian (guest, #11344) [Link] (3 responses)

> Perhaps it would be more useful to put a LLVM-based JIT into Octave rather than write a new language (Julia) from scratch?

As I understand it, while it's certainly possible to speed up R and especially Octave, it's not possible to achieve the same performance in a compatible language. Julia is leveraging the many things we've learned about just-in-time compilation of dynamic languages over the past decade in its design, and this is what lets it achieve native-code performance.

Whether it will find a large audience, and how well the promise of being able to write everything in the high level language will pay off in practice remains to be seen. But it does have good ideas, and I think the designers are correct to try to build something new at this point.

Rust 1.0 alpha released

Posted Jan 12, 2015 4:23 UTC (Mon) by torquay (guest, #92428) [Link] (2 responses)

and this is what lets it achieve native-code performance.

Is this merely "compile what's written into native code", or does it do optimization of math expressions ala template metaprogramming in C++ ? Part of the reason C++ is so useful for scientific/engineering code is its ability to avoid the generation of temporary objects while evaluating complicated compound expressions.

Rust 1.0 alpha released

Posted Jan 12, 2015 5:04 UTC (Mon) by rillian (guest, #11344) [Link]

I think so. Everything is multiple-dispatch, and the compiler can flatten calls to the most-specific argument types. http://nbviewer.ipython.org/gist/StefanKarpinski/b8fe9dbb... has more information.

Rust 1.0 alpha released

Posted Jan 12, 2015 10:17 UTC (Mon) by joib (subscriber, #8541) [Link]

Crudely, one can view a Julia function as analogous to a C++ template. At run time, type inference is used to compile an appropriate more or less statically typed version (with a cache of previously compiled versions to avoid recompiling, of course).

AFAICS, the Julia compiler is not that good at optimizing array expressions (yet?), so there is a lot of extra allocations of temporary arrays. Though there is a macro package "Devectorize" which can help somewhat.

Rust 1.0 alpha released

Posted Jan 12, 2015 10:10 UTC (Mon) by joib (subscriber, #8541) [Link] (2 responses)

As far as I can see, the goal of Julia is a language+environment which offers the programming productivity of high level environments like matlab, R, scientific python, without having to drop down to C/C++/Fortran all the time for performance reasons.

I have a small tight binding program that I have ported from the original Fortran 90, to C++ with Eigen, C++ with Armadillo, Python/numpy, and recently Julia. The Python and Julia versions are about half the size of the C++/Fortran versions. Performance-wise, C++ and Fortran are close, Julia within a factor of two of those, and Python/numpy something like 20 times slower than the Julia version (IIRC).

As to why create a new language rather than creating a JIT compiler for python/octave/R, the explanation given by the devs is that there are a lot of subtle language and library design choices which make it really hard to do well for python/octave/R. And of course, language-wise, MATLAB/Octave and R are pretty horrid. While Julia syntax superficially resembles matlab, at a deeper level it's more like a Lisp/Scheme variant (homoiconicity, macros, etc.).

As for porting Eigen/Armadillo or such to Rust, are the Rust generics up to it? Those libraries make heavy use of template metaprogramming.. Also, Rust syntax would need to be extensible so one would be able to have decent multi-dimensional array syntax (maybe doable with macros, I don't know).

Rust 1.0 alpha released

Posted Jan 16, 2015 1:48 UTC (Fri) by linuxbox (guest, #6928) [Link]

We actually implemented an early-stage compiler for the R language, using similar techniques to those in Julia. Couldn't get funding to continue it.

Rust 1.0 alpha released

Posted Jan 20, 2015 16:49 UTC (Tue) by zooko (guest, #2589) [Link]

Interesting numbers! Thanks!

If you happen to port it to PyPy+numpy (which may or may not require some actual rewriting to get it to run -- http://buildbot.pypy.org/numpy-status/latest.html), I'd like to hear how that compares, too. :-)

Rust 1.0 alpha released

Posted Jan 12, 2015 11:41 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (97 responses)

> save the world (from buffer overflows, at least)

What is really nice about Rust is that it saves the world from nasty and hard-to track double free bugs. Rust tracks ownership of pointers with very little runtime overhead that the compiler eliminates in most cases.

Rust 1.0 alpha released

Posted Jan 12, 2015 14:16 UTC (Mon) by ms (subscriber, #41272) [Link] (76 responses)

Yeah, but the ownership types scare me the most about this language. I've not seen any other language which has chosen ownership types over GC. Whilst the rules don't seem insane, I do worry about the amount of noise it adds to the syntax, and whether it's really going to scale - I fear it may become one of those issues that subtly impacts extensibility.

But I don't think I'm really in the target market for this sort of language.

Rust 1.0 alpha released

Posted Jan 12, 2015 14:30 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (20 responses)

With a GC, your language now has a runtime and needs special treatment when dlopen'ing one of its libraries from another language. Rust doesn't have this problem. Of course, there's the @nogc route that languages like D have, but I prefer it not have a GC unless explicitly requested because you either design with @nogc from the start or have a hell of a time putting it everywhere. Plus, lifetimes can be inferred now so you only really need them to link two ordinarily disparate variables' lifetimes together (AFAIK).

Rust 1.0 alpha released

Posted Jan 12, 2015 14:55 UTC (Mon) by ms (subscriber, #41272) [Link] (19 responses)

Sure, yes there are clearly pros and cons. Just like I personally prefer languages with green threads and a much richer RTS, but yes, that has knock-on effects for FFI and so forth.

For me, language choice is about "how easily does the language allow me to express a certain idea, and give me acceptable performance". But if your goal is more specifically performance focussed, then I can see Rust may cater well.

Rust 1.0 alpha released

Posted Jan 12, 2015 16:07 UTC (Mon) by droundy (guest, #4559) [Link] (16 responses)

I believe rust *had* green threads and a rich RTS until they realized that these could achieved with a library, so they simplified the core language. I'm delighted that this may be the first viable memory-safe alternative to C for implementing system libraries that can be used in any language.

Rust 1.0 alpha released

Posted Jan 12, 2015 19:06 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> I believe rust *had* green threads
Not anymore, it was removed for good during this summer.

Rust 1.0 alpha released

Posted Jan 12, 2015 21:17 UTC (Mon) by roc (subscriber, #30627) [Link] (12 responses)

They're still available in a library.

Rust 1.0 alpha released

Posted Jan 13, 2015 8:25 UTC (Tue) by ms (subscriber, #41272) [Link] (11 responses)

Interesting. I've just been trying to do some googling for libgreen and pretty much failing to find anything. So if there are URLs for the following, please do say.

To do green threads as a library, that would mean you'd need some way to interrupt a thread, suspend the computation and then allocate some other work to the thread. The very fact there's no API to do this on the JVM is the reason why Akka is not an real actor framework. An alternative implementation is using something like call/cc. In many languages, the RTS is an interpreter of some sort, and so building it into the interpreter is quite straight-forward.

But for libgreen to be able to do this (and is libgreen itself written in Rust?), presumably there must be one of these mechanisms available.

Rust 1.0 alpha released

Posted Jan 13, 2015 10:26 UTC (Tue) by riccieri (guest, #94794) [Link] (10 responses)

> So if there are URLs for the following, please do say.

libgreen is hosted at https://github.com/alexcrichton/green-rs since it was removed from the main rust repo.

AFAIK it's broken now, though. The hooks it needed were removed recently, thanks to the runtime removal work. From what I've read, it wouldn't be trivial to get it up to speed again.

> But for libgreen to be able to do this (and is libgreen itself written in Rust?), presumably there must be one of these mechanisms available.

The fact that there isn't is one of the reasons it was removed. It was trivial for a green thread to block the whole native thread by loop/recursion.

The Rust community uses a RFC process to discuss big changes like this before they land. If you are interested in reading up on the motivations that led to libgreen's demise, take a look at https://github.com/rust-lang/rfcs/blob/091e5fabbbbd0419b8... (discussion: https://github.com/rust-lang/rfcs/pull/230).

Rust 1.0 alpha released

Posted Jan 13, 2015 10:48 UTC (Tue) by ms (subscriber, #41272) [Link]

Thank you very much for the links and pointers.

Rust 1.0 alpha released

Posted Jan 14, 2015 6:04 UTC (Wed) by b7j0c (guest, #27559) [Link] (8 responses)

This is understandable given the rapid rate of change in the Rust world, but there's a real danger here of repeating the problems we see in Perl's CPAN and Haskell's Hackage - third party libs that bitrot, get opinionated (in a bad way), or are just orphaned. With Go, I never worry that my HTTP library will go off the reservation or just splinter...its given the same attention as the compiler itself.

Rust 1.0 alpha released

Posted Jan 14, 2015 12:52 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (7 responses)

But then you get the Python problem where the stdlib exists but is woefully inadequate (urllib, urllib2, xml) for certain use cases anyways.

Rust 1.0 alpha released

Posted Jan 14, 2015 19:09 UTC (Wed) by b7j0c (guest, #27559) [Link] (6 responses)

This keeps coming up from Rust people...Python library rot.

Its a Python problem, not a software problem. Why do people keep leaning on it like a crutch?

Java, C#, Go, even C++ among many others seem to be getting along just fine shouldering the responsibility of managing a standard library...

Rust 1.0 alpha released

Posted Jan 14, 2015 19:26 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

To be fair, I haven't done much Rust programming myself so my personal experience with it isn't very extensive. I have however been bitten by Python multiple times :/ . I also wouldn't call it "rot" so much as "batteries included, but I need 9V batteries and all you have are AA batteries".

Java, C#, and Go all have quite large companies shouldering a *lot* of the development of those standard libraries as well. C++ has multiple, but then you have the problem that it only contains the intersection of all their interests and agreements (which is, thankfully, getting larger). Mozilla isn't a weakling, but it also isn't a billion-dollar multinational.

Rust 1.0 alpha released

Posted Jan 14, 2015 19:36 UTC (Wed) by bronson (subscriber, #4806) [Link] (4 responses)

The megabytes of Java and C++ stdlibs that are now deprecated and considered antipatterns indicate "just stick it in the stdlib" is not as easy as it sounds. What went wrong with Python? How can Rust avoid being another "Python problem?"

The entire Rust project has a tiny fraction of the manpower that wrote Java's first stdlib. I applaud them for treading a little more carefully.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:38 UTC (Wed) by b7j0c (guest, #27559) [Link] (1 responses)

> The megabytes of Java and C++ stdlibs that are now deprecated and considered antipatterns indicate "just stick it in the stdlib" is not as easy as it sounds.

Do you really think the situation will be better with third party libs?

Rust 1.0 alpha released

Posted Jan 14, 2015 23:02 UTC (Wed) by bronson (subscriber, #4806) [Link]

I do! Absolutely. Especially if the language has a good package manager.

Ruby is a good example. Years ago, a lot of functionality was rolled into its stdlib: rexml, drb, webrick, json, etc. Since then, far FAR better implementations have been produced: nokogiri, rabbitmq, puma/unicorn/..., json-native, etc. These are drastic improvements to API and internals -- incremental, backward compatible tweaks weren't possible (or, more accurately, would have required so much work that it's just not realistic).

Now nobody uses the stdlib versions anymore. They're completely dead, but they need to be shipped Ruby forever. (Huh, just like a lot of Java and C++ calls)

So, to avoid this, Ruby 2.0 gemified some of its other libs and things got much better: http://www.rubyinside.com/the-ruby-standard-library-to-be...

Node did this too. Lots of functionality from Java's stdlib is not shipped with Node, but found in common NPM packages. Nobody seems to mind and, in fact, improvements seem to come much faster.

Few things ossify code quite as much as including it in the stdlib.

Rust 1.0 alpha released

Posted Jan 15, 2015 23:03 UTC (Thu) by pboddie (guest, #50784) [Link] (1 responses)

What went wrong with Python? How can Rust avoid being another "Python problem?

By insisting that people cannot merely declare their mission accomplished, throw their code over the wall into the standard library, and then walk away leaving others to maintain it forever.

Underestimating the role that the standard library plays in attracting and retaining users, and believing that language-polishing is more useful than library maintenance, is another trap that the Rust maintainers might also want to avoid when Rust becomes mature enough for most people to be happy with what the language itself offers.

Rust 1.0 alpha released

Posted Feb 3, 2015 22:10 UTC (Tue) by nix (subscriber, #2304) [Link]

By insisting that people cannot merely declare their mission accomplished, throw their code over the wall into the standard library, and then walk away leaving others to maintain it forever.

So you mean they don't want the Rust standard library to rust?

(sorry)

Rust 1.0 alpha released

Posted Jan 13, 2015 18:01 UTC (Tue) by b7j0c (guest, #27559) [Link] (1 responses)

> I believe rust *had* green threads and a rich RTS until they realized that these could achieved with a library

This is one position that I wish the Rust team had not embraced...the idea that libraries will simply emerge for common functionality.

In the short to mid-term, we'll get multiple attempts to implement stuff like networking, green threads etc...resulting in frankenstein code, bloated binaries, and code rot. Sure, over the very long term, winners will emerge...but it seems more sensible to just bite the bullet and accept that developers expect some common batteries to be included. Without a doubt, a robust and sensible standard lib has been fundamental to the success of Go, Java and C#.

Case in point - HTTP. Retrieving a url and printing its contents is the new "hello world". Most modern developers will access HTTP services more than they will access the filesystem. Indeed, Rust's initial use case (Servo) is embedded in an application that is focused on HTTP. HTTP is twenty years old and will be around in another fifty. If a standard library can read local files, it should be able to read the contents of a URL.

The notion of a "minimal core" is a virtuous position that occupies the moral high ground but has no practical value.

Rust 1.0 alpha released

Posted Jan 13, 2015 20:52 UTC (Tue) by roc (subscriber, #30627) [Link]

I don't think the Rust people are opposed to having a rich standard library.

They're making the library "optional" in the sense that if you write Rust code that doesn't explicitly use the standard library, your compiled Rust program has few or no dependencies on any run-time library. This property is makes it much easier to use Rust in certain contexts --- e.g. embedded systems, kernels, components in some larger system which already has its own complex runtime.

That's why the standard library switched from user-threads to native threads.

But that's totally compatible with having a rich, featureful standard library.

Rust 1.0 alpha released

Posted Jan 13, 2015 7:09 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (1 responses)

The biggest problem with Erlang style of a program composed of massive amount of green threads is that it requires segmented stack support. Unfortunately as Rust and Go guys have learned on a modern hardware performance impact of that is substantial. And without the segmented stack green threads are no longer looks that attractive to deserve a prominent place in the language design. So Rust rightfully delegated the green thread support to a library.

Rust 1.0 alpha released

Posted Jan 14, 2015 6:00 UTC (Wed) by b7j0c (guest, #27559) [Link]

Punting is not a solution

Rust 1.0 alpha released

Posted Jan 12, 2015 18:36 UTC (Mon) by HelloWorld (guest, #56129) [Link] (50 responses)

> I do worry about the amount of noise it adds to the syntax
Well, one has to put up with syntax noise anyway in a C-like language. All those <>, () and {} serve no real purpose as humans perceive most of the syntactic structure through indentation. This is also why people (including myself) often get lost in function calls nested more than two or three levels deep. It's not that it's hard per se but that the representation of it is unsuitable for the way human brains work.

Personally, I think it's sad that we have to worry about this kind of stuff at all. In 2015, it ought to be possible to edit a syntax tree directly without taking the detour through a textual representation that was defined by somebody else. Structured editing makes it possible to show me exactly the level of details I want to see. One example of this is lamdu's verbose typing mode, see http://vimeo.com/97648370 (at 1:48). It shows the type of every subexpression in an unobtrusive and helpful way.
Perhaps some day something similar exists for other languages.

Rust 1.0 alpha released

Posted Jan 12, 2015 19:37 UTC (Mon) by viro (subscriber, #7872) [Link]

Unobtrusive is right - with the font size that doesn't reduce the amount of source you can see at the same time ridiculously low, these types of subexpressions will be downright invisible...

Seriously, how large is your monitor and how large are the programs you are normally working on? Cheap shots about your nick aside, _are_ you actually writing anything, or is your involvement with any kind of programming just a pure armchair quarterbacking?

Rust 1.0 alpha released

Posted Jan 12, 2015 21:21 UTC (Mon) by roc (subscriber, #30627) [Link] (46 responses)

Structured program editing has been tried and failed many, many times over several decades.

Part of the problem is that you end up locked into a world of your own because the rest of the world is based on text.

Another part of the problem is it's incredibly useful to be able to work with (temporarily) syntactically invalid programs.

Modern IDEs give you most of the benefits of structured editors without the downsides, by maintaining a parsed or partially-parsed AST that's always in sync with the editor text.

Rust 1.0 alpha released

Posted Jan 13, 2015 8:32 UTC (Tue) by ms (subscriber, #41272) [Link] (45 responses)

> Another part of the problem is it's incredibly useful to be able to work with (temporarily) syntactically invalid programs.

I would recommend you look at something like Epigram. The type-checker _drives_ development and prompts you to fill in the gaps rather than merely trying to cope with what you give it. I believe you can do fairly similar things with Agda and Coq. The Haskell programming-with-holes is getting close these days too.

Too often people think of an adversirial relationship between programmer and type checker. If you change that to a collaborative relationship then you can make a lot of interesting progress. I'm not knocking the feedback that modern IDEs give, but the level of understanding they have about your program is pretty basic. Much more can be done. At that point, editing on the AST becomes somewhat more feasible, IMO.

Rust 1.0 alpha released

Posted Jan 13, 2015 21:07 UTC (Tue) by roc (subscriber, #30627) [Link] (44 responses)

Modern IDEs also support "fill in the gaps" programming. See http://eclipse.dzone.com/news/effective-eclipse-dont-write-c for example.

Eclipse's Java tools' autocomplete and autogenerate features are type-aware. For example, typing "foo.bar<ctrl-space>" brings up an autocomplete list containing just methods exposed by foo's type.

> the level of understanding they have about your program is pretty basic.

Eclipse JDT maintains a full type-annotated AST on every keystroke (as long as the program is valid). Editing the AST directly would give you nothing more (except pain). This is been true for over a decade.

Rust 1.0 alpha released

Posted Jan 13, 2015 21:08 UTC (Tue) by roc (subscriber, #30627) [Link]

BTW it's not just Eclipse; many modern IDEs are at the same level. Eclipse is just what I know.

Rust 1.0 alpha released

Posted Jan 13, 2015 21:28 UTC (Tue) by ms (subscriber, #41272) [Link] (4 responses)

Yes, I know that. The type system for Java though is very basic so there's not much an IDE can really do. Languages with much richer type systems (I'm thinking mainly dependently-typed languages such as Epigram, Agda, Idris or even proof assistants such as Coq) allow the IDE/editor to do much more and programming then becomes more of a conversation.

The classic example is you're writing an implementation of Zip. You state in the type signature for Zip that the two lists must be the same length and then you state that you wish to proceed by structural recursion. Epigram, for example, will then take that information and will generate the stubs for the two cases you need to deal with: 1. both lists have a head and a tail; 2. both lists are empty. It knows that the other cases (one list has head-and-tail, the other is empty) is impossible given the predicates given, so doesn't generate any stubs for these cases.

I think it may be the case that you only really get to this level of conversation once you have dependent types. It's not really there in Haskell/Scala/Rust (IMO, all fairly similar from a types PoV - certainly Haskell and Scala have _some_ aspects where you can do computation at type level, but it's limited / inconvenient). Maybe that really just means you need to design and build your language for this sort of dialogue with an editor in mind rather than try to add it on later.

Rust 1.0 alpha released

Posted Jan 13, 2015 22:31 UTC (Tue) by roc (subscriber, #30627) [Link] (3 responses)

I think you're conflating two features: structured AST editing, and leveraging rich type systems for more sophisticated editing assistance. They aren't orthogonal, but neither depends on the other.

I heartily agree that the richer your type system, the more an IDE can do. (Well, up to a point, since expensive, unpredictable or undecidable type computations could cause problems for an IDE.) But you don't need to directly edit an AST to get those benefits. In your Zip example, you could easily extend the Eclipse UI to generate those stubs, if the language supported it.

Rust 1.0 alpha released

Posted Jan 14, 2015 8:16 UTC (Wed) by ms (subscriber, #41272) [Link] (2 responses)

> I think you're conflating two features: structured AST editing, and leveraging rich type systems for more sophisticated editing assistance. They aren't orthogonal, but neither depends on the other.

You're entirely right, thank you!

So yes, the richer the type system is, the more the editor can work with you.

I also happen to think that the way we use text files for programming, as some sort of ad-hoc 2D canvas with weird rules, is somewhat antiquated and I do wonder if better could be done. I agree that this too has nothing to do with AST-based editing, which is making me think maybe I'm not interested in AST-based editing at all...

Rust 1.0 alpha released

Posted Jan 14, 2015 18:37 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Maybe people ought to learn Forth :-)

The source code pretty much is an AST :-)

Okay, that's a bit tongue-in-cheek but it's not far off.

Cheers,
Wol

Rust 1.0 alpha released

Posted Jan 14, 2015 21:14 UTC (Wed) by roc (subscriber, #30627) [Link]

It's true for Scheme and LISP too. Look up "homoiconicity".

For better or worse, though, people are used to syntax that isn't homoiconic.

Rust 1.0 alpha released

Posted Jan 14, 2015 0:31 UTC (Wed) by HelloWorld (guest, #56129) [Link] (7 responses)

> Eclipse's Java tools' autocomplete and autogenerate features are type-aware. For example, typing "foo.bar<ctrl-space>" brings up an autocomplete list containing just methods exposed by foo's type.
That's the boring part. Programming with holes takes into account not only the type of the (left) operand but also the type of the hole that you're trying to fill. Say foo's bar method takes an int. Then when I type foo.bar(baz.<Ctrl>-<Space> I should be offered those methods of baz first that actually return an int, and Eclipse doesn't do that.

Rust 1.0 alpha released

Posted Jan 14, 2015 1:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

IntelliJ IDEA certainly does this. And it can do this (although not perfectly) even for C++.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:46 UTC (Wed) by HelloWorld (guest, #56129) [Link] (4 responses)

I can only comment on IntelliJ's Scala support and so far, I'm less than impressed. We have rather long (ca. 1500 LOC) file in our project and every time I make non-trivial changes to it, IntelliJ takes ages to parse it again. Perhaps that's just a Scala issue, but I suspect an AST-based editor would work better and be less touchy.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

No, it won't be. The problem is in Scala - it requires a lot of CPU power to parse, especially when implicits or macros are used.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:55 UTC (Wed) by HelloWorld (guest, #56129) [Link] (2 responses)

> The problem is in Scala - it requires a lot of CPU power to parse
The whole point of having an AST editor is not having to do parsing at all.

Rust 1.0 alpha released

Posted Jan 14, 2015 23:45 UTC (Wed) by nix (subscriber, #2304) [Link]

What yields the AST, then, magic? Like it or not, the only way to get from a bunch of text to an AST is parsing. It sounds like the IntelliJ parser isn't particularly incremental, though (not surprising: incremental parsing of as much as possible of potentially-incomplete or invalid strings is really, really hard.)

Rust 1.0 alpha released

Posted Jan 15, 2015 0:07 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

The problem is not in _parsing_ but in actually doing the semantic checking and validation.

I.e. if you type:
>
>val blah = foo();
>bar(blah); <-- You're here
>
IDEA has to spend a lot of time to find the candidates for the bar() function, to check the type of their arguments, to see if there's perhaps an implicit conversion and so on.

The parsing of "bar(blah);" into an untyped AST is easy.

Rust 1.0 alpha released

Posted Jan 14, 2015 2:08 UTC (Wed) by roc (subscriber, #30627) [Link]

OK, but there's nothing about Eclipse's architecture that makes that particularly difficult to implement. All the information that you need to make that work is available. ms was arguing that this can't be done in a text-based editor.

Rust 1.0 alpha released

Posted Jan 14, 2015 0:34 UTC (Wed) by HelloWorld (guest, #56129) [Link] (29 responses)

By the way, I also contest the assumption that it's very useful to be able to write syntactically invalid code. I rarely do that on purpose, most of the time I just mess up the parens and then the compiler complains and I have to figure out where the paren needs to go. I don't think of that as a feature.

Rust 1.0 alpha released

Posted Jan 14, 2015 2:38 UTC (Wed) by zlynx (guest, #2285) [Link] (20 responses)

Say that you're moving code around. You are removing an if {} else {} and replacing it with a ternary expression.

During that process code is going to be in invalid states because you can't remove the braces and rewrite it without going through invalid states. In some fancy GUI editor that enforced correctness you'd be required to delete the code and reenter it in the new form instead of deleting a few braces and replacing the if/else.

It only really works for Lispish languages because it's already essentially a syntax tree.

Rust 1.0 alpha released

Posted Jan 14, 2015 12:50 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (4 responses)

For an AST editor, why would it not have a button or menu item to transform it into a ternary ?: already?

Rust 1.0 alpha released

Posted Jan 14, 2015 16:00 UTC (Wed) by zlynx (guest, #2285) [Link] (3 responses)

Sure you could have a button.

Are you going to have a button for every possible code transformation possible? Why? Isn't it going to take longer to find the right button than to just edit the code?

Rust 1.0 alpha released

Posted Jan 14, 2015 16:18 UTC (Wed) by Limdi (guest, #100500) [Link] (2 responses)

Ask the vim guys. it works!

Rust 1.0 alpha released

Posted Jan 14, 2015 19:29 UTC (Wed) by bronson (subscriber, #4806) [Link] (1 responses)

As a Vim guy, I don't even have a button that reliably converts Ruby block forms ("do ||; end" vs "{ || }"), much less any sort of interesting task.

Oh I've installed a few half-assed plugins attempting stuff like this, and they all waste more time than they save.

Any hints on what my vimrc is missing?

Rust 1.0 alpha released

Posted Jan 14, 2015 21:39 UTC (Wed) by Limdi (guest, #100500) [Link]

You are right. Where no problem is, is no solution needed.

What I meant is that if a serious problem arises, that it is solvable.

Its probably faster to edit the source code, ur right, thats probably why some AST-Editors take the hybrid approach, take visual and text input.

To the transformation thing: Yes, some gui editor which enforces correctness and is not a hybrid editor and is not scriptable to add new transformations and which has no command/menu-entry/holy-button to disable correctness temporarily might be not the best AST-Editor in the world.

Now that I copy-pasted the whole ideas from above I am asking myself why I just did that.

Rust 1.0 alpha released

Posted Jan 14, 2015 19:11 UTC (Wed) by HelloWorld (guest, #56129) [Link] (14 responses)

I don't see why your example would pose a problem in an AST-based editor. So let's say your code is if(a) { b } else { c }. Then you could insert a new ternary-operator node above a, yielding if(a ? <hole> : <hole>) { b } else { c }. Now you cut and paste b and c to the right places, yielding if(a ? b : c) {<hole>} else {<hole>} (which may well be a type error but shouldn't be a syntax error). And now you can just move the ternary-operator node one level up, discarding the remainder of the if-else node. It's entirely possible if the editor offers a decent selection of AST-based editing primitives. Figuring out what those are is probably part of the challenge, but I think it can be done.

Rust 1.0 alpha released

Posted Jan 14, 2015 21:20 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

I suspect it's highly annoying to be forced to go through those intermediate states, when it seems more convenient to take a shortcut through invalid states. I'm not sure, since I haven't used one of these systems personally.

Like I said, this has been tried many times, and we aren't using such editors so those attempts were not successful in the end. Unfortunately, because of the way academic research works, it'll be difficult to find reports on why these systems failed :-(.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:07 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

My guess is the lack of rigidity in "mainstream" languages. With something as strict as Haskell, the types you expect narrow things down by quite a bit. Basically, the really hard part is that a "()" hole which is near impossible to fill intelligently. Languages which don't have side-effect tracking have a hole of that shape *everywhere* and the AST is basically [Statement] which is awfully vague and I can indeed seeing fighting the editor at every step because it doesn't read your mind. The example "if <-> ?:" transformation doesn't have any issue in Haskell because you have ifThenElse[1] as a function and the if/then/else keywords are just syntactic sugar for that function[2], so a transformation is always 1:1.

[1]Basically; it seems if/then/else is actually syntax, but there is an extension which makes it sugar for an ifThenElse function.
[2]There is no if/then in Haskell; else is *mandatory*.

Rust 1.0 alpha released

Posted Jan 14, 2015 21:34 UTC (Wed) by zlynx (guest, #2285) [Link] (11 responses)

Your example is exactly what I said was more difficult. You're deleting the code and replacing it in the holes.

Another one I thought of that happens all the time in Python. Someone does a thinko and puts code inside of a loop body that should actually only run once. Delete four spaces and it's fixed. With an AST editor you have to cut and paste that into another node.

None of this makes an AST editor impossible to use. I'm just making the point that there are several things that temporarily invalid syntax lets you do easily.

And here is another point. What does the fancy AST editor do if it has to open a file that someone hacked on with Vim or Notepad or it suffered a bit flip or a bad disk block? Kind of limited if it only works on perfect data.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:34 UTC (Wed) by HelloWorld (guest, #56129) [Link] (3 responses)

> Another one I thought of that happens all the time in Python. Someone does a thinko and puts code inside of a loop body that should actually only run once. Delete four spaces and it's fixed. With an AST editor you have to cut and paste that into another node.
No you don't. Nothing stops an AST editor from having commands to move subtrees around in a smart way (i. e. one level up in your case).

> None of this makes an AST editor impossible to use. I'm just making the point that there are several things that temporarily invalid syntax lets you do easily.
I'm not disputing that such cases exist. I'm disputing that the inconvenience caused thereby is greater than the advantage of not having to deal with syntax errors any longer.

> And here is another point. What does the fancy AST editor do if it has to open a file that someone hacked on with Vim or Notepad
As long as it parses, no problem. If it doesn't, fix it with what you used to break it.

> or it suffered a bit flip or a bad disk block?
Since that essentially never happens, it's not the case that we should optimize our tools for. And if it actually does happen, fix it with some other means or recover it from the SCM or backup.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:47 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I'm not disputing that such cases exist. I'm disputing that the inconvenience caused thereby is greater than the advantage of not having to deal with syntax errors any longer.
And I dispute that. We can actually compare it in practice - there's an AST editor from IntelliJ: https://www.jetbrains.com/mps/ and of course they produce the best syntax-aware code editors in the world.

So feel free to try their AST editor. It's horrible. And that tells volumes - even the guys who write code parsers for breakfast and do incremental C++ parsing for lunch can't make a good AST editor.

Rust 1.0 alpha released

Posted Jan 14, 2015 22:57 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

"JetBrains can't do it" isn't enough to convince me it's a bad idea in general.

Rust 1.0 alpha released

Posted Jan 14, 2015 23:27 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Don't forget the "…for Java" part there too.

Rust 1.0 alpha released

Posted Jan 15, 2015 14:41 UTC (Thu) by cesarb (subscriber, #6266) [Link] (3 responses)

> And here is another point. What does the fancy AST editor do if it has to open a file that someone hacked on with Vim or Notepad or it suffered a bit flip or a bad disk block? Kind of limited if it only works on perfect data.

And what about when you're writing a header which is meant to be included more than once, with macros defined differently each time? There's no single AST for it, each time it's included it can have a radically different AST.

Rust 1.0 alpha released

Posted Jan 15, 2015 16:05 UTC (Thu) by HelloWorld (guest, #56129) [Link]

And this, among many many others, is the reason why both the C preprocessor and the lack of a proper module system in C are among the most idiotic things that ever happened in the field of programming. As long as we use garbage like that, there's no chance of ever getting out of the midle ages of programming.

Rust 1.0 alpha released

Posted Jan 15, 2015 16:17 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

If that feels like the right way to do something, it's usually an indication that you should be using a proper code generation tool that uses a suitable domain-specific input language, rather than resorting to the simultaneously inadequate and incomprehensible facilities of the C preprocessor.

Rust 1.0 alpha released

Posted Jan 15, 2015 16:32 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Sorry, the preprocessor existing is not a reason to not have better tools just because it throws a wrench at any attempt at reasoning about C/C++. Now if the C preprocessor were *hygenic*, sure. But it isn't, so I feel no remorse for it being neglected for new tools.

Rust 1.0 alpha released

Posted Jan 15, 2015 17:01 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

And here is another point. What does the fancy AST editor do if it has to open a file that someone hacked on with Vim or Notepad or it suffered a bit flip or a bad disk block? Kind of limited if it only works on perfect data.

This seems like a total non-problem. As I see it, there are two cases:

The editor fails to generate a valid AST for code that still compiles and runs correctly. This is an AST editor bug that needs to be fixed.
People are submitting code that doesn't compile. This is a process problem and needs to be dealt with by rejecting broken code.

In neither case is the real problem with AST-level editors in general.

In any case, I doubt it's going to show up much in real-world usage. If AST-level editors are a genuine improvement over text editors, it shouldn't be hard to get everyone in the project to start using them. If they aren't, they're going to be a niche product for the handful of cases where they're especially useful.

Rust 1.0 alpha released

Posted Feb 3, 2015 22:09 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

The problem with "people are submitting code that doesn't compile" is that these are *editors*. People routinely transition through code that doesn't compile on the way to code which does -- in fact, since people cannot type at infinite speed and most people do not ensure that all their identifiers' prefixes are also valid identifiers, this sort of transition is essentially universal.

You can't really reject anything from an editor except when the user asks for it (or does something, like committing, which suggests that they think the code is in a self-consistent state).

Rust 1.0 alpha released

Posted Feb 3, 2015 23:23 UTC (Tue) by dashesy (guest, #74652) [Link]

Inspections are getting better but still I have to turn off half of them in Pycharm (which is one of the smartest) and still half of code gets flagged because of dynamic dispatching, lack of understanding about Mixins and meta classes, ...
Should not reject even on commit.

Rust 1.0 alpha released

Posted Jan 14, 2015 2:39 UTC (Wed) by roc (subscriber, #30627) [Link] (7 responses)

It's very useful to allow the code be *temporarily* invalid.

Rust 1.0 alpha released

Posted Jan 14, 2015 18:57 UTC (Wed) by HelloWorld (guest, #56129) [Link] (6 responses)

I'm not convinced about that.

Rust 1.0 alpha released

Posted Jan 14, 2015 23:49 UTC (Wed) by nix (subscriber, #2304) [Link] (5 responses)

More and more you are convincing me that you've never written nontrivial amounts of code, or that you've written them in a very stylized way and never watched anyone else write code, such that you're convinced that only *your* way of writing code is possible.

It is *utterly routine* to write things like function calls and nested blocks by typing them in from the start to the end. Not everyone religiously types in foo() and then goes back and fills in the brackets. An editor that cannot handle this style of coding will be unusable for a very large proportion of the programming community (well over half, I'd guess, from my experience: quite possibly over 90%).

Rust 1.0 alpha released

Posted Jan 15, 2015 0:18 UTC (Thu) by HelloWorld (guest, #56129) [Link] (4 responses)

> More and more you are convincing me that you've never written nontrivial amounts of code, or that you've written them in a very stylized way and never watched anyone else write code, such that you're convinced that only *your* way of writing code is possible.
I write code in a team for a living, thank you very much.

> Not everyone religiously types in foo() and then goes back and fills in the brackets. An editor that cannot handle this style of coding will be unusable for a very large proportion of the programming community (well over half, I'd guess, from my experience: quite possibly over 90%).
You clearly lack any kind of imagination.

Rust 1.0 alpha released

Posted Jan 15, 2015 16:34 UTC (Thu) by bronson (subscriber, #4806) [Link] (3 responses)

Sounds like you both are most interested in sniping at each other and any discussion about editors is just a side effect?

Rust 1.0 alpha released

Posted Jan 15, 2015 17:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Hmm... Useful discussions as a side effect of pure trolling.

So let's call it 'functional discussion'!

Rust 1.0 alpha released

Posted Jan 15, 2015 18:45 UTC (Thu) by HelloWorld (guest, #56129) [Link] (1 responses)

Well, I'm not the one who started questioning nix' competence because his opinion differs from mine. I just think it's too early to call structured editing a failed idea.

Rust 1.0 alpha released

Posted Feb 3, 2015 22:06 UTC (Tue) by nix (subscriber, #2304) [Link]

I just think that any style of editing that precludes your writing code in whatever order you like (top-down, bottom-up, functions-from-start-to-end, hell functions-from-end-to-start if you like) is doomed to failure. The variety of writing styles is just too great.

(Thankfully proper parsers for this stuff -- which can handle incremental parsing of erroneous code with bits missing and outright syntax errors, etc -- is quite possible, if also quite hard. It's not like it has to figure out what all the syntactic constituents are all the time, like a parser in a compiler must. It can leave great bits listed as "don't know" or even get it outright wrong now and then and the likelihood is nobody will ever notice.)

Rust 1.0 alpha released

Posted Jan 13, 2015 9:02 UTC (Tue) by jezuch (subscriber, #52988) [Link] (1 responses)

> Personally, I think it's sad that we have to worry about this kind of stuff at all. In 2015, it ought to be possible to edit a syntax tree directly without taking the detour through a textual representation that was defined by somebody else.

About ten years ago one James Gosling, I think, undertook a project like this. The result was not a syntax tree editor, though, but Jackpot, a refactoring engine in the NetBeans IDE which is very cool (but severely under-documented). I may remember things wrong, of course, but I remember being rather excited about this.

(What's more, not only we're still using text files, but we also insist on using a fixed-width font so that the text columns are aligned. How quaint is that? ;) )

Rust 1.0 alpha released

Posted Jan 13, 2015 9:16 UTC (Tue) by ms (subscriber, #41272) [Link]

> What's more, not only we're still using text files, but we also insist on using a fixed-width font so that the text columns are aligned. How quaint is that? ;)

Well, readability is very important, and if things make more sense vertically aligned then so be it. That said, I do think Bret Victor's talk on the future of programming languages is a pretty serious indictment of programming language development. http://vimeo.com/71278954

Rust 1.0 alpha released

Posted Jan 12, 2015 21:29 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

Yes, Rust is the first major language to make heavy use of language-enforced ownership/borrowing (though there's been a lot of research work in this area). That's what makes it both scary and exciting.

I think the results in practice have been very positive so far. For example, Servo is reasonably large and complicated. There hasn't been much churn in the ownership/borrowing rules recently, which suggests it's no longer causing major issues. (It took a while to converge, though!)

Servo?

Posted Jan 13, 2015 15:41 UTC (Tue) by louie (guest, #3285) [Link] (1 responses)

Is there a state-of-servo somewhere? Just curious...

Servo?

Posted Jan 13, 2015 18:56 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

It used to be attached to the "This Week in Rust" posts, but it seems to have diverged at some point. Anyways, found this[1] blog.

[1]http://blog.servo.org/

Rust 1.0 alpha released

Posted Jan 13, 2015 9:55 UTC (Tue) by xav (guest, #18536) [Link]

The Vala language does that, based on GObject system. I only have toyed a bit with it but it's a joy to use compared to plain C for dealing with all GLib-based frameworks.

Rust 1.0 alpha released

Posted Jan 17, 2015 7:29 UTC (Sat) by keeperofdakeys (guest, #82635) [Link] (19 responses)

It should be pointed out that the ownership tracking is purely compile time, there is absolutely no runtime component of it. There are libraries which give you runtime semantics of ownership, so you can write safer unsafe code though, but you must explicitly use the libraries and their functions.

With the 1.0 feature changes of Rust, you can effectively call if from C code without any setup (some features do require it though).

Rust 1.0 alpha released

Posted Jan 17, 2015 10:48 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (18 responses)

Hm, I though to support ownership tracking across libraries/crates a compiler still needed to generate some extra code to ensure safety. Or was the rules changed so even that minimal support is no longer necessary?

Rust 1.0 alpha released

Posted Jan 17, 2015 14:02 UTC (Sat) by apoelstra (subscriber, #75205) [Link] (17 responses)

> Hm, I though to support ownership tracking across libraries/crates a compiler still needed to generate some extra code to ensure safety. Or was the rules changed so even that minimal support is no longer necessary?

There are some datatypes which provide runtime safety checks (and have well-defined semantics if safety is violated), but the primitive types do not. There is nothing like a NullPointerException in Rust, so I'm not sure what this extra code would be doing. Can you clarify your comment? To the best of my knowledge Rust has never generated extra code to ensure safety.

I'm not the best authority on Rust, but I have been following it for over a year and contributed several nontrivial (but unremarkable) changes and bug reports to various parts of the compiler.

Rust 1.0 alpha released

Posted Jan 17, 2015 16:40 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (16 responses)

See http://smallcultfollowing.com/babysteps/blog/2012/11/18/i... . There the talk was about @T pointers that later became Box<T>. They require extra runtime support.

Rust 1.0 alpha released

Posted Jan 17, 2015 19:58 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

Box<T> are just like regular C++ smart pointers. No special global runtime support for them is needed.

Rust 1.0 alpha released

Posted Jan 17, 2015 20:28 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (13 responses)

I am not sure what exactly "regular smart pointers" means. Does in the current Rust the overhead of Box<> is similar to that of unique_ptr in C++, which is not zero compared with raw pointers, but the overhead is local to the code that uses the pointers with no impact on the rest?

Rust 1.0 alpha released

Posted Jan 17, 2015 21:00 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Just like in C++, you can have your own smart pointers (by implementing the 'deref' method). So there's a wide range of possible smart pointers with various overheads. Arc<T> (atomic reference counter) is pretty slow, for example.

Box<T> behaves like an auto_ptr in C++ and it really has no dynamic overhead compared to a usual raw pointer because the compiler (borrow checker) can trace and check the lifetimes.

unique_ptr in C++ is a more complicated beast because it uses a special deleter to allow its destructor to run without the full definition of the object being destructed.

Rust 1.0 alpha released

Posted Jan 17, 2015 22:58 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (6 responses)

> the compiler (borrow checker) can trace and check the lifetimes.

But then what has changed since http://smallcultfollowing.com/babysteps/blog/2012/11/18/i... ? The examples there demonstrated why a minimal runtime overhead is necessary and that was implemented later.

Rust 1.0 alpha released

Posted Jan 17, 2015 23:04 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Quite a lot of stuff has changed since then: Rust dropped green threads, most of the runtime, gained a minimal core library, etc.

Right now Rust can safely be used to implement libraries that are invoked from pure C or any other language.

Rust 1.0 alpha released

Posted Jan 17, 2015 23:25 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (4 responses)

I meant what was changed regarding the borrowing rules? I.e does the usage of Box<T> in Rust 1.0 requires absolutely no overhead in all cases compared over a raw pointer in a C sense? 2 years ago the rules required to use bit manipulations to mark a pointer as borrowed and checks on write operations. I was under impression that that stayed the same.

Rust 1.0 alpha released

Posted Jan 17, 2015 23:43 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

All the borrow checker operations are done in compile time, so they have zero overhead.

Perhaps you're referring to drop flags? Right now Rust internally marks destroyed objects by adding a special bitflag to them. That's needed to support 'dynamic drops'.

However, this is going to change to purely static code, having zero impact on the structure size or overhead

https://github.com/pnkfelix/rfcs/blob/6288739c584ee6830aa...

Rust 1.0 alpha released

Posted Jan 19, 2015 8:07 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (2 responses)

Thanks for clarifications! I forgot that @ pointers in older Rust were GC-controlled and they required some overhead. In Rust 1.0 Box<T> pointers indeed have *no* overhead compared with C pointers. C++ has nothing like that as even with unique_ptr in addition to however small overhead there is no safety against aliasing the moment one passes unique_ptr<T> as const T&.

Rust 1.0 alpha released

Posted Jan 19, 2015 9:48 UTC (Mon) by JGR (subscriber, #93631) [Link] (1 responses)

Nothing in C or C++ can protect you against aliasing in that way.
C++ smart pointers track ownership, not whether other non-owning pointers/references might exist elsewhere.

One other difference is that (if I'm reading the docs correctly) shallow copying a Box<T> does a move, like auto_ptr in C++, which worries me a little.

Rust 1.0 alpha released

Posted Jan 19, 2015 11:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

You _can_ make aliasing restriction in C++. I had my own system of owned/borrowed pointers since the days of C++03.

However, it can only work if you are careful not to use non-borrow-tracking smart pointers. And it has some runtime overhead.

As to moves vs. copy, Rust actually does not copy stuff very often. In fact, you have to go to some lengths to make your structures copyable if they contain anything that's not a primitive type. However, most stuff in Rust is implicitly movable.

It makes so much sense that I wonder why C++ hasn't tried that first.

Rust 1.0 alpha released

Posted Jan 18, 2015 17:21 UTC (Sun) by jwakely (subscriber, #60262) [Link]

> unique_ptr in C++ is a more complicated beast because it uses a special deleter to allow its destructor to run without the full definition of the object being destructed.

It *can* use a special deleter, but it only does that optionally. The default deleter has no overhead and requires the type to be complete in the unique_ptr destructor.

Rust 1.0 alpha released

Posted Jan 18, 2015 17:31 UTC (Sun) by jwakely (subscriber, #60262) [Link] (3 responses)

> unique_ptr in C++, which is not zero compared with raw pointers

It's pretty close though

(It some overhead when passed to/from functions because its non-trivial move constructor and destructor mean it needs to be passed by invisible reference not in a register.)

Rust 1.0 alpha released

Posted Jan 18, 2015 18:56 UTC (Sun) by JGR (subscriber, #93631) [Link] (2 responses)

> It's pretty close though

> (It some overhead when passed to/from functions because its non-trivial move constructor and destructor mean it needs to be passed by invisible reference not in a register.)

The destructor is part of the type, the structure itself contains only a raw pointer, and can be passed in a register just like a raw pointer. It isn't a virtual class or anything.
The overhead comes when destructing it, as it needs to check if the raw pointer value is non-null, and if so, delete/run the custom deleter on it.
The difference in the move constructor is that the source is cleared when the pointer is "moved".

Rust 1.0 alpha released

Posted Jan 18, 2015 22:36 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

That's actually what Rust does right now (it is the simplest way to implement dynamic drops), but there's a plan to use static analysis to avoid the need to check and zero objects on destruction.

Rust 1.0 alpha released

Posted Jan 24, 2015 23:24 UTC (Sat) by jwakely (subscriber, #60262) [Link]

The Itanium ABI says that a non-trivial copy constructor and destructor affect how a type is passed:
https://mentorembedded.github.io/cxx-abi/abi.html#value-p...
That predates C++11, but the same is true of non-trivial move constructors.

Rust 1.0 alpha released

Posted Jan 18, 2015 1:11 UTC (Sun) by apoelstra (subscriber, #75205) [Link]

Ah, `@` pointers were actually garbage collected pointers, which (I think) did require runtime support. But they were nearly gone when I showed up, and there should be no trace of them now.

`~` pointers were the ones that became `Box<T>`. These did not have any overhead. Unlike C++, the compiler has enough information to determine ownership statically and is able to insert (the equivalent of) `malloc` and `free` calls in the correct places with no tracking code.

One big exception to this, as Cyberax reminded me, is drop flags. These are flags inserted by the compiler when objects are freed in certain execution branches of a block but not others; then at the end of the block where cleanup code is inserted, the compiler does not know exactly what has been freed, and needs a runtime lookup table to avoid double-freeing. Fortunately these are on the way out too :).

Rust 1.0 alpha released

Posted Jan 16, 2015 12:20 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link]

[joke]
Well, we both know that compiling libDiamonds and Rust brings memory.
[/joke]