22 ms·
State of Rust 0.11.0
- broodbucket 12y agoIf you want to check out Rust and are having trouble because the docs aren't close to done yet, Rust for Rubyists (rustforrubyists.com) just came out with an update supporting 0.11. If you're using the nightlies, the only thing in that book that isn't consistent (that I've found so far) is that the .to_str() method is now .to_string().
- DAddYE 12y agoI suggest also this: http://rustbyexample.com http://rustbyexample.com It's an awesome resource and updated on a daily basis.
- steveklabnik 12y agoHopefully, my re-write of the guide will fully eclipse Rust for Rubyists soon. :)
- broodbucket 12y agoI really appreciate you still updating Rust for Rubyists even though you're working on the official guide.
- steveklabnik 12y agoYou're welcome. <3. 0.11 was the first edition I _completely_ re-read all the text and fixed things, and I still had something like ~10 errors. Editing your own writing is hard.
- nobotty 12y agoI'll be more interested when they've found a way to work with native binaries on windows, and handle creating/using binaries that take full advantage of the PE's import/export functionality. In reality it's not cross-platform if it doesn't support the almost guaranteed necessary features of the platform -- utilizing compiled dynamic libraries.
- cmrx64 12y agoOpen an issue. There is really only one contributor who works on Windows support. We need more people telling us what we are doing wrong on Windows.
- deleted 12y ago[deleted]
- cmrx64 12y agoUnfortunately, all those other things don't fit into the classic Haiku: A systems language / pursuing the trifecta / safe, concurrent, fast
- scythe 12y agoOh, wow, someone responded? I deleted that comment because i didn't feel it was sufficiently on-topic, but I had said: >Ada 95 achieved this two decades go, ATS some time after. Rust is trying for a fourth goal, to be expressive and convenient to use, and a fifth goal, to be portable and available to everyone. > Safe, concurrent, and fast just isn't enough. Also, consider putting in a little more tension: rust: functional stuff Concurrent, safe and clever still fast and easy.
- pjmlp 12y ago> A systems language / pursuing the trifecta / safe, concurrent, fast I dare to say Ada and the respective compilers meet all those requirements.
- dbaupp 12y agoI'm very curious, because I don't know much about Ada. How does Ada ensure that taking a reference/pointer to an element of a vector is safe? (i.e. the vector doesn't get reallocated/deallocated while the pointer still exists etc.) The three options I can think of are: - pervasive garbage collection, - disallowing such references and just copying the data out every time, and - the borrowing/freezing system of Rust Really only the latter is acceptable for the sort of 'fast' that Rust is aiming for. Rust also allows for memory safe concurrent code. Message passing is safe due to move semantics and transferring ownership of data between threads, and shared memory is safe because the type system has the power[1] to ensure that any mutation of it is atomic (either using atomic data types, or mutexes). Does Ada allow for both 100% memory-safe message passing and 100% memory-safe shared memory? [1]: http://doc.rust-lang.org/master/std/kinds/trait.Share.html http://doc.rust-lang.org/master/std/kinds/trait.Share.html
- rdtsc 12y agoThat is very exciting. I like the direction the project is going. But, one thing worries me -- performance. Anyone know a list or tracker of benchmarks to see how it roughly compares. Or is it too ealry too talk about it? Am I pointing to the elephant in the room? I am ok with saying "we are not there to talk about it, stop stirring the pot". I understand that. But looking at the future, if Rust is to compete with C++, it needs to perform close to it. Not necessarily in the "safer"/default mode, but it needs to have an unsafe, turn-off-all-checks-run as fast as you can mode. C++11/C++14 improved C++ many enjoy and like using it. Many that don't are probably using it for performance reasons. That is a niche Rust will have to compete in.
- cmrx64 12y agoRust's performance is competitive with clang and improving, even in the "safer" mode. We have benchmarks in many of the libraries (search for #[bench]) and some in src/test/bench. We're on the benchmarking game, but that is really just a game, not indicative of anything besides how much time someone has spent microoptimizing a specific program. Someone is working on a custom LLVM pass that will remove essentially every null check that Rust adds. On top of that, there are still a few more changes on the way that aren't easy, but should give a nice perf improvement.
- rdtsc 12y ago> but that is really just a game, Very much so, agreed. It is a PR game most of all. It is unfortunate. But it is probably a game that needs to be played. I know microbenchmarks are bogus, but I still click and look at them.
- jbooth 12y agoIs there a capability or plans to be able to export a header file from Rust code that C code (or Python, Go, whatever) could reference? I couldn't find anything when searching for it but it seems that it'd be possible since Rust doesn't have a runtime, right?
- dbaupp 12y agoYes, you can expose C symbols from a Rust library: #[no_mangle] pub extern fn rustlib_increment(x: i32) -> i32 { x + 1 } #10350 covers actually printing a .h file from Rust code. https://github.com/rust-lang/rust/issues/10530 https://github.com/rust-lang/rust/issues/10530
- jbooth 12y agoAwesome. I think the ability to write a nice .h file, in particular, will really be the killer feature for Rust as "better systems language". Exporting headers and symbols for higher level languages in a format that's universally understood.
- masklinn 12y ago> Rust doesn't have a runtime, right? Rust does have a runtime (used for tasks and GC'd types amongst others), the runtime can be disabled and the standard library is being split between "requires runtime" and "does not require runtime" (with as much as possible being moved to the latter). It's incorrect to say that Rust does not have a runtime, but it's correct to say that runtime-less Rust is very much a first-class concern for the project. PS: note that C does have a runtime as well, if a very minimal one.
- jblow 12y agoI want a language I would enjoy programming in. Rust seems to have a lot of what I want (GC not mandatory, perf, etc, etc) BUT private-by-default is a terrible idea. I started writing a Rust program and I was just typing pub pub pub all over the place. Ugly. That plus the excessive markup the language requires for safety are enough to put me off it. Video game programmers desperately need a new language to replace C++, but I think this is not it, because the amount of friction added for safety reasons feels very high. I'll keep an eye on the language as it evolves, though.
- kasey_junk 12y agoI think your response is on point because Rust also seems to be a lot of what I want (GC not mandatory, perf, etc, etc, plus pattern matching). Private by default is literally a huge positive for me. But the terribleness of Rust strings is enough to put me right off of it. I'm worried that all of us are waiting for something to replace C++ that can't happen.
- dbaupp 12y agoWhen you say "terrible", are you complaining about having to write `.as_slice()` and `.to_string()` all the time? For context for others who may not have a lot of Rust experience, Rust has two string types, the heap allocated `String` and the 'string slice' `&str`, which is a view of some string data anywhere in memory (possibly on the heap, possibly not). A little more info about these types: http://stackoverflow.com/a/24159933/1256624 http://stackoverflow.com/a/24159933/1256624 At the moment, conversions between them are via explicit method calls, which can result in verbose code when handling them. An explicit conversion is required even for the super-cheap `String` -> `&str` conversion (which is just repackaging the 3 words (length, capacity, pointer) of String into the 2 words (length, pointer) of the &str).
- kasey_junk 12y agoThat is part of the problem. The bigger part of the problem is comparing String's with constants. It simply doesn't work easily. Also, start trying to do pattern matching on Vec<String> vs Vec<str> (and the wide variety of static, ref, etc versions there in) and you end up spending a lot of effort to do what is very basic in most languages that support generic pattern matching. Try a simple use case, parse a command line argument array via pattern matching in a Rust program.
- tempodox 12y agoThis is welcome news. Also, I wasn't sure that Vec<T> was actually ~[T], I couldn't find that in the docs. Thanks for spelling it out. I see Rust as a language that could become the “next C” (only better), and I'm excited watching it evolve.
- sriku 12y agoNewbie taking a serious look at Rust here. Any notes about non-blocking I/O in rust? Iron [1] is mentioned, but am not sure how I/O is handled in Iron yet .. or how it would be written to be non-blocking [2]. I hear "read the source luke" echoing in the chambers of HN and will do that, but some higher level info would be nice. [1] http://ironframework.io/ http://ironframework.io/ [2] http://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking_io_possible_in_rust/ http://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking_... edit: This (http://doc.rust-lang.org/native/io/ http://doc.rust-lang.org/native/io/) seems to suggest that the norm is non-blocking I/O which is automatically handled by the scheduler.
- ben0x539 12y agoIf you explicitly use the "green" runtime that ships with rust instead of the "native" runtime, you get green threads where the built-in blocking IO only blocks the green thread but lets the OS-level thread carry on executing other green threads. Internally that is built on top of libuv for async IO, but as far as I know, Rust currently doesn't expose any interface for manually doing async or nonblocking IO.