7 ms·

Announcing Rust 1.36.0

pimeys 7y ago
std::future is stable. Async/await in about 12 weeks. Been writing loads of code, trying out the new futures and especially the possibility to use &self in an async context is a huge benefit. Beware though to use an executor that can drive the new futures and watch out certain libraries using `tokio::spawn` , which will cause panics. Some executors for the new futures: https://docs.rs/futures-preview/0.3.0-alpha.17/futures/executor/struct.ThreadPool.html https://docs.rs/futures-preview/0.3.0-alpha.17/futures/execu... https://github.com/withoutboats/juliex https://github.com/withoutboats/juliex And a web server to try out async/await on nightly: https://github.com/rustasync/tide https://github.com/rustasync/tide Compatibility layer from 0.1 to 0.3 and back is in futures-util-preview if compiled with the feature flag `compat`. https://docs.rs/futures-util-preview/0.3.0-alpha.17/futures_util/compat/index.html https://docs.rs/futures-util-preview/0.3.0-alpha.17/futures_...
- jkarneges 7y ago
  For anyone wanting to understand how to implement a basic engine for std::future from scratch, I mashed some code until it worked: https://gist.github.com/jkarneges/cb1ee686ef97bb05ebe04b5fc67536f4 https://gist.github.com/jkarneges/cb1ee686ef97bb05ebe04b5fc6... It's based mostly on this article, which predates std::future: https://www.viget.com/articles/understanding-futures-in-rust-part-1/ https://www.viget.com/articles/understanding-futures-in-rust...
  - pimeys 7y ago
    Here's another example how to mix futures 0.1 and async/await together. https://github.com/pimeys/blocking_test/ https://github.com/pimeys/blocking_test/
  - jadbox 7y ago
    Thank you. We really need more examples... and hopefully a full guide to futures/async. As someone currently in the outskirts of the Rust community, it's really hard to 'peer inside' what's happening and how to use it in practical applications. It's a matter of time, but it's just so exciting xD
    - steveklabnik 7y ago
      There is an “async book” in the works, by the working group. You’re 100% right that good docs will be important here!
- baby 7y ago
  > watch out certain libraries using `tokio::spawn` , which will cause panics care to expand on that?
  - pimeys 7y ago
    tokio::spawn needs to be run from the context of tokio's executor. If you use some other executor, such as juliex, it will panic. This is hopefully solved by the Runtime crate and the crates using it will use a more generic version.
ecmascript 7y ago
I can't use Rust because I like to make sexual jokes and that is against their Code of Conduct.
gaogao 7y ago
Just that page seems to be down right now.
- Flott 7y ago
  It's working for me.
  - gaogao 7y ago
    Strange. I'm just going to read the markdown instead, https://github.com/rust-lang/blog.rust-lang.org/commit/d72140e70a32ebf8701657cbcdda244873047ef2 https://github.com/rust-lang/blog.rust-lang.org/commit/d7214...
    - Flott 7y ago
      You could also try this: https://web.archive.org/web/20190704140112/https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html https://web.archive.org/web/20190704140112/https://blog.rust...
mmastrac 7y ago
We've been slowly rewriting our core instrumentation code at FullStory to take advantage of the new futures and async/await. I'd love to blog on this at some point but I think that the real big win here was being able to use ? to early exit in async code. I'm excited to see what the future brings here - we're still pretty new with async/await and building our own internal patterns.
- pimeys 7y ago
  Did you try to use an executor that can drive the new futures? The ability to use &self in an async context is so much nicer than playing around with Arc with things that really don't need one. Also very happy to not being forced to write .map_err ever again.
  - mmastrac 7y ago
    We're in a tricky spot with our async code because we need to interop with both Android JNI, Objective C threads, and some diagnostics code that uses tokio/websockets. For the first pass there was a lot of "let's get this working with a modern executor and make it perfect later". When we get some spare bandwidth we'll definitely see if we can get some extra productivity out of using &self. So much of our existing futures code is either self-less or uses some macro code to generate glue to allow us to use Arc-typed self - this is to allow a bunch of async core code to interop with these async platform drivers. Been on a crash course getting better at architecting Rust programs for nine months. Luckily the Rust ecosystem and toolchain is getting even more amazing each time around so we can justify some work to refactor and try new approaches.
    - pimeys 7y ago
      Do you have experience doing async ffi to other runtimes from Rust? Such as passing down futures from Rust to JavaScript or Java so you can use them from their context. I'd love to read a blog post about that subject...
      - 7y ago
kspp 7y ago
Is there any way to financially support the project? I have only been able to find a couple of Patreon pages of people working on specific libraries I haven't been using personally.
- simias 7y ago
  The project is sponsored by Mozilla so I guess the best way to support it is to use Firefox...
  - _han 7y ago
    Here's Mozilla's donation page: https://donate.mozilla.org https://donate.mozilla.org
    - deleted 7y ago
      [deleted]
    - mrec 7y ago
      Note that donations go to Foundation rather than Corp though. It's not clear how much - if anything - goes to dev projects like Rust.
      - lightgreen 7y ago
        Mozilla Corporation is fully owned by Mozilla Foundation. https://en.wikipedia.org/wiki/Mozilla_Corporation https://en.wikipedia.org/wiki/Mozilla_Corporation Corporation is separated from Foundation for legal and tax reasons, otherwise, it is the same org. (But employees of Mozilla get their salary, and it's not possible to give money directly to Mozilla Rust developers.)
        mrec 7y ago
        Yes I know, but I thought Foundation does a lot of less-techie things outside of Corp?
- 7y ago
ChrisSD 7y ago
MaybeUninit<T> is very welcome considering mem::uninitialized turned out to be such a mistake. I only tried using it once which dissuaded me from trying again, which was probably for the best. I'm still looking forward to const generics and a more usable const fn. In a way it's a shame Rust doesn't have a purely constant function in the interim. But a hybrid function will be more versatile once it allows some form of looping. The last thing on my wishlist is extern types (aka opaque types aka void *). The current workaround using a pointer to a [i8; 0] type relies on LLVM's particular handling of such pointers and always looks weird in rust.
- SCHiM 7y ago
  I might be revealing myself as a novice rust programmer here, but can't you use 'ptr : * const()' as an opaque pointer type? It's how I interface with C and C++ callback functions.
  - steveklabnik 7y ago
    You can, but there’s reasons a real external type feature is useful: https://github.com/rust-lang/rfcs/blob/master/text/1861-extern-types.md https://github.com/rust-lang/rfcs/blob/master/text/1861-exte...
  - ChrisSD 7y ago
    According to the nomicon[0], using a zero sized array in a repr(C) struct is the best practice for type safety. I also seem to remember someone saying the zero sized array is analogous to how LLVM bitcode represents void* in C. [0] https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs https://doc.rust-lang.org/nomicon/ffi.html#representing-opaq...
MuffinFlavored 7y ago
Future being stabilized to me is confusing. You still need `tokio` or a runtime to spawn them into an executor in order to do anything with them, right? So you have a standard trait from the language officially, that is useless without a third party library?
- bjterry 7y ago
  I think that allows library authors to implement against the trait, but then the user of that library can choose which concrete implementation they want to use in their app, so they don't have to have multiple and convert between them.
- steveklabnik 7y ago
  Sort of yes and sort of no. What you need is to call poll at the appropriate time. Doing so does not, strictly speaking, require external libraries. That said, you probably don’t want to write that code yourself; the naive implementation will be extremely inefficient. This is where external libraries come in. The reason they’re external is, depending on what you want to do, you’ll want an executor with different characteristics. An embedded executor has very different needs than a network IO executor than a GUI event loop. By stabilizing the trait, we can ensure library compatibility: everyone agrees on the same interface. Given that we’ve invested so much in making it easy to add libraries to your project, including a single one wouldn’t be appropriate.
  - MuffinFlavored 7y ago
    I'm not sure what this is worth, but I'd personally feel better and take Rust more seriously if they had an implementation as good as Tokio's available as part of the standard library instead of it being split across a bunch of third party libraries. Are there talks to make that a reality in the next 18 months? Is `async / .await` going to be just syntactic sugar around `Future` or is it going to necessitate an executor lives in the standard library?
    - GolDDranks 7y ago
mathieubordere 7y ago
Maybe I'm the only one, but I have a very hard time grasping all the functionality/concepts offered by Rust. I really like the safety guarantees offered at compile time, and really do think that we should move away from C-like languages if we ever want to control the tsunami of security flaws, but I can't stop wondering if Rust isn't (perhaps needlessly) complicating things and scaring off (non-C++) programmers.
- wtetzner 7y ago
  What are the concepts you have trouble with?
- nicoburns 7y ago
  Have you read the Rust book? I came to Rust from JavaScript, having never written more than "hello world" in C++ and found it pretty approachable.
- zengid 7y ago
  I don't think you're alone in being put off by the complexity of the language. I think once you get over the hump things start to click. The mindset that has helped me is to say, "Ok, this syntax might sometimes look familiar, but this language is COMPLETELY DIFFERENT from anything else I know, so I can't use my usual metaphors/analogies and need to use a clean slate". Then you can look at things like Ownership, Traits, and Pattern Matching and see how the whole language is built up around a few key ideas (with a lot of subtle variations) and then it might start to click. You need to give it a lot of time. Some of the ideas are really not familiar. I don't think Rust presents some of the ideas perfectly, but I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust and maybe make them appear more idiomatic.
  - vthriller 7y ago
    > this language is COMPLETELY DIFFERENT from anything else I know Rust itself borrows a lot from functional programming while also topping the story with lesser-known things like lifetimes, so no wonder it feels alien to a lot of people. In fact, the following: > I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust is actually already happening, except it's FP that's inspiring contemporary language designers (including Rust team). To me personally even limited familiarity with Haskell probably helped a lot back when I started tinkering with Rust, it all felt more familiar to me than to average C or Python dev.
davnicwil 7y ago
Can anyone recommend an http/rest api framework for Rust? I'd love to look at using it, last checked a couple of years ago and I don't remember finding anything that looked particularly stable / production ready.
- kevinbluer 7y ago
  Iron could be worth a look: http://ironframework.io http://ironframework.io Haven’t used it extensively, but it’s pretty feature-rich and looks reasonably well-maintained.
- steveklabnik 7y ago
  Actix web and rocket are the two most popular. HTTP stuff benefits a lot from asynchronicity, and so there’s been a lot of churn over the past few years as this story shakes out. We’re almost there though!
  - deleted 7y ago
    [deleted]
  - tiniuclx 7y ago
    I can second the suggestion for actix-web, it is a joy to use and I believe it is the only HTTP framework that has reached version 1.0 :) Have a look at the sort of things you can do with it https://github.com/actix/examples https://github.com/actix/examples
- jnordwick 7y ago
  Yeah, Go or Python both have good ones. Don't torture yourself - this isn't rust's wheelhouse.
  - steveklabnik 7y ago
    Depends on what you need; on benchmarks, like Techempower, actix is absolutely killing it.
  - dang 7y ago
CameronNemo 7y ago
The alloc crate stabilization should provide serde with improved options. Currently they maintain two json modules, one that does heap allocation and one that does not. https://serde.rs/no-std.html https://serde.rs/no-std.html https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#the-alloc-crate-is-stable https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#the-a...
- masklinn 7y ago
  Wouldn’t the non-allocating module remain useful and the allocating one just get lowered to depend on alloc rather than std?
RaycatRakittra 7y ago
If someone inexperienced in systems programming chose Rust as their first systems language, would there be difficulty adapting to other languages like C++? It seems like I'm caught in this back and forth between "C++ isn't pretty but it makes you money" and "Rust is so nice but where are the jobs".
- rcxdude 7y ago
  Adapting won't be too hard. I've heard a few people say learning rust made them better C++ coders, since the habits which make it easier to write rust which passes the borrow checker also make for more robust C++ code (in effect, the same rules the rust compiler enforces also apply to C++ code, but the compiler cannot help you nearly as much).
- kibwen 7y ago
  On the contrary, I'd say that learning Rust is a fabulous stepping stone to "modern" C++ (much of which served as the philosophical foundation for Rust in the first place). And once you get good enough at Rust that you've internalized the rules regarding memory ownership, you'll be able to instinctively apply those same rules successfully in C++, where the compiler proves fewer things for you.
  - neilv 7y ago
    I appreciate what you're saying, and that there's some truth to that, but I think there's at least two components to good allocation management in C++ (or C, or other memory-unsafe language)... The first component is conventions and idioms for managing allocations, and Rust will force you into (and support) some good (but nontrivial) ones. The second component is self-discipline. Look at the long history of vulnerabilities in C and C++ code that are due to carelessness -- of an oops that a programmer made when they knew better. If what's being considered is Rust as a stepping stone to C++, how much does Rust help with the first component, and is Rust even counterproductive for the second component? Regarding counterproductive for the second component, you might've seen a conventional practice of grinding the Rust Clippy until the code compiles. I don't know how that affects the development of self-discipline (e.g., maybe some people try to make a practice of being Clippy-free on every compile attempt?), but it seems a reasonable and interesting question to ask. (I'm not dissing Rust for this. I mostly like Rust, and would be happy to be working in/on it.)
thinkpad20 7y ago
> In Rust 1.36.0, the HashMap<K, V> implementation has been replaced with the one in the hashbrown crate which is based on the SwissTable design. While the interface is the same, the HashMap<K, V> implementation is now faster on average and has lower memory overhead. Note that unlike the hashbrown crate, the implementation in std still defaults to the SipHash 1-3 hashing algorithm. The wording here confuses me. They say they took the implementation from hashbrown, but then finish by saying that the implementation is different. What am I missing?
- xyzzyz 7y ago
  The hash table implementation (the data structure) is changed, but the hash function (the one which generates the hashes) is kept the same.
  - Twirrim 7y ago
    Maybe I misunderstood the speed complaints about HashMap in Rust. I thought it was the hash function that was the slow bit? What is the anticipated improvements from using SwissTable?
    - steveklabnik 7y ago
      We do choose a hash function not designed for speed by default, but that doesn’t mean that the implementation of the table can’t be improved. This is effectively the third re-write of it.
    - oconnor663 7y ago
      I think the bottleneck depends on the size of your table and the size of your keys. A large table with small keys will bottleneck on memory IO, but a small table with large keys will bottleneck on hashing the keys. But I definitely haven't benchmarked any of this.
- devit 7y ago
  The hashtable implementation is taken from hashbrown but the default hash is still the same and not taken from hashbrown.
johnklos 7y ago
Oooh! Maybe this version can be compiled deterministically!
- steveklabnik 7y ago
  Is there something specific you’re thinking of here? We do generally try to keep things reproducible, though sometimes things slip in. There’s a tracking issue for this, IIRC.
- kibwen 7y ago
  This has been possible at times in past versions of Rust, though I don't think there's currently any automatic regression test to ensure it so the ability comes and goes. Here's the tracking issue: https://github.com/rust-lang/rust/issues/34902 https://github.com/rust-lang/rust/issues/34902
damck 7y ago
Writing modern safe c++ isn't really the hassle everyone makes out of. Besides smart pointers the clang's sanitizers go a long way. I did try to pitch Rust at my corp but aforementioned safety checks are considered enough against the overhead of learning new language and I agree. Personally I don't like the Rc and Box syntax that's required to get a simplest homebrew version of even linked list going, C++'s metaprogramming hacks are rivaling that. I wish the stigma against "unsafe" C++ was a bit more rational. People who use it aren't the kind fresh out of bootcamps and mostly realise the gains and risks. But maybe I'm skewed by my job which uses C++ and takes any risks seriously.
- pjmlp 7y ago
  Sadly it is not a stigma, https://www.jetbrains.com/lp/devecosystem-2019/cpp/ https://www.jetbrains.com/lp/devecosystem-2019/cpp/ 34% don't use any kind of unit testing. 35% don't use any kind of static analysis tooling. 36% don't use any kind of guidelines.
  - rhodysurf 7y ago
    I wouldn’t rely on JetBrians survey to tell the whole story for C++. TONS of places use Visual Studio for C++ and would never even know about a JetBrains survey
    - pjmlp 7y ago
      Naturally it isn't representative of the whole industry, but it does show a trend. I can also post a ISO C++ one with similar results. Or the video from Herb Sutter's talk at CppCon, where only 1% of the audience confirmed using any form of static analysers. As anecdote, many enterprise places that use VC++ are still using versions like 2008 or 2010 and writing code as MFC/ATL had just been released. The same kind of shops that are running Red-Hat enterprise 5, some Java version pre-8, and such.
    - Matthias247 7y ago
      Those might be even worse. I think my experience correlates with the study. Most lower level code that I had seen used neither unit-tests nor any good structuring. At least in close-to-hardware projects that seems to be more the rule than an exception. I think this is due to many contributors there not having a pure software-engineering background. Those often have not worked in other higher level stacks and therefore are not familiar with practices.
AlleyTrotter 7y ago
Can someone point to a explanation of how to speak/read Rust. exactly how would you say "use std::fs::File" How does one pronounce :: Seems simple enough but things get much more complex by the third or fourth chapter of the Book.
- Diggsey 7y ago
  I would just read the words, "use" "standard" "fs" "file" and wouldn't pronounce the "::" at all.
  - AlleyTrotter 7y ago
    so the " :: ' has no verbal meaning, it's just a way of linking traits, libraries, functions,or crates? Not easy to explain
    - AlleyTrotter 7y ago
      I found what I was looking for in the appendix B-3 Path related syntax """ ::path Path relative to the crate root (i.e., an explicitly absolute """
    - atombender 7y ago
      It's for dereferencing namespaces. "a::b::c" is analogous to a file system path /a/b/c.
  - jnordwick 7y ago
    std pronounced "stud" with a very very short "u".
- ordu 7y ago
  I never pronounce separators like ::, ., ->... And braces, brackets, parenthesis and angle braces I do not pronounce. Programming languages are made not to sing them, but to write and read. To read silently I mean. While I understand what I'm reading, I do not bother to pronounce it in a way that would be digestible by an accident listener. If such a strategy stands between you and understanding, I'd suggest you to use silence gaps of different lengths. Like 0.5s for space and 0.2s for ::.
bigmit37 7y ago
Does Rust have its own linear algebra, image processing, computer vision libraries in pure rust? I would love to see how such libraries are built from scratch in a low level language. I feel like I would learn a lot as well.

std::future is stable. Async/await in about 12 weeks. Been writing loads of code, trying out the new futures and especially the possibility to use &self in an async context is a huge benefit. Beware though to use an executor that can drive the new futures and watch out certain libraries using `tokio::spawn` , which will cause panics. Some executors for the new futures: https://docs.rs/futures-preview/0.3.0-alpha.17/futures/executor/struct.ThreadPool.html https://docs.rs/futures-preview/0.3.0-alpha.17/futures/execu... https://github.com/withoutboats/juliex https://github.com/withoutboats/juliex And a web server to try out async/await on nightly: https://github.com/rustasync/tide https://github.com/rustasync/tide Compatibility layer from 0.1 to 0.3 and back is in futures-util-preview if compiled with the feature flag `compat`. https://docs.rs/futures-util-preview/0.3.0-alpha.17/futures_util/compat/index.html https://docs.rs/futures-util-preview/0.3.0-alpha.17/futures_...

jkarneges 7y ago
For anyone wanting to understand how to implement a basic engine for std::future from scratch, I mashed some code until it worked: https://gist.github.com/jkarneges/cb1ee686ef97bb05ebe04b5fc67536f4 https://gist.github.com/jkarneges/cb1ee686ef97bb05ebe04b5fc6... It's based mostly on this article, which predates std::future: https://www.viget.com/articles/understanding-futures-in-rust-part-1/ https://www.viget.com/articles/understanding-futures-in-rust...
- pimeys 7y ago
  Here's another example how to mix futures 0.1 and async/await together. https://github.com/pimeys/blocking_test/ https://github.com/pimeys/blocking_test/
- jadbox 7y ago
  Thank you. We really need more examples... and hopefully a full guide to futures/async. As someone currently in the outskirts of the Rust community, it's really hard to 'peer inside' what's happening and how to use it in practical applications. It's a matter of time, but it's just so exciting xD
  - steveklabnik 7y ago
    There is an “async book” in the works, by the working group. You’re 100% right that good docs will be important here!
baby 7y ago
> watch out certain libraries using `tokio::spawn` , which will cause panics care to expand on that?
- pimeys 7y ago
  tokio::spawn needs to be run from the context of tokio's executor. If you use some other executor, such as juliex, it will panic. This is hopefully solved by the Runtime crate and the crates using it will use a more generic version.

ecmascript 7y ago

I can't use Rust because I like to make sexual jokes and that is against their Code of Conduct.

gaogao 7y ago

Just that page seems to be down right now.

Flott 7y ago
It's working for me.
- gaogao 7y ago
  Strange. I'm just going to read the markdown instead, https://github.com/rust-lang/blog.rust-lang.org/commit/d72140e70a32ebf8701657cbcdda244873047ef2 https://github.com/rust-lang/blog.rust-lang.org/commit/d7214...
  - Flott 7y ago
    You could also try this: https://web.archive.org/web/20190704140112/https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html https://web.archive.org/web/20190704140112/https://blog.rust...

mmastrac 7y ago

We've been slowly rewriting our core instrumentation code at FullStory to take advantage of the new futures and async/await. I'd love to blog on this at some point but I think that the real big win here was being able to use ? to early exit in async code. I'm excited to see what the future brings here - we're still pretty new with async/await and building our own internal patterns.

pimeys 7y ago
Did you try to use an executor that can drive the new futures? The ability to use &self in an async context is so much nicer than playing around with Arc with things that really don't need one. Also very happy to not being forced to write .map_err ever again.
- mmastrac 7y ago
  We're in a tricky spot with our async code because we need to interop with both Android JNI, Objective C threads, and some diagnostics code that uses tokio/websockets. For the first pass there was a lot of "let's get this working with a modern executor and make it perfect later". When we get some spare bandwidth we'll definitely see if we can get some extra productivity out of using &self. So much of our existing futures code is either self-less or uses some macro code to generate glue to allow us to use Arc-typed self - this is to allow a bunch of async core code to interop with these async platform drivers. Been on a crash course getting better at architecting Rust programs for nine months. Luckily the Rust ecosystem and toolchain is getting even more amazing each time around so we can justify some work to refactor and try new approaches.
  - pimeys 7y ago
    Do you have experience doing async ffi to other runtimes from Rust? Such as passing down futures from Rust to JavaScript or Java so you can use them from their context. I'd love to read a blog post about that subject...
    - 7y ago

kspp 7y ago

Is there any way to financially support the project? I have only been able to find a couple of Patreon pages of people working on specific libraries I haven't been using personally.

simias 7y ago
The project is sponsored by Mozilla so I guess the best way to support it is to use Firefox...
- _han 7y ago
  Here's Mozilla's donation page: https://donate.mozilla.org https://donate.mozilla.org
  - deleted 7y ago
    [deleted]
  - mrec 7y ago
    Note that donations go to Foundation rather than Corp though. It's not clear how much - if anything - goes to dev projects like Rust.
    - lightgreen 7y ago
      Mozilla Corporation is fully owned by Mozilla Foundation. https://en.wikipedia.org/wiki/Mozilla_Corporation https://en.wikipedia.org/wiki/Mozilla_Corporation Corporation is separated from Foundation for legal and tax reasons, otherwise, it is the same org. (But employees of Mozilla get their salary, and it's not possible to give money directly to Mozilla Rust developers.)
      - mrec 7y ago
        Yes I know, but I thought Foundation does a lot of less-techie things outside of Corp?
7y ago

ChrisSD 7y ago

MaybeUninit<T> is very welcome considering mem::uninitialized turned out to be such a mistake. I only tried using it once which dissuaded me from trying again, which was probably for the best. I'm still looking forward to const generics and a more usable const fn. In a way it's a shame Rust doesn't have a purely constant function in the interim. But a hybrid function will be more versatile once it allows some form of looping. The last thing on my wishlist is extern types (aka opaque types aka void *). The current workaround using a pointer to a [i8; 0] type relies on LLVM's particular handling of such pointers and always looks weird in rust.

SCHiM 7y ago
I might be revealing myself as a novice rust programmer here, but can't you use 'ptr : * const()' as an opaque pointer type? It's how I interface with C and C++ callback functions.
- steveklabnik 7y ago
  You can, but there’s reasons a real external type feature is useful: https://github.com/rust-lang/rfcs/blob/master/text/1861-extern-types.md https://github.com/rust-lang/rfcs/blob/master/text/1861-exte...
- ChrisSD 7y ago
  According to the nomicon[0], using a zero sized array in a repr(C) struct is the best practice for type safety. I also seem to remember someone saying the zero sized array is analogous to how LLVM bitcode represents void* in C. [0] https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs https://doc.rust-lang.org/nomicon/ffi.html#representing-opaq...

MuffinFlavored 7y ago

Future being stabilized to me is confusing. You still need `tokio` or a runtime to spawn them into an executor in order to do anything with them, right? So you have a standard trait from the language officially, that is useless without a third party library?

bjterry 7y ago
I think that allows library authors to implement against the trait, but then the user of that library can choose which concrete implementation they want to use in their app, so they don't have to have multiple and convert between them.
steveklabnik 7y ago
Sort of yes and sort of no. What you need is to call poll at the appropriate time. Doing so does not, strictly speaking, require external libraries. That said, you probably don’t want to write that code yourself; the naive implementation will be extremely inefficient. This is where external libraries come in. The reason they’re external is, depending on what you want to do, you’ll want an executor with different characteristics. An embedded executor has very different needs than a network IO executor than a GUI event loop. By stabilizing the trait, we can ensure library compatibility: everyone agrees on the same interface. Given that we’ve invested so much in making it easy to add libraries to your project, including a single one wouldn’t be appropriate.
- MuffinFlavored 7y ago
  I'm not sure what this is worth, but I'd personally feel better and take Rust more seriously if they had an implementation as good as Tokio's available as part of the standard library instead of it being split across a bunch of third party libraries. Are there talks to make that a reality in the next 18 months? Is `async / .await` going to be just syntactic sugar around `Future` or is it going to necessitate an executor lives in the standard library?
  - GolDDranks 7y ago

mathieubordere 7y ago

Maybe I'm the only one, but I have a very hard time grasping all the functionality/concepts offered by Rust. I really like the safety guarantees offered at compile time, and really do think that we should move away from C-like languages if we ever want to control the tsunami of security flaws, but I can't stop wondering if Rust isn't (perhaps needlessly) complicating things and scaring off (non-C++) programmers.

wtetzner 7y ago
What are the concepts you have trouble with?
nicoburns 7y ago
Have you read the Rust book? I came to Rust from JavaScript, having never written more than "hello world" in C++ and found it pretty approachable.
zengid 7y ago
I don't think you're alone in being put off by the complexity of the language. I think once you get over the hump things start to click. The mindset that has helped me is to say, "Ok, this syntax might sometimes look familiar, but this language is COMPLETELY DIFFERENT from anything else I know, so I can't use my usual metaphors/analogies and need to use a clean slate". Then you can look at things like Ownership, Traits, and Pattern Matching and see how the whole language is built up around a few key ideas (with a lot of subtle variations) and then it might start to click. You need to give it a lot of time. Some of the ideas are really not familiar. I don't think Rust presents some of the ideas perfectly, but I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust and maybe make them appear more idiomatic.
- vthriller 7y ago
  > this language is COMPLETELY DIFFERENT from anything else I know Rust itself borrows a lot from functional programming while also topping the story with lesser-known things like lifetimes, so no wonder it feels alien to a lot of people. In fact, the following: > I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust is actually already happening, except it's FP that's inspiring contemporary language designers (including Rust team). To me personally even limited familiarity with Haskell probably helped a lot back when I started tinkering with Rust, it all felt more familiar to me than to average C or Python dev.

davnicwil 7y ago

Can anyone recommend an http/rest api framework for Rust? I'd love to look at using it, last checked a couple of years ago and I don't remember finding anything that looked particularly stable / production ready.

kevinbluer 7y ago
Iron could be worth a look: http://ironframework.io http://ironframework.io Haven’t used it extensively, but it’s pretty feature-rich and looks reasonably well-maintained.
steveklabnik 7y ago
Actix web and rocket are the two most popular. HTTP stuff benefits a lot from asynchronicity, and so there’s been a lot of churn over the past few years as this story shakes out. We’re almost there though!
- deleted 7y ago
  [deleted]
- tiniuclx 7y ago
  I can second the suggestion for actix-web, it is a joy to use and I believe it is the only HTTP framework that has reached version 1.0 :) Have a look at the sort of things you can do with it https://github.com/actix/examples https://github.com/actix/examples
jnordwick 7y ago
Yeah, Go or Python both have good ones. Don't torture yourself - this isn't rust's wheelhouse.
- steveklabnik 7y ago
  Depends on what you need; on benchmarks, like Techempower, actix is absolutely killing it.
- dang 7y ago

CameronNemo 7y ago

The alloc crate stabilization should provide serde with improved options. Currently they maintain two json modules, one that does heap allocation and one that does not. https://serde.rs/no-std.html https://serde.rs/no-std.html https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#the-alloc-crate-is-stable https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#the-a...

masklinn 7y ago
Wouldn’t the non-allocating module remain useful and the allocating one just get lowered to depend on alloc rather than std?

RaycatRakittra 7y ago

If someone inexperienced in systems programming chose Rust as their first systems language, would there be difficulty adapting to other languages like C++? It seems like I'm caught in this back and forth between "C++ isn't pretty but it makes you money" and "Rust is so nice but where are the jobs".

rcxdude 7y ago
Adapting won't be too hard. I've heard a few people say learning rust made them better C++ coders, since the habits which make it easier to write rust which passes the borrow checker also make for more robust C++ code (in effect, the same rules the rust compiler enforces also apply to C++ code, but the compiler cannot help you nearly as much).
kibwen 7y ago
On the contrary, I'd say that learning Rust is a fabulous stepping stone to "modern" C++ (much of which served as the philosophical foundation for Rust in the first place). And once you get good enough at Rust that you've internalized the rules regarding memory ownership, you'll be able to instinctively apply those same rules successfully in C++, where the compiler proves fewer things for you.
- neilv 7y ago
  I appreciate what you're saying, and that there's some truth to that, but I think there's at least two components to good allocation management in C++ (or C, or other memory-unsafe language)... The first component is conventions and idioms for managing allocations, and Rust will force you into (and support) some good (but nontrivial) ones. The second component is self-discipline. Look at the long history of vulnerabilities in C and C++ code that are due to carelessness -- of an oops that a programmer made when they knew better. If what's being considered is Rust as a stepping stone to C++, how much does Rust help with the first component, and is Rust even counterproductive for the second component? Regarding counterproductive for the second component, you might've seen a conventional practice of grinding the Rust Clippy until the code compiles. I don't know how that affects the development of self-discipline (e.g., maybe some people try to make a practice of being Clippy-free on every compile attempt?), but it seems a reasonable and interesting question to ask. (I'm not dissing Rust for this. I mostly like Rust, and would be happy to be working in/on it.)

thinkpad20 7y ago

> In Rust 1.36.0, the HashMap<K, V> implementation has been replaced with the one in the hashbrown crate which is based on the SwissTable design. While the interface is the same, the HashMap<K, V> implementation is now faster on average and has lower memory overhead. Note that unlike the hashbrown crate, the implementation in std still defaults to the SipHash 1-3 hashing algorithm. The wording here confuses me. They say they took the implementation from hashbrown, but then finish by saying that the implementation is different. What am I missing?

xyzzyz 7y ago
The hash table implementation (the data structure) is changed, but the hash function (the one which generates the hashes) is kept the same.
- Twirrim 7y ago
  Maybe I misunderstood the speed complaints about HashMap in Rust. I thought it was the hash function that was the slow bit? What is the anticipated improvements from using SwissTable?
  - steveklabnik 7y ago
    We do choose a hash function not designed for speed by default, but that doesn’t mean that the implementation of the table can’t be improved. This is effectively the third re-write of it.
  - oconnor663 7y ago
    I think the bottleneck depends on the size of your table and the size of your keys. A large table with small keys will bottleneck on memory IO, but a small table with large keys will bottleneck on hashing the keys. But I definitely haven't benchmarked any of this.
devit 7y ago
The hashtable implementation is taken from hashbrown but the default hash is still the same and not taken from hashbrown.

johnklos 7y ago

Oooh! Maybe this version can be compiled deterministically!

steveklabnik 7y ago
Is there something specific you’re thinking of here? We do generally try to keep things reproducible, though sometimes things slip in. There’s a tracking issue for this, IIRC.
kibwen 7y ago
This has been possible at times in past versions of Rust, though I don't think there's currently any automatic regression test to ensure it so the ability comes and goes. Here's the tracking issue: https://github.com/rust-lang/rust/issues/34902 https://github.com/rust-lang/rust/issues/34902

damck 7y ago

Writing modern safe c++ isn't really the hassle everyone makes out of. Besides smart pointers the clang's sanitizers go a long way. I did try to pitch Rust at my corp but aforementioned safety checks are considered enough against the overhead of learning new language and I agree. Personally I don't like the Rc and Box syntax that's required to get a simplest homebrew version of even linked list going, C++'s metaprogramming hacks are rivaling that. I wish the stigma against "unsafe" C++ was a bit more rational. People who use it aren't the kind fresh out of bootcamps and mostly realise the gains and risks. But maybe I'm skewed by my job which uses C++ and takes any risks seriously.

pjmlp 7y ago
Sadly it is not a stigma, https://www.jetbrains.com/lp/devecosystem-2019/cpp/ https://www.jetbrains.com/lp/devecosystem-2019/cpp/ 34% don't use any kind of unit testing. 35% don't use any kind of static analysis tooling. 36% don't use any kind of guidelines.
- rhodysurf 7y ago
  I wouldn’t rely on JetBrians survey to tell the whole story for C++. TONS of places use Visual Studio for C++ and would never even know about a JetBrains survey
  - pjmlp 7y ago
    Naturally it isn't representative of the whole industry, but it does show a trend. I can also post a ISO C++ one with similar results. Or the video from Herb Sutter's talk at CppCon, where only 1% of the audience confirmed using any form of static analysers. As anecdote, many enterprise places that use VC++ are still using versions like 2008 or 2010 and writing code as MFC/ATL had just been released. The same kind of shops that are running Red-Hat enterprise 5, some Java version pre-8, and such.
  - Matthias247 7y ago
    Those might be even worse. I think my experience correlates with the study. Most lower level code that I had seen used neither unit-tests nor any good structuring. At least in close-to-hardware projects that seems to be more the rule than an exception. I think this is due to many contributors there not having a pure software-engineering background. Those often have not worked in other higher level stacks and therefore are not familiar with practices.

AlleyTrotter 7y ago

Can someone point to a explanation of how to speak/read Rust. exactly how would you say "use std::fs::File" How does one pronounce :: Seems simple enough but things get much more complex by the third or fourth chapter of the Book.

Diggsey 7y ago
I would just read the words, "use" "standard" "fs" "file" and wouldn't pronounce the "::" at all.
- AlleyTrotter 7y ago
  so the " :: ' has no verbal meaning, it's just a way of linking traits, libraries, functions,or crates? Not easy to explain
  - AlleyTrotter 7y ago
    I found what I was looking for in the appendix B-3 Path related syntax """ ::path Path relative to the crate root (i.e., an explicitly absolute """
  - atombender 7y ago
    It's for dereferencing namespaces. "a::b::c" is analogous to a file system path /a/b/c.
- jnordwick 7y ago
  std pronounced "stud" with a very very short "u".
ordu 7y ago
I never pronounce separators like ::, ., ->... And braces, brackets, parenthesis and angle braces I do not pronounce. Programming languages are made not to sing them, but to write and read. To read silently I mean. While I understand what I'm reading, I do not bother to pronounce it in a way that would be digestible by an accident listener. If such a strategy stands between you and understanding, I'd suggest you to use silence gaps of different lengths. Like 0.5s for space and 0.2s for ::.

bigmit37 7y ago

Does Rust have its own linear algebra, image processing, computer vision libraries in pure rust? I would love to see how such libraries are built from scratch in a low level language. I feel like I would learn a lot as well.