nercury

Yes, the stable release is lagging behind a bit, as it must be stable :)

Most importantly, the finished MIR revolution [0] will finally allow developers to focus on new exciting features, like ergonomic "impl Trait" [1], incremental compilation, or even the beginnings of Gc [2].

[0]: https://github.com/rust-lang/rust/pull/35764

[1]: https://github.com/rust-lang/rust/issues/34511

[2]: http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...

It takes time to build things.

Good article, but loosing 50 pounds over 2 months seems impossible. I always thought the optimal weight loss rate was max 2-3 pounds per week.

The idea here is to separate lifetime of iteration (the scope in which "next" is used 'i) and the lifetime of data ('a), which would result in following signature:

  fn next<'i>(&'i mut self) -> Option<Vec<&'a T>>

which, thanks to lifetime elision, is the same as

  fn next(&mut self) -> Option<Vec<&'a T>>

Retrying on any exception might be wrong thing to do. For example, the I/O error many levels bellow might happen for wildly different reasons, and handling them all the same way might be wrong. If not, then the correct behavior of the project depends on exceptions originating from different modules being handled the same, and that increases coupling.

This worries me a bit: I have another github account that is definitely a robot: it publishes documentation on github pages automatically on successful travis build.

There are robots everywhere: for example, the Rust's github repos won't work the same without bors or highfive.

If I remember correctly, the github itself definitely used to allow robots for such use cases.

Rust is good.

Great tooling: Libraries can be written, published and used quickly. Code can be easily rebuilt on upcoming Rust versions without uninstalling anything. Integrated testing and documentation generation. Cross-compilation.

Truly cross-platform. As an example, Rust even supports both GNU and MSVC targets on Windows, that means Rust libraries can be linked into the C++ projects compiled with MINGW or MSVC. All the standard library features are cross-platform, unless namespaced otherwise.

Rust linear type system requires variables be either uniquely mutable or immutable, but not both. This solves whole class of resource management problems (memory being the most important) in the simplest possible way. This compile-time guarantee also works for all references to data, which become thin pointers at runtime. This, together with Send-able and Sync-able types, also ensures no data races.

Language is up-to-date. No-nulls, pattern matching, closures, generics, attributes will feel familiar to programmers coming from various languages. Language had many iterations and changes, and every bit of it was designed with care. Right now it may be a bit explicit, but sugar can always be added later if it appears worth it.

Stable release cycle, stability guarantee. We know when new beta will be renamed to stable and we know what's in it! That means there is time to check all ecosystem for possible breakage, even though historically Rust introduced hardly any breaking changes since 1.0 a year ago.

Wait for this to land: https://github.com/rust-lang/rust/pull/33500

Nice Al Legory

I don't know about what the author's goals are, but I am in favor of offloading as much work to computer as possible.

To err is to be human, but compilers never forget.

The engineering decisions are not based on beliefs. They are usually trade-offs. Safety in Rust has a very specific meaning clearly outlined in the official book. There are users who prefer it for certain tasks. The answer to your last question is also in the book.

It is rare to see a cross platform release with so much collaboration behind the scenes. Extremely exciting!

Yeah, I am also wondering. All I see is the same ol' link to half-outdated NDK documentation.

"auto a = ConjureMagic();" "SetMagic(a);"

The problem here is actually is an old one of failing to separate a getter from a command.

It looks like ConjureMagic is causing side effects and modifying the state of whatever class it belongs to.

This is also the reason one can't answer the question "what the heck is a?". If the "ConjureMagic" is only a getter and does not modify class state, it may probably need a better name, like "GetMaxMagicPossible". That renders an auto no longer confusing, because this name explains more than the return type. If, on the other hand this is just a command to conjure the magic and we are getting the remaining amount only to immediately pass it to the member "SetMagic" function, then there was no point in returning this value - it could be done inside the "ConjureMagic" itself.

If you are more gender-inclusive than me, I suggest you create a new open source project with these rules:

- Require all contributors to specify their gender; - Do not allow new contributions if they exceed gender quota for release.

Good luck.

I disagree that the way is "worse".

I like that in templates, string handling is _enforced_ to be different. For example, when you manipulate strings in template, you can be reasonably sure all output is escaped, unless you specify otherwise in a very few precise cases with explicit syntax.

A good template language allows you to create/limit available tools/helpers for your particular project. That is especially important in larger projects and larger teams, where everyone is not immediately expected to know intended good practice to follow. Creating DSL in template _is_ a way of documenting intended good practice.

A good template language does not pretend not to be turing-complete: instead, it provides comprehensive error handling and error messages, so that users know exactly where some error or type occurred.

One more reason to use the language is because it is a language. If someone used something like Django, the Twig will be quite familiar and easy to pick up.

Template engine can optimize-away, pre-compile things, just like languages do.

With separate template language you don't need to recompile whole build if you change a template (presuming hosting language is compiling to binary and template engine is interpreted).

Full disclosure: I am currently rewriting Twig in another language, and believe it's completely worth the effort.

I can also say smart things:

Template language is useful not because it allows to do things, but because it limits what can be done.

No, I did not actually had Angular in mind when writing this. We often hear talks how new major version should handle deprecation gracefully. It was more the reaction of actually seeing it happen.

> If your app runs on Ember 1.13 without raising deprecations, it should run on 2.0.

Every framework should take note: that's how you avoid creating another framework and fragmenting community!

It's is great to see this in action :). Amazing work.

Different AST representations in Rust compiler - high level and middle level.

The introduction in book (linked in announcement) actually explains exactly this, very nicely.

It sounds like this:

Rust is a systems programming language focused on three goals: safety, speed, and concurrency. It maintains these goals without having a garbage collector, making it a useful language for a number of use cases other languages aren’t good at: embedding in other languages, programs with specific space and time requirements, and writing low-level code, like device drivers and operating systems. It improves on current languages targeting this space by having a number of compile-time safety checks that produce no runtime overhead, while eliminating all data races. Rust also aims to achieve ‘zero-cost abstractions’ even though some of these abstractions feel like those of a high-level language. Even then, Rust still allows precise control like a low-level language would.

Thanks for writing this, can't be upvoted enough!

Please consider the time it takes for a new language to be fully developed and to take hold. These major revisions are simply new languages, because they _break backward compatibility_.

Except, um... PHP.

I was surprised to find my old project there from 2009: a simple lib for utf8 font rendering with OpenGL. I exported it into github, only to find that it never had any source hosted in source control - all my source was in a tarball inside "downloads".

I guess there are many authors like me who don't even remember they are hosting something there - it would be sad to loose all that code.

I find another aspect of this announcement VERY interesting: the SPIR-V immediate language.

I haven't finished reading the PDF [0] yet, but it looks like LLVM, but for hardware.

[0]: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf

When faced with similar confusion, I used "bound value" instead of "variable". I thought it might be better.

Interesting read would be here: http://doc.rust-lang.org/std/thread/

It is also guaranteed by ownership system: in the safe mode (which is default) rust will statically (at compile time) ensures that a value can only be mutated at a single execution point. It is done by moving, instead of copying any value _by default_, unless it is wrapped in some kind of synchronization primitive or implements a _Copy_ trait.

Synchronization primitives themselves are implemented in unsafe mode, thus limiting the unsafe code scope and allowing custom unsafe code which can also be wrapped in safe interface.

I think the JavaScript virtual machines are amazing. Thanks to browser speed wars, they pulled out a trick that I would not have thought possible - making JavaScript fast as hell.

Calling V8 "whatever monkey" is a bit ignorant.

Oh, I haven't said that JavaScript is a good language :)

That's why Rust is so important. It demonstrates that it is possible to drop to the lower-level concepts which do __not__ need GC for memory safety, and then build the "easy" abstraction on top of them.

I suspect that we will see more languages like Rust in future, because Rust has essentially proved the feasibility of the ownership model with working implementation.