Rust 1.0: Scheduling the trains

http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

by steveklabnik • 12 years ago

330 183 12 years ago

seren• 12 years ago

What is the roadmap after 1.0 ? Is it going to evolve quickly ? Or will it be the right time to join since things are going to be more stable ?

My question sounds obvious but depending on the project 1.0 can mean very different things.

arthursilva5• 12 years ago

Something in the middle, check this post http://blog.rust-lang.org/2014/10/30/Stability.html

kibwen20• 12 years ago

1.0 only means "code that you've written against a stable release won't break on future stable releases". Rust will still be evolving quickly for quite a while, though we'll at least be free of this nonstop update-your-broken-code treadmill that we've been on for years. :)

scanr4• 12 years ago

I really, really hope that abstract return types make it in or are not considered a breaking change for a future release:

https://stackoverflow.com/questions/26329231/returning-a-sim...

https://github.com/rust-lang/rfcs/pull/105

arthursilva5• 12 years ago

Since it's not a breaking change it's not coming in 1.0, probably shortly after it though.

kzrdude5• 12 years ago

it looks like a breaking change, say if you change the return type of `fn iter()` on a slice.

kibwen20• 12 years ago

Anonymized return types will sadly not be a blocker for 1.0, though they will be an enormously high priority post-1.0.

In particular, the biggest pain point for the lack of anonymized return types won't be the use case mentioned in that SO thread (which is heinously ugly and leaks implementation details, but at least it's possible), but will rather be the fact that without anonymized return types it will be impossible for a function to construct a closure and then return that closure without stuffing it into a box (though note that it will still be possible for functions to return unboxed closures if it accepted that closure as a parameter to the function).

scanr4• 12 years ago

Great to hear that folk are aware of this and that it's not considered a breaking change for a future release. Where is the best place to get updates on these kinds of features? I was following the github ticket until it closed and it wasn't clear where to go afterwards.

aalvarado2• 12 years ago

Yup, seeing method signatures like these is discouraging:

``` core::iter::Zip<core::iter::FilterMap<'_, (&std::collections::hash::set::HashSet<attr::Attribute>, &attr::Attribute), &attr::Attribute, core::iter::Zip<core::iter::Repeat<&std::collections::hash::set::HashSet<attr::Attribute>>, core::iter::Map<'_, (&attr::Attribute, &()), &attr::Attribute, std::collections::hash::map::Entries<'_, attr::Attribute, ()>>>>, core::iter::FilterMap<'_, (&std::collections::hash::set::HashSet<attr::Attribute>, &attr::Attribute), &attr::Attribute, core::iter::Zip<core::iter::Repeat<&std::collections::hash::set::HashSet<attr::Attribute>>, core::iter::Map<'_, (&attr::Attribute, &()), &attr::Attribute, std::collections::hash::map::Entries<'_, attr::Attribute, ()>>>>> ``

kibwen20• 12 years ago

Ha, we hate them too, which is why we're so eager to finalize their design so that we can replace all of that hideous garbage with just `impl Iterator`. :)

And who knows, it might happen for 1.0 if enough people push on the design and are willing to put in the legwork of implementing it.

jimbokun3• 12 years ago

What is that, if I may ask?

bjz_3• 12 years ago

This is a huge ergonomic issue that the team is very aware of. There are plans to fix it post 1.0.

asb2• 12 years ago

I do wonder if Rust 1.0 is being branched just a little bit too early. I understand that you have to draw a line in the sand somewhere, and the rolling release model means new features can be rolled out quickly. On the other hand, I'm rather disappointed that the ergonomics of error handling may change substantially after 1.0. This is something that is going to affect every single Rust program written, and people may be surprised if 'the best way' to do this changes after 1.0.

https://github.com/rust-lang/rfcs/pull/243

saosebastiao3• 12 years ago

I worry about that too. In addition, I haven't seen any confidence that HKT can be implemented in a backwards compatible way, and that is one of the most-requested features (along with Async IO). I would hate to have to wait around for a 2.0 for this stuff.

kibwen20• 12 years ago

  > I haven't seen any confidence that HKT can be implemented 
  > in a backwards compatible way

Because nobody has ever managed to propose a design for HKT. How can you possibly future-proof against a feature with no clear idea as to its shape?

kibwen20• 12 years ago

There's always going to be some feature that would make something nicer and that seems worth waiting for. At the limit we'd be holding off 1.0 until Rust has higher-kinded types (which has never had a concrete proposal nor is anyone really sure it can be incorporated nicely with the rest of Rust's type system), and that's a feature that would absolutely change the paradigm of error handling overnight.

The time is soon. I as much as anyone want error handling to be flawless, but I don't think that's enough of a reason to hold back the rest of the language. If we have to evolve our approach to error handling a ways down the road, so be it. Other languages have endured similar paradigm shifts.

However, this issue will be inherently subjective... all I can say for sure is, if nobody at all were saying "no, it's too early!", it would certainly be too late. :)

asb2• 12 years ago

I do get that, but the distinction I'm trying to make between a feature like this and HKT is that you would expect changes in this area to impact practically every Rust program in existence, while the same is not necessarily true for HKT. Sure the changes can be made backwards compatibly, but it still means that the definition of 'normal Rust code' will be quite different, which people may find odd for a language that just hit 1.0.

Ultimately I do appreciate reaching 1.0 is a difficult set of tradeoffs and everyone has their pet feature they're sad isn't going to make it in. Bring on 2.0!

aturon4• 12 years ago

We do plan to add some version of this RFC, but made a careful decision about not including it for 1.0. It will not completely change the error-handling design, but rather empower it with additional, finer-grained control.

It's possible that we will add at least the `?` notation to replace `try!` before 1.0 final; it remains to be seen.

pcwalton6• 12 years ago

I do wonder if Rust 1.0 is being branched just a little bit too early.

Rust has been going as a project for five years.

Jweb_Guru• 12 years ago

It doesn't follow that it's not branching a bit early. Especially since the language five years ago bore little resemblance to what it is currently. I understand the justification that if Rust waits too long it will become irrelevant, but there are certainly plenty of reasons to think it should hold off. For example, the macro system is going to need to be completely rewritten after 1.0.

MichaelGG4• 12 years ago

My pet change is making an "uncaught " panic turn into an abort. Rust has the default behavior of silently discarding panics, for whatever reason.

kibwen20• 12 years ago

Can you elaborate? A panic is a panic, and it will either unwind or abort if unwinding is interrupted with a second panic. There's nothing silent about that.

deathanatos• 12 years ago

Are they really ready for a 1.0? I'm looking at the standard library, and things (or core functionality of things) like file-system I/O, vectors, strings, _iterators_ … are marked as "experimental"; I was particularly curious as to how they were going to deal with iterators, since I think this is a particularly hard problem. (In many languages these are either pointers (C++) or close to it.¹)

I wouldn't really consider a language without a standard library "complete", and a good standard library is important to me in a language. (As it's going to help you get stuff done.)

¹Python, for example, doesn't specify iterator invalidation rules AFAICT; you just have to look at what CPython does. And in CPython, there are ways to make an iterator return a sequence of items that does not make any sense. (e.g., the same item twice, or skipping items…) In C++, invalidation is well-specified, but the compiler doesn't really help catch errors.

steveklabnik13• 12 years ago

1) in general, Rust 1.0 is about language stability. This means that any library not of quality will be pulled out.

2) this means Rust will have a small standard library. But we already have Cargo. So you end up getting lots of packages, they just aren't built-in: they require adding one line to a config file instead.

3) iterator invalidation is a compile-time error in Rust. Rust relies on Iterators quite heavily.

aturon4• 12 years ago

I completely agree that a strong standard library is essential, and we've been working very hard over the last months to set explicit conventions, revamp APIs, and generally get Rust's standard library into a 1.0 state.

You shouldn't read much into the "experimental" tags right now; they're part of an API stability tracking system that is heavily in flux at the moment. In particular, for most of the modules you mentioned, only the module name itself has not been marked "stable", while the contents have been. For example, if you look at the Vec type itself:

http://static.rust-lang.org/doc/master/std/vec/struct.Vec.ht...

you'll see that most methods are unstable or stable, rather than experimental. (The "experimental" status is currently the default, to help us keep track of API "stabilization" progress.)

This stability tracking is part of our general story about API compatibility; you can read more at

http://blog.rust-lang.org/2014/10/30/Stability.html

These markers won't take on their full meaning until we ship 1.0.

For 1.0, all of the APIs you mentioned will be "stable", and indeed most of their internals already are. Over the next few weeks, we'll be updating stability markers to reflect the API scrutiny and design work that we've been doing.

More generally, for all but a couple of the modules listed at

http://static.rust-lang.org/doc/master/std/index.html?search...

we have already performed a detailed scrutiny of the API, and have either landed changes needed for 1.0 or will do so very soon. Most truly experimental APIs have already been deprecated or removed.

For IO in particular, you can read a very recent RFC that proposes the final set of API changes for 1.0:

https://github.com/rust-lang/rfcs/pull/517

Hope that helps!

Sir_Cmpwn8• 12 years ago

I'm getting less optimistic about Rust. At first, I liked that they were willing to make breaking changes pre-1.0 to get the language right. However, leading up to 1.0 they've decided to leave cruft in, in the name of getting the release out.

For example, the current build system is functionally equivalent to #including a bunch of C files in your C project and only passing one file to cc. I brought this up and had a long discussion about it and how it might be improved with the community, but then when core contributors showed up, the discussion was shut down with the justification that "1.0 comes in a month". I've heard other stories about poor management of the project and I'm just not as excited about Rust as I used to be.

steveklabnik13• 12 years ago

I'm... not sure what you mean by this. Something like #include technically exists, but is absolutely not used everywhere, and is certainly not the 'default build system'.[1]

Where was this discussion held?

1: http://doc.rust-lang.org/std/macro.include_str!.html is what I'm thinking of here.

ddevault• 12 years ago

"Functionally equivalent" to, not identical to. I'm talking about the module system. You could literally replace any instance of:

    mod mod_name;

With:

    #include "path/to/mod_name"

and then run it through the C preprocessor and it'd work exactly the same.

The discussion was held on IRC.

fngegngkg• 12 years ago

Agreed. At this point Rust is already looking rusty. A solution desperately searching for a problem. We need something to replace C (so we are told), but maybe Rust won't be that tool.

throwawayanonon3• 12 years ago

The C and C++ hate comes mainly from web developers and language hipsters. They dominate the echo chambers of HN and /r/programming.

When you mention you are a C programmer or like coding in C, they begin to blabber about C being legacy, Rust this, and Go that (languages they think are more like Python). All in an effort to cope with the insecure feelings they have because the C programming language and C++ (read: pointers) intimidate them.

pcwalton6• 12 years ago

" A solution desperately searching for a problem. We need something to replace C (so we are told), but maybe Rust won't be that tool."

As someone who works with Rust on a daily basis to implement a browser engine, I can confidently say that Rust is not a solution in search of a problem for our domain. As an example, I implemented CSS "letter-spacing" the other day, and it worked first try after compiling. The layout code I write has a remarkable resilience to crashes; in the rare cases that it panics, it aborts safely. And I get parallelism "for free" as I implement more layout features, because the compiler stops me if I'm about to do something non-thread-safe. None of this applies to C or C++, and the end result is that we can move faster and write cleaner code.

wycats• 12 years ago

For what it's worth, I've been using Rust for over a year in my product (http://skylight.io) and it matched my needs pretty closely. Our product is a performance monitoring tool that runs inside of Rails apps, so it's important to us to keep the overhead of our "agent" small and controllable.

Since the agent runs inside of a Ruby program, our only good choices are Ruby itself or a language without a garbage collector (embedding a language with a GC inside a language with GC is asking for trouble -- take a look at the bug tracker for TheRubyRacer for some color). Our initial version of the agent was written in Ruby, but carefully controlling memory usage or performance in Ruby isn't really feasible.

We prototyped a new version of the agent in C++, but I personally didn't feel comfortable shipping a binary that would run in thousands of customers' Rails apps in a language that could segfault if you're not careful. We took Rust very seriously last November, even thought it was still very young, because it gave us a language with direct control over memory with compiler-verified guarantees that our program wouldn't segfault.

TLDR: Rust is a very good choice for writing performance or memory-critical code that will be embedded in a high-level-language.

Also, because it offers compile-time guarantees about safety, I expect it to expand the number of cases where people feel justified in embedding a low-level language for performance-critical problems.

MichaelGG4• 12 years ago

I'm using Rust at my startup. The prototype version was written in F#, but that means you're anyways fighting memory allocation, which was the single biggest performance issue in my program. My system works on network traffic at line rate, so every allocation per packet is noticeable.

C programs doing what I'm doing have traditionally had security issues. Since our code often runs in privileged locations, that's an unacceptable risk. Plus, Rust is vastly more expressive than C and not messed up like C++. And abstractions are cheaper, too. For instance, we use Generics + Traits as a way to keep flexibility and a plugin model per frame, while keeping the performance of static dispatch. C wouldn't be able to do that in an easy way.

arthursilva5• 12 years ago

This isn't necessarily all bad, as people use it more this and OTHER problems will show up and will be worked out. As long as we don't get into HUGE breaks (like Py3) it's fine.

mushishi• 12 years ago

That's saddening to hear. Can you point out the discussion, so we can get a better idea what you mean?

kibwen20• 12 years ago

I've linked it from my comment here: https://news.ycombinator.com/item?id=8741113

zcdziura• 12 years ago

I'm genuinely curious what you mean by "leaving the cruft in". I haven't been following the release discussions very closely, so I don't know exactly what "crufty" things there are in the language/standard libraries.

Also, on the subject of the build system, while I too found it a bit confusing, only passing in the "main" file and having the compiler automatically compile and link all dependencies, over time I've come to love that feature. Especially coming from a (admittedly amateurish) C background, where I had to explicitly compile all of my source files into object code before linking them together, having the compiler manage everything for me cuts down on a lot of mental overhead (in my opinion, anyway). I wish the process was explained a little bit better in The Guide, but that's a documentation problem and not an implementation problem, which is much more easy to fix.

steveklabnik13• 12 years ago

I wish the process was explained a little bit better in The Guide,

To make sure I'm understanding, you mean the process of only compiling the crate root?

Multi-crate stuff has historically been a pretty weak area of the docs, but we do have a whole guide on it now: http://doc.rust-lang.org/guide-crates.html

Please feel free to open up issues on the repository any time you feel the documentation is lacking, I'd love to fix any problems.

kibwen20• 12 years ago

  > I brought this up and had a long discussion about it and 
  > how it might be improved with the community, but then 
  > when core contributors showed up, the discussion was shut 
  > down with the justification that "1.0 comes in a month"

Can you cite a source? If it was on IRC, I'm willing to sift through logs to find it for you if you give me your IRC nick.

  > I've heard other stories about poor management of the 
  > project

What stories are those? We have our fair share of people who like to spread FUD, so I'm curious which one you ran into. :)

Sir_Cmpwn8• 12 years ago

Can you cite a source? If it was on IRC, I'm willing to sift through logs to find it for you if you give me your IRC nick.

I'm "SirCmpwn", and the chat took place a few days ago in #rust on irc.mozilla.org.

What stories are those? We have our fair share of people who like to spread FUD, so I'm curious which one you ran into. :)

I'm not really willing to name people who criticised Rust's project management here.

kzrdude5• 12 years ago

From the discussion, it sounded like you wanted Rust to copy C's compilation model with objects per file, but no reason why apart from mimicing C.

Sir_Cmpwn8• 12 years ago

Nah, there are plenty of reasons other than "mimicing C" to use a similar model. One example is incremental compilation - right now, you have to recompile an entire Rust project every time you change even one file. Like I've said before, I don't want to rehash this argument here on HN, so let's not get too far into it. I just want to make it clear that I'm not just pulling this out of my ass.

scythe• 12 years ago

At the risk of repeating some arguments you've heard, does that really need to be in 1.0? Incremental compilation doesn't destroy backwards compatibility (unlike, e.g., moving threads out of the stdlib), and it isn't a "showstopper" feature (e.g. unboxed closures), it's a convenient trick that can be tacked on later. It's hardly the sort of thing that needs to delay stability for the majority of users.

pcwalton6• 12 years ago

If it's about incremental compilation, this is indeed correct. We've talked about doing incremental compilation post 1.0 and the module system is irrelevant to whether that is possible.

ww5202• 12 years ago

I too felt the management of the community contribution in the project was kind of poor. At least that's what I saw last year; now sure how it's now since I didn't follow it after my enthusiasm waned and moved on. I still believe Rust is a very promising project and wait for its final release before doing anything.

bjz_3• 12 years ago

What was poor about it? Could you cite instances?

coldtea3• 12 years ago

For example, the current build system is functionally equivalent to #including a bunch of C files in your C project and only passing one file to cc

That sounds like the perfect example of something that can be imporoved later and is totally orthogonal to the language design.

Semantics and syntax are what they need to get right pre 1.0, not the build system.

frowaway0012• 12 years ago

Also, the whole cargo thing is a disaster. One namespace for all libraries? This will work out great. Totally. Not.

dbaupp3• 12 years ago

It seems to work fairly well for PyPI, NPM and RubyGems (to name a few).

alexandre_m• 12 years ago

I predict some confusion about Rust crates.io and this project https://crate.io/

Jemaclus7• 12 years ago

I'm pretty stoked about this. I've been following Rust since 0.4, and it's been super fun to play around with. I have two major problems with it, but none of them are Rust's fault -- purely flaws of my own:

1) I have no idea what to do with it. I'm primarily a web developer, and I really want to get into systems programming, but I have no idea what to do with it or where to start. I wound up implementing about 50 different Rosetta Code things in Rust 0.9 and 0.10, but I still never came up with a really solid use-case that I could start and finish.

That said, I've been really impressed by rust-doom (https://github.com/cristicbz/rust-doom) and the new Iota editor (https://github.com/gchp/iota), and I wish I had the know-how to even start down that path.

2) Given that the last time I touched systems programming was in college (15 years ago), I've found it difficult to wrap my head around some of the concepts (ownership in particular). I actually hung out in the IRC chat room for awhile, but I felt more than a few times that people were treating me like an idiot because of my questions ("Ha! You did X? Why in the world would you do that??"), so I wound up not really going back. I'm sure it was all my imagination and that I'm just being sensitive, but I think it would be very helpful to have more people interested in getting new people on board -- specifically people like me, with over a decade of programming experience in higher-level languages.

I guess the TLDR of this is: I love Rust, but I don't know what to do with it.

Congrats to the Rust team, though. 1.0 is a huge milestone. Good job!

steveklabnik13• 12 years ago

Thanks so much!

For 1, it's true that it's not clear Rust is going to be great for web development. http://arewewebyet.com sums things up. That said, Rust does run the backend of Crates.io, and I've been toying around with it as an Ember backend, so we'll see :)

2) I'd love to hear your thoughts on my new ownership guide, which landed last weekish: http://doc.rust-lang.org/guide-ownership.html thoughts very welcome, either here, email, or on the issue tracker.

Ownership is the one concept in Rust that hasn't really existed at the language level before, so it's the most unusual thing to grok.

I felt more than a few times that people were treating me like an idiot because of my questions

Sorry to hear that. :/ We try to keep it 100% welcoming, but sometimes, people slip through the cracks.

Jemaclus7• 12 years ago

I'll check out the guide, thanks!

I don't necessarily need web-based ideas, but I don't know enough about the systems programming ecosystem to have an idea of where to start! A text editor? A game? A virtual planetarium? Machine learning? I have no idea! (Like I said, not your/Rust's problem...)

Dirlewanger• 12 years ago

I've been toying around with it as an Ember backend

Care to divulge some of your experiences so far? Like others here, I'm a webdev searching for a point of entry in Rust, and seeing that there's web frameworks out already I thought they'd might work. I want to start a side project with a Backbone/Marionette front but have been wondering whether to use Rails (day job), Node, or now even Rust. Thanks.

Just saw your rustforrubyists...definitely going to follow that!

kibwen20• 12 years ago

I'm in your boat, I'm a web developer who's always been curious about systems programming and has been following Rust as a way to get into the domain without all the tedious runaround and rampant paranoia associated with manual memory management. But, I still don't know what I should actually do with this knowledge now. :)

  > I actually hung out in the IRC chat room for awhile, 
  > but I felt more than a few times that people were 
  > treating me like an idiot because of my questions ("Ha! 
  > You did X? Why in the world would you do that??")

Unacceptable. I'm an op in #rust (bstrie), so feel free to PM me their nicks and I'll see to it that they treat new users better in the future.

sanderjd• 12 years ago

As a counter-anecdote, I'm in a very similar boat as the parent comment, and I have been astounded how consistently all the people in irc who definitely could make me feel like an idiot are unwilling to do so. It is a really refreshing experience after years of going into rooms full of arrogant people who actually don't know very much, as opposed to Rust's irc where everyone seems to know everything and are humble nonetheless.

masklinn• 12 years ago

1) I have no idea what to do with it. I'm primarily a web developer, and I really want to get into systems programming, but I have no idea what to do with it or where to start.

I'm thinking profiling some stuff and writing native accelerators, in Rust instead of C. More of an excuse than a need, but hey.

nickik2• 12 years ago

Web developer here, i just srarted to write a interpreter for a small lisp, granted not system programming but I can still use the low level features to my advantage.

Its pretty fun, but im looking forware to stability too.

hga7• 12 years ago

Writing a Lisp "in a week" (that would be putting most of your time into the project) is a classic thing to do, and while it indeed isn't exactly system programming, if you keep it simple (e.g. maybe limit it to atoms, lists and fixnums), but include precise GC, you'll learn a lot of things you need.

Hmmm, I've been wanting to learn Rust, but I always need a project to learn a language, and I haven't written a Lisp "in a week" yet ^_^. Yeah, thanks for the idea.

Flow• 12 years ago

I'm trying to write a tiny lisp interpreter in Rust myself. I haven't got very far.

Do you have a public repository for a curious fellow hacker?

michaelsbradley• 12 years ago

I'm hoping to port Shen to Rust, but I need to read the guide and learn my way around Rust itself before diving in too naively.

shmerl3• 12 years ago

May be someone will create a good Web development framework with Rust? After all there some for C++ already like this one: http://cppcms.com

saiko-chriskun• 12 years ago

http://nickel.rs

http://ironframework.io

barosl• 12 years ago

I like their FAQ, which says that other than database servers, application servers can be the bottleneck.

http://cppcms.com/wikipp/en/page/faq

http://blog.cppcms.com/post/42

saosebastiao3• 12 years ago

I feel like the projects where where rust is best positioned in terms of comparative advantage fall into two categories:

1) Large and complex systems that are slow to evolve due to being written in languages that are unsafe or are relatively poor in abstraction (in addition to the immense domain complexity). Examples: SQL and/or distributed databases, Paxos-ish systems, Operating Systems, IDEs, GIS, etc.

2) Extremely high performance systems on the fringe of research. Examples: MIP/LP/CP/SAT Solvers, Theorem Provers, Formal Verification tools, Rete-based Rule Engines, Machine Learning algorithms and frameworks, Statistical Samplers for MCMC, etc.

Unfortunately (maybe, I don't really know if it will turn out well or not), most of the hype for rust comes from back-end web developers. That is fine...I'm sure there is some performance to eek out there...but it is also trying to compete in an area where garbage collection has its greatest competitive advantages (namely, long running server processes). The comparative benefit is relatively small.

kibwen20• 12 years ago

  > most of the hype for rust comes from back-end web 
  > developers

It may seem that way because 1) most of the hype for anything programming-related these days comes from back-end web developers, and 2) because back-end web developers are the primary audience of HN. At Rust meetups that I've attended I've seen interest in people doing video games, robotics, AI, numerical work, databases... they just don't have as public and excitable a forum as this. :)

digikata• 12 years ago

I suspect that crypto libraries and embedded systems might also be good areas for Rust. Basically anywhere that a buffer overflow or memory leak is a relatively high-penalty failure.

sovande• 12 years ago

compete in an area where garbage collection has its greatest competitive advantages (namely, long running server processes)

I thought it was the opposite that was true. A garbage collector can/will leak memory over time (days) and will use up to 6-8 times more memory and can have performance problems etc. All long running server processes I know of (database, mail, http servers) manage their own memory. Exceptions are VM based systems and it is not unheard of to have a trivial Tomcat app use up to 1GB of memory.

toby• 12 years ago

My main use for C code is embedded / bare-metal programming, so I was curious if Rust could run directly on ARM boards. I found https://github.com/hackndev/zinc but haven't given it a try yet.

mahyarm• 12 years ago

Think client side native apps. Like a cross platform layer for a mobile/desktop app suite. With web dev, you have the advantage of being able to accept the JVM's relatively long spin up time and it's resulting speed over time. You have the flexibility to use things such as clojure or erlang. Client apps can't accept that kind of restriction very well.

I know of many client side libraries that are in C++ because it works everywhere(tm). Being able to maintain them in something like rust would be far nicer.

kyllo• 12 years ago

Does Rust have anything like a usable GUI toolkit yet to support client-side native app development?

eridius• 12 years ago

  > I've found it difficult to wrap my had around some of
  > the concepts (ownership in particular).

Have you tried reading the Ownership Guide (http://doc.rust-lang.org/guide-ownership.html)? I actually haven't read this particular guide myself (it didn't exist when I got started with Rust), but it sounds relevant :)

mrcwinn2• 12 years ago

Just providing some useless ramblings here...

You're a web developer, and you don't know what to do (in terms of how to spend your time) with a language geared toward systems.

That makes a lot of sense! At a certain scale, they're different types of work. It's like saying, "I'm a race car driver with a fighter jet. I've always admired them, but I'm just not sure where to fly!"

These types of languages, and more broadly any compiled language like C or C++, are very well suited to solve problems that your dynamic or scripted language can't solve at scale. Say, for example, as a web developer you built a website on Ruby on Rails that converts user-uploaded photos to morph, based on some algorithm, into a cute, unique photo of a kitten.

You have several concerns here: - Processing the image, hopefully in the background so it's non-blocking and you can control resource needs. - Storage. Is it on a local disk? S3? Something close by but on the network? If you have a performance bottleneck, is I/O an issue? - Memory/CPU. How many resources are needed for n- jobs? Is it starving resources from serving additional web requests (really a separate concern, when you think about it!)

I would say for these types of problems (and this is admittedly a contrived example), Rails + some Gem or even pure Ruby might just absolutely suck and eat it.

These specialized languages can be a super useful tool for figuring out "simple problems with complicated solutions." They also offer the comfort of compiling down to a binary that might have no external dependencies (so, very portable depending on the compiler/runtime, and probably very reliable).

Is that the right thing for a pure web developer to play? Depends on the developer, but it's not surprising you're not quite sure what to do with it. It's possible you just don't have the right type of problem to solve yet.

That being said, Rust or Go are still fun to play with! Good for you for exploring.

Jemaclus7• 12 years ago

That's exactly what I mean. :) A lot of the things I rely on for web development are so advanced under the hood that I don't even know where to begin. Like, let's say I want to write a tool that will let me take photos, resize them, crop them, add watermarks. I don't even... where do you start?

I wrote an LZW compressor in Rust 0.9 way back when, and it sucked pretty badly, but I wouldn't even know how to open a JPG or PNG, much less the mystical art of resizing it!

Gotta start somewhere, I guess. :)

peteretep• 12 years ago

I have found the IRC channel to be an incredibly supportive and helpful place, despite my barrage of dumb questions. I've been on IRC since the mid 90s and never seen anywhere so friendly, welcoming, and tolerant.

swetland3• 12 years ago

The biggest question I have regarding rust-1.0, is what's the likelyhood of small/standalone binaries being possible? Last time I looked, while there was talk about lightweight core libraries on the website, but the basic hello world binary was 2MB+ and depended on a bunch of shared libraries. I spent a little time trying to figure out how to build static/smaller binaries without much luck.

kibwen20• 12 years ago

Rust's runtime is actually undergoing a dramatic overhaul and is being almost entirely removed as we speak: https://github.com/rust-lang/rust/pull/19654

This is incredibly exciting in that it means that you won't need to do any ceremony to link in Rust libraries from other languages (previously you had to opt out of the stdlib and reimplement lang items as needed). But it also means that static libs should be much smaller, due to no runtime being necessary (which should also make LTO more able to strip unused symbols, shrinking binary size further).

swetland3• 12 years ago

That definitely sounds encouraging! Looking forward to this.

steveklabnik13• 12 years ago

It shouldn't be _both_ 2MB _and_ depend on a bunch of shared libraries, it should only be glibc and libgcc. And you can make it smaller by asking Rust to do dynamic linking rather than static linking.

The smallest known Rust binary is 151 bytes: http://www.reddit.com/r/rust/comments/2iwtjh/151byte_static_...

My sibling also has great info.

buster• 12 years ago

To be fair, it's not possible to tell cargo to do that (yet) (refering to https://github.com/rust-lang/cargo/issues/60 )

alkonaut• 12 years ago

That must be under something other than windows. Rust on Windows definitely still has issues with static linking, dependence on gcc libs for 32bit exception handling etc. Being able to build smaller statically linked binaries on windows is hopefully a priority.

jaredonline• 12 years ago

This is incredibly exciting. Way to go Rust team!

piokoch• 12 years ago

Now Rust needs some killer app. Maybe a message broker, something like Apache Kafka, maybe even with Java Messaging Service compatybility as an option. Rust with its low level I/O and efficient memory management should enable creating something very performant.

does_not_matter• 12 years ago

Lie #3: Code is more important than data

This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephemeral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! – have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing – the data. Bad data equals slow and crappy application. Writing a good engine means first and foremost, understanding the data.

http://www.insomniacgames.com/three-big-lies/

XorNot• 12 years ago

So something that always holds me up with new languages: workflow.

What's a Rust development workflow look like at the moment, from editor, to reference materials, to debugging? I tend to be an IDE person (which obviously doesn't and won't exist for some time) so I'm pretty eager to hear how other people have been doing it.

thristian• 12 years ago

I've only dabbled in Rust, but my setup for writing Rust in Vim is pretty similar to my setup for writing anything else: vim on one side of the screen, where I do my editing and type ":make" to try and build it (with Vim's makeprg configured to run "cargo test"). On the other side, a browser open to the Rust stdlib docs, and a terminal for interactive testing.

Rust 1.0: Scheduling the trains

Related Stories