No post body was provided.
Rust 1.0: Status report and final timeline
31–40 of 128 posts
Re: Rust 1.0: Status report and final timeline
#32One thing I'm less clear on is what will happen after 1.0. Is there a "post 1.0 wishlist" somewhere?
Since last July or so, Servo has been tracking all of the major features we'd like to see that have been postponed to post-1.0:
https://github.com/servo/servo/issues/2854
Re: Rust 1.0: Status report and final timeline
#33Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…
You need to put the key material into an opaque struct, which does store it on the heap. Using the `black_box` function you can zero the key material out in the destructor.
I see. Which would be kind of similar to how you do it in C; the destructor is actually guaranteed to run when it goes out-of-scope?
But what I'm a bit more worried about is how the secret data gets in there, and what happens while I'm working with it: expansion, cipher state, key setup, all the little adds and xors and rots (dammit, why doesn't ROT ever get some real operator love? It's got first-class instructions… :() - all that stuff you'd do in u32 and u64. Temporary copies may still be a problem, if you look at the object that actually comes out of compilers sometimes.
Does using an opaque type actually deal with that issue here?
Re: Rust 1.0: Status report and final timeline
#34Even though 1.0 isn't out yet, today you can use Rust for many real projects. I'm unsure whether I'd bet my business on it yet, but I'd be open to the idea. And I'm usually a very late adopter. I've been building a 3d game with Rust and OpenGL, ported from a C++ codebase. So far, my experience has been very positive. Despite Rust's supposed immaturity, it feels more polished than C++ in many ways. Forward progress ha…
I'm betting my business on it. I've written a network search engine in F# and it's in use on the VoIP arm of one of the public telcos. VoIP can generate terabytes of signalling data a day, even while not making much money. (In wholesale, many calls simply don't complete, so you've got a huge amount of data and transactions that pay you $0.)
The challenge with F# is controlling memory usage. Even one extra allocation per packet can make a measureable difference in performance. I ended up doing a ton of unsafe code and manually managing most of the heap. Rust allows me to write fairly high-level code (not as expressive as F# yet but whatever) while getting "best" performance. Inline asm is a bonus, as there's some algorithms for integer compression that can use SIMD for big wins (I can do that in .NET, but it's ugly, and doing it safely means a ~30 instruction thunk). And sometimes in tight loops, I've found it difficult to get .NET to do acceptable codegen, causing double-digit% impacts.
There's also the safety issues writing unsafe code for network-exposed traffic. So Rust is actually more safe than .NET, because I have to toss .NET's safety to gain performance.
The backend management code I can continue to write in F#, and Rust's C-compatibility means it's trivial to interop the code. So I can do "orchestration" of indexing daemons and management APIs and such things in a higher-level language, then for actual indexing and whatnot, just jump over to Rust, seamlessly.
Finally the static compilation means a smoother installation experience for customers. And if I ever ship a closed-source module that executes on the client, I don't need to license Mono for static linking. So that's nice. And the safety guarantees are good, because similar, existing, software in C has put customers at risk before. (I'm not sure if I can effectively market that last part, but hey.)
Rust would appear to have a unique value proposition and I'm very pleased to see it progressing so damn well.
Re: Rust 1.0: Status report and final timeline
#35Earlier quoted context omitted.
You need to put the key material into an opaque struct, which does store it on the heap. Using the `black_box` function you can zero the key material out in the destructor.
I see. Which would be kind of similar to how you do it in C; the destructor is actually guaranteed to run when it goes out-of-scope? But what I'm a bit more worried about is how the secret data gets in there, and what happens while I'm working with it: expansion, cipher state, key setup, all the little adds and xors and rots (dammit, why doesn't ROT ever get some real operator love? It's got first-class instructions……
I know nothing about writing crypto core code. But... Rust supports inline assembly, so after you're done, you could always zeroize every register, right?
Re: Rust 1.0: Status report and final timeline
#36Earlier quoted context omitted.
You need to put the key material into an opaque struct, which does store it on the heap. Using the `black_box` function you can zero the key material out in the destructor.
I see. Which would be kind of similar to how you do it in C; the destructor is actually guaranteed to run when it goes out-of-scope? But what I'm a bit more worried about is how the secret data gets in there, and what happens while I'm working with it: expansion, cipher state, key setup, all the little adds and xors and rots (dammit, why doesn't ROT ever get some real operator love? It's got first-class instructions……
[deleted]
Re: Rust 1.0: Status report and final timeline
#37I saw that integer overflow has been revised: it now defaults to checking overflow in unoptimized builds. I got a little nervous about this when reading the performance-related objections of @thestinger here: https://github.com/rust-lang/rfcs/pull/560
At least optimized builds aren't affected, but it sounds like lots of code (including Rust nightlies) aren't built optimized.
Re: Rust 1.0: Status report and final timeline
#38Is it possible to estimate the amount of manpower and time required to develop a new language from scratch till it is stable and reasonably production ready? Adoption of language is different topic, since it depends on users. Rust and Go are two reasonably new languages. I understand scope and priorities of each language may be different but my idea is to get some approximation/thumb rule for any one before starting…
Both Google and Mozilla have teams dedicated to their languages, but they represent a very small portion of the total number of contributors to the language. I couldn't find exact lists of the team members inside both organizations.
In terms of volume of contributions, for Go, Google employees are by far the most active: https://github.com/golang/go/pulse. In this graph, the 7 top contributors to the project are Google employees. The Rust pulse graph shows the same trend (https://github.com/rust-lang/rust/pulse), with the top 6 contributors being Mozillians (according to a few Google searches).
Something that noteworthy about Go is the "quality" of the team members: Google has Ken Thompson, Rob Pike and Russ Cox working full time on the language. Mozilla may have a few great developers on Rust too, but Google is very serious about Go.
I don't have any information about how financial and human resources are used by Google and Mozilla for the development.
Re: Rust 1.0: Status report and final timeline
#39One thing I'm less clear on is what will happen after 1.0. Is there a "post 1.0 wishlist" somewhere?
A feature that has already seen many proposed rfcs and long discussions is "Efficient code reuse" (a.k.a some kind of inheritance), summarized here: https://github.com/rust-lang/rfcs/issues/349 It was explicitly postponed until after 1.0.
I just wrote a comment on that issue with some half-baked ideas, but I really think that this is one of those "line in the sand" features that will determine (at least for me) whether rust is really staying true to its emerging identity or whether it's on the road to becoming another opinionated kitchen sink language.
The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynamic dispatch, you suddenly have vtables. But who decides what those vtables look like? Where do they reside in memory? What's the layout of that? If a struct suddenly has an is-a pointer, where is that mentioned in the code? Now my struct isn't just a struct.
I love the rust idea that tons of modern language design still allows for zero-cost abstraction. Inheritance in dispatch starts getting into the land of "putting a lot more stuff in my binary than I asked you to", and I would argue that it's this property more than anything else that keeps embedded programmers and kernel guys safely in the minimalistic land of C.
It would be nice to have a new C, finally. But the more a language has an opinion on runtime layout, behavior, and symbol names, the less C-like it becomes.
Rust got this right when it decided that GC was NOT the correct default behavior for a language. The reason you see people playing with OS kernels in rust and not as much in D is, I think, mainly due to this decision. I think rust should continue carrying this torch.
If not for the ability to have the best of both worlds (a modern language and access to to-the-metal programming with a controllable runtime layout and deterministic performance profile), where exactly is the value in learning how to use the borrow checker?
Re: Rust 1.0: Status report and final timeline
#40I saw that integer overflow has been revised: it now defaults to checking overflow in unoptimized builds. I got a little nervous about this when reading the performance-related objections of @thestinger here: https://github.com/rust-lang/rfcs/pull/560 At least optimized builds aren't affected, but it sounds like lots of code (including Rust nightlies) aren't built optimized.
The nightlies are built with optimizations. And trust me, nobody's going to be distributing Rust binaries that weren't built with optimizations because Rust code built without optimizations has performance on par with Ruby rather than C++ (LLVM's optimization passes do a hell of a good job).