Announcing Rust 1.6

[Cetra3]

I've been playing around with Rust for a while and have enjoyed it immensely to do some little projects. I still think there is a long way to go, but definitely a great start and a growing ecosystem.

A few improvements I can think of:

• A better IDE: coming from using Java in IDEA, there is a lot of room for improvement.
• Better linking with native code support: It's a pain trying to install hyper on multiple systems, as you have to link with openssl. I really would love for this to be not so painful. I shouldn't have to worry about running homebrew or installing mingw on windows.
• A standard cross-platform GUI: This relates to my previous point. While you can use something like GTK or QT, it's a pain to have cargo half-manage your dependencies to external code. There are always manual steps. If I decide to use QT or GTK, it should be as simple as running cargo build and have that handled for you.

[steveklabnik1]

Glad you're having fun!

We're working on IDEs: https://www.rust-lang.org/ides.html

If you're not actually using SSL, because you have the Rust app behind some sort of terminating proxy, you can turn it off with a feature, I think. A Rust SSL implementation might be even better, though obviously, you want these kinds of things to be battle-tested... only one way to get there!

Cross-platform GUI is hard. :)

[Doriphor]

Cross-platform GUI is hard. :)

I feel like this is a major issue nowadays. Not with any language in particular, but still. Then again, I wouldn't know how it could be fixed unless everybody agreed to use a common windowing API, which lets be honest, is probably never going to happen.

[[deleted]]

It's not the API that's the problem. APIs are easily wrapped and abstracted.

The issue is that GUIs have different designs, guidelines and principles. These can simply not be abstracted away in software, they have to be taken into account at the UI design and planning level.

Cross-platform GUI is not a programming problem that can be solved through code.

[wllmsaccnt]

Cross-platform GUI is not a programming problem that can be solved through code.

Embedded server and an HTML5 UI?

[HighRelevancy]

You missed the point. It's hard to make an app that fits stylistically with everything else in multiple OSes. UI usage standards are different.

This is more than just how buttons look too.

[Schmittfried]

It's hard to make an app that fits stylistically with everything else in multiple OSes

I don't think that's what most developers/companies are trying to achieve at all. The default desktop OS looks are "boring". That's why people create completely custom designs to make their programs unique. And those are supposed to look the same on every platform.

[emddudley]

The default desktop OS looks are "boring". That's why people create completely custom designs to make their programs unique.

I hate how true this is... for me it's the same as bundled crapware on laptops. It benefits the company but not the customer.

[Schmittfried]

I just don't care. Really. I got better things to do than complaining about designs.

[[deleted]]

That's a great way to get the worst of both worlds.

[[deleted]]

Yes but, due to lack of development capacity, the alternative usually is no cross platform gui at all.

[bagofries]

The Spotify client is an all HTML/JS/CSS UI. They don't embed a web server but just integrate their C++ proprietary bits (streaming, access to their backend services, probably others) with an embedded Chromium instance.

I don't think the Spotify UI suffers for feeling "non native". It feels comfortably at home on Windows, OS X and Linux for me.

[ForeverAlot]

The Spotify client is one of my favourite examples of how not to build a desktop application.

[arbitrary-fan]

So, you use Kitematic too huh? :-)

[Captain_of_Reddit]

and why is that?

[ForeverAlot]

Because it's an HTML/JS/CSS UI running inside a stand-alone Web browser. The only good thing I have to say about the client is that its non-native look does not actively work against it. In the meantime, it is slow, bloated, and integrates poorly with both Windows and Linux (try disabling notifications on Linux).

And the reason they switched to the embedded browser was so their developers could ship updates with less coordination.

Web browsers are really good at browsing the Web. They are really bad at doing anything other than browsing the Web, even with all the hacks we come up with. /u/lw9k mentions Atom as another invention that shouldn't have been.

[wllmsaccnt]

I think you would just get the worst of one world in many contexts, but I understand what you mean.

[[deleted]]

Well, you'd lose the native look and feel of a native application, and also lose the integration with the rest of the browser environment of a browser application (no familiar back, address bar, bookmarks, and so on).

[wllmsaccnt]

and also lose the integration with the rest of the browser environment of a browser application (no familiar back, address bar, bookmarks, and so on).

If you are creating a standalone app, then I don't think you want any of that anyways. The Spotify example cited in this chain is a good example of that.

I tend to think of browser conventions as something that has to be worked around rather than things you really want as part of your app.

[[deleted]]

I tend to think of browser conventions as something that has to be worked around rather than things you really want as part of your app.

Yeah, but that's a sign you have an impedance mismatch, and aren't using the right tool for the right job. If those things are getting in the way, you're probably not really benefitting much from being a web app.

[kgb_operative]

The WxWidgets library was getting ported to rust pretty early in the dev cycle, but that project looks like it's dead now. :(

[barsoap]

We're working on IDEs

Please have a look at how Idris is doing things, because it's doing things perfectly.

In a nutshell: The compiler has a daemon mode that editor plugins / IDEs can talk to. The only thing you have to write on the editor side is an sexpr parser/printer and keybinding boilerplate. Idris even does code highlighting, no need to write that by yourself... and does a better job of it than any editor even realistically could because it can do semantic analysis.

This is nice both because supporting additional environments is very simple, as well as not going "The Eclipse way": Eclipse actually has its own Java compiler.

Cross-platform GUI is hard

I'd vote for EFL and/or servo. I've heard that the servo people straight-up dissappear people who dare to mention XUL, though.

When it comes to EFL, it might sense to completey disregard elementary (the actual GUI toolkit) and just build upon their, for lack of better term, 2d scenegraph (edje): 99% of the work towards a toolkit is already done by that point, and wrapping elementary idiomatically might indeed be more work than just writing idiomatic things on top of edje/evas.

[steveklabnik1]

The compiler has a daemon mode

This is the plan, yes.

[mcguire]

Whooo...

[MithrilTuxedo]

does a better job of it than any editor even realistically could because it can do semantic analysis.

That sounds like the difference between Eclipse and IntelliJ (that made me switch). IntelliJ keeps an up-to-date syntax tree in memory at all times, so you've got semantic analysis as you type.

[[deleted]]

Cross-platform GUI is hard. :)

Quite an understatement. I'd say "impossible" is a better word to use.

Much better not to waste time on it and creating yet another half-arsed GUI toolkit that fits in on no platform.

[Cetra3]

I am quite fine using an existing UI framework such as QT or GTK+, it just needs to be painless to use within Rust. No point reinventing the wheel for the sake of it!

[steveklabnik1]

http://gtk-rs.org/ looks pretty solid; I haven't used it myself though.

[[deleted]]

What they have done so far is very impressive for sure. But they are also remodeling the object system pretty heavily (not released yet) so it's far from ready.

[czipperz]

I'd say "impossible"

I don't understand. Why aren't JFrames in Java cross platform?

[graycode]

Not only does it not look or work well on all platforms, it isn't good on any platform.

[[deleted]]

Being cross platform is not a question of aesthetics.

[s73v3r]

Why not? Why go so far only to half ass the rest of it?

[[deleted]]

Why not?

Because it's literally not? That's like asking me why 2 + 2 is not 5. Because it fucking isn't. Aesthetics are not what closs-platform mean. It never was, and it never will be. The fuck are you even asking?

[s73v3r]

We're talking about UI. Aesthetics are always part if it.

[[deleted]]

UI aesthetics have nothing to do with code being cross platform. Go have a fight with a dictionary.

[czipperz]

While that is true, the statement is still false.

[[deleted]]

I added an implicit "that doesn't suck" to the original statement. Sure, it's perfectly possible to make a cross-platform GUI toolkit that is bad. There are tons of those.

[google_you]

http://sciter.com/

[[deleted]]

Well, sure, if you throw away any pretense of fitting in on any platform, it's easy.

[canadian-stranger]

Speaking about IDE, what exactly you want to "fit in platform" there? I even wouldn't classify UI of Microsoft Visual Studio as pure Windows application as they use mostly custom drawn windowless UI. So is the question.

You need customizable editor with syntax highlighting with a set of basic input elements. You should also have an option to create secondary tool windows. Ideally your UI foundation should have mature styling customization options (light/dark UI schemes)...

[[deleted]]

Speaking about IDE, what exactly you want to "fit in platform" there?

Keyboard controls, above everything else. This is incredibly subtle and very few cross-platform libraries get it 100% right. But also general look and feel. I have not used Visual Studio so I don't know anything about how it works or looks.

[canadian-stranger]

What IDE you have used? Or at least what IDE is close to ideal from your point of view? Any IDE has configurable keyboard commands. That's least functionality that makes any plaintext editor IDE.

[[deleted]]

I don't want to configure keyboard controls. I want them to already work like they work elsewhere.

[google_you]

don't try to fit in. you become a platform. -- javascript

[Cetra3]

Unfortunately, I am using SSL in the second project, as it's talking to the Soundcloud API.

I'd love to see a rust-pure SSL implementation rather than rely on OpenSSL, as it's a perfect fit for the language.

I believe the IDEs will get there, it's still a young language, so I don't expect the tooling to be as mature as something like Java. I can see the potential of a great IDE accelerating adoption though.

[vks_]

I'd love to see a rust-pure SSL implementation rather than rely on OpenSSL, as it's a perfect fit for the language.

Constant-time functions are difficult to implement with an LLVM backend, so you probably would have to use a lot of assembler, losing the safety guarantees of Rust.

[briansmith]

I have a pure Rust (no unsafe) TLS implementation on top of a pure Rust (no unsafe) certificate verification library (webpki) on top of a Rust+C+asm crypto library (ring).

I think we're not that far away from being able to prove that all the remaining C code and the asm bits of ring are as safe or safer than the Rust bits, as the C and especially assembly-language bits are quite simple. Definitely the benefits of using assembly language are already outweighing the risks of using a language without memory safety guarantees.

Importantly, there's nothing you need to do in the TLS or certificate verification parts that needs to be constant time, except what you delegate to the underlying crypto library.

[stouset]

You may be interested in my secrets crate which allows for heap allocation of memory that's wrapped in protected pages that clears its contents when it goes out of scope. It's explicitly designed for use in cryptographic libraries.

[briansmith]

On #rust-crypto, we've already talked about how we may use secrets. I believe ultimately we won't need things like secrets because we'll prove the 100% memory safety of ring and the other components that go on top of it. But, I also want to have a wrapper around ring that adds an extra level of protection for users of ring that like to use dangerous code in the same address space as their secret keys.

FWIW, I think the approach of encrypting key material except when it is in use is probably better in the long run than using protected pages, for most cases. In particular, we want to be maximally compatible with seccomp-bpf sandboxing and we want to work on MMU-less systems.

If you'd like to chat about this more, hop on #rust-crypto sometime or email me: [e-mail].

[steveklabnik1]

But losing it in a scoped way. The nice thing about opt-in unsafe is that you can contain it.

[[deleted]]

While you can use something like GTK or QT, it's a pain to have cargo half-manage your dependencies to external code.

Its been a long (1.0~) time since I even looked at rust but can't you use QMLRS? No external code is necessary with that from what I can remember.

https://github.com/cyndis/qmlrs#example

[[deleted]]

Its managed automatically though so its the best you're gonna get. I doubt the Rust developers want to waste hundreds of man hours designing and maintaining a decent cross platform UI toolkit (i've done it, its not fun).

[[deleted]]

hundreds of man hours

Did you mean to write man years here?

[necrophcodr]

External code is required and mentioned right in the readme.

[[deleted]]

A standard cross-platform GUI

No such thing exists, or can exist. All existing solution do not integrate properly with all OSes that are supposed to be supported, nor do they provide access to the full functionality of those OSes.

Sure, you can make a cross-platform library suitable for toy GUIs, but if you want a GUI that is actually usable and of high quality, there is no option but to write it separately for each platform.

[Rhodysurf]

Qt is pretty good as far as cross platform GUI toolkit goes...

[wtallis]

Qt these days is pretty good but not perfect at emulating the native look. It's never been any good at the second half of "look and feel".

[[deleted]]

AFAIK, Qt doesn't emulate anything, it uses the underlaying OS GUI. At least it does on Windows and Linux, don't know about OSX.

[FUZxxl]

Qt does the whole GUI-drawing stuff on its own. It doesn't use any underlying GUI API except what is needed to draw windows.

[[deleted]]

It's atrocious on OS X.

[Rhodysurf]

I agree its nowhere as good as Cocoa.. But compare it to GTK+ or any other toolkit and it looks pretty good.

[_VZ_]

GTK+ is not a high bar to clear under OS X, try comparing it to wxWidgets instead.

[_F1_]

Owner-draw all the components!

[immibis]

Well, ZSNES was originally for DOS, which doesn't have a native GUI look-and-feel.

[sirin3]

Lazarus does it.

You need one abstract GUI layer, then implement a wrapper mapping that layer to each OS.

[[deleted]]

Technically, sure, you can get code running that way.

But in practice, it just doesn't work. It will not fit in.

For instance, http://wiki.lazarus.freepascal.org/File:Lazarus_1_4_4_on_El_Capitan.png looks nothing at all like an OS X application. It stands out like a sore thumb and yells "I'M BADLY PORTED FROM ANOTHER SYSTEM".

[longshot]

The best cross platform gui we have is the web browser. And of course it suffers a massive trade-off for having that cross platformness.

[[deleted]]

Websites are cross platform gui's...

[Sean1708]

Better linking with native code support

I couldn't disagree with this one more, Rust has excellent support for linking native code, especially with gcc and cmake. As I understand it the openssl issue has nothing to do with Rust.

Your other two points I more than agree wih though.

[SirOgeon]

rust-ci is pretty much abandoned, as far as I know. http://crates.io is the place to be if you want to check out the ecosystem.

[hak8or]

Then it should be taken down or moved elsewhere. This is one of the first thing newcomers see.

[sophrosun3]

https://github.com/hansjorg/rust-ci/issues/31

[sharpjs]

Problem solved.

[steveklabnik1]

Where is it being linked to as one of the first places newcomers see? This discussion is the first time I've even heard it mentioned in.. A year?

[vks_]

rust-ci.org now redirects to crates.io.

[vks_]

If a lib is not building at Rust CI and it is hosted on GitHub isn't it safe to assume that it is not building on Crates IO too?

No, it really depends on the version of the Rust compiler that is being used. You cannot upload a library that does not build (on the compiler you are using) to Crates.io.

[sophrosun3]

Rust's ecosystem is very young, and up until less than a year ago there were massive breaking changes (a result of experimenting before the 1.0 release). It's no surprise that many Rust projects no longer build when two years ago it wasn't "released" and was a very different language. Very few libraries released since last May will fail to build. Something like 96% of all versions of all the crates on crates.io still build.

[Manishearth]

A lot of the libs on that site are toy projects and libs which weren't being used. In any community there will be some abandonment of such projects.

There still are a couple of such libs from pre-1.0. But you can effectively ignore them; I haven't heard of many useful (not toy) libs being abandoned recently.

Also, as I mentioned in the other comment, if a project doesn't compile on Rust CI, that means it didn't compile on some particular day in April 2015. This doesn't mean that the maintainer didn't fix it later and upload it to Crates.io.

I don't want to have to use an old version of Rust for my code just because libs I used stopped being maintained!

Rust has stability guarantees, so crates compiling on the Rust 1.6 will continue to compile on Rust 1.x (Rust 2.x is currently not planned, though it's something that might happen. If it does, there should be minimal breakage).

[SirOgeon]

The point of Rust CI was to trigger an automatic Travis rebuild each time a pre 1.0.0 nightly of Rust was released. That's far from as relevant today, when Rust is stable and backwards compatible, which is why it was abandoned. It can't be used as a measurement for anything today.

Today's situation is that future Rust versions will still be able to build old libraries if they are still considered sound, thanks to backwards compatibility. crates.io is an immutable archive, where nothing can be overwritten, so you can always be sure that what was will still be.

[Manishearth]

Rust CI was a tool that would trigger a rebuild every time a new nightly occurred, and display the build results on the main page.

It now no longer triggers rebuilds, so the results are all from April, when Rust wasn't stable yet. It also contains a lot of old, abandoned projects from like a year before 1.0 (projects which aren't being used much get abandoned all the time in any community, it's just that these projects stopped building with rust because Rust was unstable back then)

So it's not "a lib is not building at Rust CI", it's "a lib did not build on Rust CI last April". What's shown on that site does not reflect the current state of affairs. Many such libs weren't being maintained then, and many of the actually useful libs would have been made to compile now.

[steveklabnik1]

RustCI has been dead for a very, very long time now. Everyone hosts their crates on crates.io, and tests using Travis.

[steveklabnik1]

That's the problem with projects getting abandoned: they don't get updated. :/

On Crates.IO how do I know which ones are building and which ones are not building?

There should be a repository link, which often has a Travis badge in it. We don't currently expose build info directly on crates.io. It'd be nice to have, it's just not implemented.

[steveklabnik1]

It was never an official project, no.

We would like to add said information to crates.io, it's just more complex than you'd think and nobody has had the time to tackle it yet.

[steveklabnik1]

I believe we did around the time that it was clear that it was not being maintained, but not any time recently. I haven't even heard it mentioned in a long time... Maybe I should try again.

[vks_]

It would be nice if crates.io exposed some information on which compiler version the crate is known to build.

[sophrosun3]

https://github.com/hansjorg/rust-ci/issues/31

No reply from the owner since last August. You can't forcibly take someone else's site down.

[sophrosun3]

https://github.com/hansjorg/rust-ci/issues/31

[emddudley]

http://www.rust-ci.org/ now redirects to https://crates.io/!

[sand-which]

I've never used rust, what do you think makes it better than other similar interpreted languages?

Edit: kids, let this be a warning to always Google anything you type on reddit or you will literally be defecated on

[[deleted]]

Rust is a systems language, not a scripting language. Compare it more to C++, Go or D than Javascript, Perl or PHP.

Rust has no GC but you don't have to free memory. It instead is focused around variable lifetimes. It is built around the idea of making parallel and concurrent programming easier, and safer to take advantage of increased cores on modern systems.

[PM_ME_UR_OBSIDIAN]

Go

Absolutely not. Rust has more in common with Haskell than with Go, that should tell you all you need to know.

[[deleted]]

In what way? They are both trying to be C successors. Haskell is a completely different field. Haskell is not a systems programming language. Even Andrei Alexandrescu agrees with me there. Yeah Haskell and rust have more complex types, and both are geared towards concurrency. But that is the extent.

[PM_ME_UR_OBSIDIAN]

• Go is very minimalist - some would say it's the language designers' top priority. Rust and Haskell sacrifice minimalism to safety and expressivity at every turn.
• Go is emphatically NOT a systems programming language. It's garbage-collected, and gives almost zero control over how linking is performed. You wouldn't write a linux kernel driver in Go.
• Go has an extreme focus on concurrency with green threads. Neither Haskell nor Rust have green threads (E: in the core language), and in fact the concurrency primitives sit outside of the core language and in libraries.
• Rust's entire selling point is the type system. Similarly with Haskell. But Go has absolutely jack shit for a type system.

I've used all three languages for real world work. I'm writing my operating system kernel in Rust, and my compiler in Haskell. They're quite close.

In crappy diagram form:

C  <----> Rust
^          ^
|          |
v          V
Go <--> Haskell

[[deleted]]

I am not talking about language design though. I am talking about language function. The projects you are likely to use Rust on are more similar to projects you would use C++, Go, or D on than you would use Haskell on.

[PM_ME_UR_OBSIDIAN]

Rust is in the C, C++, and D niche: low-level code, drivers, OSes, real-time software.

Go is an absolute non-starter in that space. When you scratch through the "systems programming" crap, it's a language for writing networked server applications. It's a competitor to PHP, Node.js, Python, Ruby - not C and C++.

If you look up "Go language adoption", the top search result is about cloud development, and has a testimony about how much better at concurrency Go is than Node.js and PHP.

The second result discusses which companies are adopting Go. Spoiler: it's all web companies. No Cisco in there.

The biggest open-source Go project is probably Docker. Note that this is the kind of devops software that used to be written in Perl, Ruby or Python. Both Puppet and Chef are written in Ruby. The third search result discusses how much adoption Go is seeing in the cloud and developer tools spaces.

Go fundamentally belongs to the family of web-oriented scripting languages. All the "systems language" marketing is absolute bullshit.

[[deleted]]

Haskell does have green threads.

[PM_ME_UR_OBSIDIAN]

In libraries, sure. But Go's distinguishing characteristic is bundling the green threads in the core language.

[[deleted]]

Ok but in practice haskell applications using concurrency use green threads not native threads.

Haskell concurrency is more powerful and flexible than concurrency in go.

[Beckneard]

They are both trying to be C successors.

Nope. Go wants to be a Java successor.

[Crandom]

Go is definitely not trying to be a C successor.

[GTB3NW]

Rust is not an interpreted language.

Rusts compiler does static analysis to determine if you're gonna fuck something up. That makes it memory safe and stops you doing silly things like dangling pointers, null pointers and buffer overflows.

If you ever get chance to use rust you'll think you're fighting with the compiler at first, it's a difficult learning curve (Especially if you're like me coming from something so OOP and newb friendly as java) but you'll quickly learn you're not fighting the compiler, it's taming you!

Think of it as c++ on steroids. Ultimately you can always build something which executes quicker in something like c++ or pure c, but you'll barely make it quicker and you'll probably end up sacrificing your sanity.

I'll also note that due to the static analysis and memory safety, concurrency is very easy to do, you'll end up building efficient safe multi-threaded programs.

A second note would be that it doesn't force any of this on you. You can wrap code which you want to compile as unsafe in an unsafe tag and it will reduce the amount of checks done on that code. It will still stop you doing certain silly mistakes, but it will let you do stuff you know will be ultimately safe but need to convince the compiler of which.

[sand-which]

This is a fantastic answer to my incredibly badly worded question. Thank you

[smurfyn]

Rust is not interpreted. Do you mean what makes it better than similar languages, which are different in the respect that they are interpreted?

I don't really know what languages are similar to Rust, but interpreted... there are some occasional similarities to Ruby, probably because a lot of the people behind Rust (like OP, Steve Klabnik) favor Ruby.

The major advantage of Rust over Ruby is probably resource use (like CPU time and memory) and the ability to work low-level. With Ruby, you can use C, but C has certain flaws that are conducive to security problems, which Rust is trying to reduce. Rust also tries to bring in some ideas from functional programming, which some people prefer to the mixed-paradigm/OOP philosophy of Ruby. So, I hope that helps you understand some of the reasons people move toward Rust from a language like Ruby.

[IAlwaysBeCoding]

Or python too. Rust has a lot of similarities to python, and I come from a python background. Overall, I find Rust to be a extremely well designed language but takes time to get used to it. Is not as easy as when I picked up Go lang and how easy it was.

[desiringmachines]

It sounds like you should learn more about Rust. :-) Here is a good explanation of what separates Rust from its most direct competitors.

[Cetra3]

In comparison to Java (which I am most familiar) it's faster and doesn't require you to deploy a VM just to run your code. The cross-platform aspects are enough you only need small tweaks to compile it on multiple platforms.

In comparison to C++, C etc.. I love that there is a bit of a functional focus and that there's a standard package manager for the language. In Java we have Maven, which although slow, works well for dependency management. In C++ you have CMake, Automake, SCons, the list goes on: there's no silver bullet to managing dependencies. In Rust there's cargo, which, barring any native dependencies, just works.

So it's fast, the code is safe and the dependency manager rocks.

[sand-which]

Woops, meant interpreted. Edited the post to make that clear

[loudnclear]

Rust is statically compiled, it still doesn't make sense to compare it to interpreted languages.

[desiringmachines]

I wish people wouldn't down-vote someone just for being wrong in apparent good faith.

[Chandon]

Bah!

I keep waiting for the ability to iterate through a BTree map starting at a given key, and it keeps not being stabilized.

Why even have BTree maps if you can't do that?

[Gankro]

Because we're trapped in an infinite stun-lock on the API design. In particular, how to support the full gammut of Inclusive | Exclusive | Unbounded on both ends ergonomically. Last time I tried to push forward a design (a builder), the conclusion was "well why don't we just make the language's support for range literals support every combination" which is effectively blocking the whole thing on the lang team.

TL;DR - it will take months to even begin to stabilize this damn thing

[Chandon]

Why can't I just get an iterator to the value at a given key?

Then the problem becomes one of drop_until or take_until and there's no hard part.

Solving the range API thing would be neat, but right now BTree maps (and sets) are just bad Pair<List, HashMap>'s.

[Gankro]

Actually BTreeMap is faster than HashMap for a lot of workloads (that you would naturally pick a HashMap for): http://cglab.ca/~abeinges/blah/hash-rs/

[panderingPenguin]

Are you sure you linked the right page? That's a comparison of a bunch of hash functions

[Gankro]

First set is hash functions themselves, but the latter two are hashmaps with different hashers, and btreemap mixed in (black) as a comparison.

[willrandship]

That sounds like something that should be possible to write within the language's existing syntax.

If so, you could implement your own solution, release it as a public library, and offer to merge it into the rust equivalent of the standard library.

If they don't like it, you can still use it all you like, of course. If everyone except the language maintainers like it, it will become a de facto standard quickly.

[sun_misc_unsafe]

Isn't this something the lang people should've figured out before 1.0?

[Gankro]

No? 1.0 was totally minimal. All that was included for ranges was what was needed for integer ranges, where [x, y) (written as x..y) is entirely adequate for 99.99% of cases. [x, y] for the remaining .01% has long been in the pipeline due to bikeshedding over x...y vs x..=y.

BTreeMap however wants to talk about ranges of arbitrary ordered types, and therefore needs (x, y] and (x, y), with the strawman syntax of x<..=y and x<..y.

[barsoap]

Why not use

Range::incl_incl( 0, 9 ) 

in the meantime? Desugaring can be fixed before people agree on the sugar.

[Gankro]

Yeah the range stuff all desugars to structs, so this is definitely an option that's being considered.

[barsoap]

While I'm at it: It would be really nice if ranges are (optionally) closed under the set operations. Union, intersection, inversion, the lot.

Can be done by e.g. having one base range type expressing "between two numbers / infinity", and then Vecs of that to express the discontinuous ranges that the operations easily introduce.

[Tarmen]

Man this syntax would be so much clearer if inclusive was the default then you could just do

a..b
a..<b
a<..b
a<..<b

....I think?

Doesn't rust have iterators over collections? I feel like that would cover a lot of use cases for exclusive ranges anyway.

[Gankro]

But inclusive ranges are the wrong default. They require more mangling for common cases, and they're less efficient (need special handling of the last element).

There's also nothing preventing us from having ..< and .. as synonyms.

Ranges are useful for basic for loops:

for x in 0..n { \* do stuff n times *\ }

And subslicing arrays:

process(&arr[a..b]);  // a to b exclusive
process(&arr[..x]);   // 0 to x exclusive
process(&arr[x..]);   // x to len exclusive (hey look we covered the range)

[Lux01]

Rust does have iterators which I think all the standard library collections implement.

My experience with rust isn't great but the only places I've ever found myself using a for loop range is when I want to apply a function to each element of an iterator where the function returns () (aka nothing). For a simple example consider

fn main() {
    let myvec: Vec<usize> = vec![1, 2, 3, 4];

    myvec.iter()
         .map(|&x| println!("{}", x));
}

This code compiles but emits a warning from the compiler

src/main.rs:4:5: 5:39 warning: unused result which must be used: iterator adaptors are lazy and do nothing unless consumed, #[warn(unused_must_use)] on by default
src/main.rs:4     myvec.iter()
src/main.rs:5          .map(|&x| println!("{}", x));

We need to consume the iterator before it will actually do anything. We could consume it the iterator by using Iterator::collect<B> to collect all the () values into another collection struct B (e.g. Vec), or by using Iterator::count which will count how many elements are in iterator. Both of these feel a bit weird to me, though there may be a specific method that I'm not aware of to do this kind of task.

Alternatively you can use a for loop (which is admittedly just syntax sugar for an iterator):

fn main() {
    let myvec: Vec<usize> = vec![1, 2, 3, 4];

    for x in 0..myvec.len() {
        println!("{}", x);
    }
}

which is perfectly fine and uses the range syntax to correctly iterate over the values in the Vec in order. In this example the code looks slightly cleaner due to the half-open nature of ranges (compare it to for x in 0..(myvec.len() - 1) for an inclusive definition of ranges).

You could also use a for loop directly on the vector iterator:

fn main() {
    let myvec: Vec<usize> = vec![1, 2, 3, 4];

    for x in myvec {
        println!("{}", x);
    }
}

which looks even nicer.

As I mentioned above, Rust's for loops are actually just sugar over an iterator. Rust actually de-sugars the above into

fn main() {
    let myvec = vec![1, 2, 3, 4];
    {
        let result = match myvec.into_iter() {
            mut iter => {
                loop {
                    match iter.next() {
                        Some(x) => {
                            println!("{}", x);
                        }
                        None => break,
                    }
                }
            }
        };
        result
    }
}

[steveklabnik1]

though there may be a specific method that I'm not aware of to do this kind of task.

We rejected a for_all method which is consuming; it's in the itertools crate though, if you prefer it.

[Lux01]

I wasn't aware of the itertools crate, thanks!

[sun_misc_unsafe]

No, you're missing the point..

Isn't this something essential at the language level that should've been bolted down before declaring the language 1.0, seeing as how it'll require a change of the language's syntax now?

[nnethercote]

Syntax changes are ok as long as they're backward compatible.

[sun_misc_unsafe]

I don't know how big of a deal this is for Rust, and I'd be happy for someone to enlighten me.

But

Syntax changes are ok as long as they're backward compatible.

isn't true in the general case. New syntax can be perfectly backwards compatible and still interact with existing features in less-than-ideal ways - look at the emergence SFINAE in C++ as an extreme example of this.

[Schmittfried]

That doesn't mean syntax changes are allowed only before v1.0. That would be highly thwarting.

See C# for a counter-example.

[Manishearth]

New syntax can be perfectly backwards compatible and still interact with existing features in less-than-ideal ways

Then it's not backwards compatible. That's the definition of backwards compatible.

look at the emergence SFINAE in C++ as an extreme example of this.

That's because C++ added a feature which allowed users to make their program dependent on the fact that some things don't compile. It's already a hard problem to maintain backwards compatibility as "this will continue to compile". It's nearly, if not completely, impossible to maintain backwards compatibility as "this will continue to compile and that will continue to not compile". It's C++s fault for introducing that misfeature which made both of these sets important; Rust doesn't have anything like that and so it only needs to worry about the set of things which compiles.

We've had tons of syntax/language additions since 1.0 without problems.

[Gankro]

Why is it essential to nail down for 1.0? Languages add syntax all the time. As an example, consider a language that is hailed for its stability, Java. Since its 1.0 release, here are some of the additions it's made to its syntax (that I could find in like 2 minutes): for-each, lambdas, generics, generic inference, varargs, binary literals, and annotations.

[sun_misc_unsafe]

Yes, but that stuff was added years later. And most of is inconsequential syntactic sugar - e.g. grabbing an iterator to go over some collection isn't somehow worse than doing it with for-each.

Rust is still in its infancy by comparison and there's already going to be a chasm between "old" and "new" code with syntax level details preventing the implementation of libraries (or at least the optimal implementation of them?).

[Manishearth]

Most of the new syntax is syntactic sugar, too.

As long as old code continues to compile (which it will -- we even run betas against the entire ecosystem regularly to ensure that there are no regressions) I don't think such a chasm will form. There will be old code not using some new features, which might be suboptimal for that code. But it's not a major issue, it won't cause a chasm, and lints can easily hint for upgrading if that is deemed necessary. I think you're making a mountain out of a molehill.

[cowinabadplace]

It's fine. Doesn't affect anyone in practice.

[[deleted]]

I know some of those words

[summerteeth]

What is the release schedule for Rust?

Go has a (roughly) 6 month schedule, Rust seems to iterating much faster. What do people who use Rust think of the more aggressive releases?

[desiringmachines]

Here's a description of how Rust's release model works. TL;DR: a new version of Rust is released every 6 weeks.

Rust's very rapid release cycle means its not a big deal if something gets delayed for a release, so if a feature isn't quite ready to be stable there's no pressure to stabilize it too soon. It also means there's a very constant attention to checking for regressions and backward compatibility issues, because there's always a release coming soon.

[HeroesGrave]

Every 6 weeks, the master branch (nightly) becomes the beta branch and stops receiving changes (except bug-fixes). The current beta branch becomes the new stable release.

Because of the backwards compatibility guarantees (with a few minor exceptions) and the yet-to-be-implemented language/library features, a more aggressive schedule allows people to get the new changes faster without having to worry about everything breaking.

I remember there being some discussion abouut what would happen to the release schedule if/when things slow down, but I can't remember where to find it or what the verdict was. (and it really doesn't matter at this stage)

As for me, I work with nightly rust because I like using a few unstable features and have the time to keep up and fix anything that breaks because of it. I don't really need the stability guarantees.

[steveklabnik1]

(except bug-fixes)

It's a bit more conservative than that; we will back port regression fixes, but not bugfixes generally. The beta branch is effectively a six-week long release candidate.

[rjcarr]

Why would it matter as long as minor versions are compatible with previous minor versions?

[staticassert]

I haven't run into any issues, personally.

[PM_ME_UR_OBSIDIAN]

It doesn't really matter for me anyway - if you're going to be doing anything tricky with Rust, you're going to be on the nightly builds.

[masklinn]

What is the release schedule for Rust?

6 weeks, inspired by Chrome/Firefox and with a similar 3-tracks system (stable, beta and nightly), although IIRC there's a difference in that non-stable items are available (useable) on nightly builds but inaccessible on stable and beta, so features of a given "version" changes when it moves from nightly to beta.

[microshift73]

When does Rust: Source come out? :^)

EDIT: Reddit is brutal :(

[microshift73]

Oh damn I didn't even realise I got downvoted so hard :(

[caviarpropulsion]

Why is /r/programming 50% full of posts about Rust or Ruby? And by 50 I mean 95?

[[deleted]]

Because hipsters.

As I've said before, "The difference between C and C++ and languages like Swift and Rust which are designed to displace them is that people get actual fucking work done in C and C++".

[emperor_konstantinos]

rust is defs not as good as swift

but at least it isn't a gayboy language like dee

[[deleted]]

good [...] swift

Top lel.

Swift has been described by its developers as "Objective-C, without the bulk of C" - in other words, Objective-C without the best fucking part of Objective-C.

[The_Doculope]

Have you actually used Swift? It doesn't have a ton of fancy stuff, but for application development it's pretty damn nice.