What happened to the exhaustive list of unnamed Github contributors? I thought that was a really powerful marketing method: dear unnamed Github user x1230134384, your contribution has been acknowledged! Feedback without requiring identification, it's kindof very cool in a project like this.
Announcing Rust 1.20
61–70 of 277 posts
Re: Announcing Rust 1.20
#62What happened to the exhaustive list of unnamed Github contributors? I thought that was a really powerful marketing method: dear unnamed Github user x1230134384, your contribution has been acknowledged! Feedback without requiring identification, it's kindof very cool in a project like this.
If you click on the final link to thanks.rust-lang.org, you'll find it there!
There have been talks about moving it back, but it's complicated. You can do the "duplicate it" strategy, but that has downsides. You could do an iframe, but then you're using an iframe. You could use JavaScript, but then a whole different crew of people will Get Mad.
Re: Announcing Rust 1.20
#63Earlier quoted context omitted.
Threadsafe (no externally visible mutable data) singleton instance?
Isn't all data (outside of unsafe blocks) in Rust already threadsafe? Isn't that one of the big selling points of the language?
It is data-race free. That's one definition of "threadsafe", but there could be others; it's a pretty broad term.
Re: Announcing Rust 1.20
#64Interestingly, because Firefox chooses to use stable Rust exclusively, this is the version of Rust that will be used to deliver Quantum when Firefox 57 releases on November 14 (by which time Rust 1.21 will be out (releasing October 12), but Firefox 57 will be in beta by September 20).
To save others from searching, Quantum[1] is the new engine for Firefox replacing(/building upon) gecko. [1] https://wiki.mozilla.org/Quantum
Quantum is the project, not the engine. The resulting product is still Gecko.
Re: Announcing Rust 1.20
#65I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs).
I'm a bit frustrated because this is so easy in C. Is there any way this can be easier?
I am imagining a special way to construct cyclical structures where everything inside would have the same lifetime and be destructed at once. We may need to hide the references from destructors though, otherwise a destructor could see a dangling reference.
Re: Announcing Rust 1.20
#66Earlier quoted context omitted.
Well, to me Rust code looks fundamentally like any other OO language e.g. let mut window: PistonWindow = WindowSettings::new( "piston: hello_world", [200, 200] ) .exit_on_esc(true) .opengl(OpenGL::V2_1) .build() .unwrap(); If you wrote that in C++ or Java or Python or.. it would /could look fundamentally the same. You create a window object and then call a bunch of its methods (mutating its state). That's OOP. I thin…
"OOP" has suffered since the 90s of being a somewhat vague term in practice (much to the chagrin of Smalltalkers), but making it even more overbroad just to make it apply to Rust will only drive the term further into uselessness. It's not about being "hip", it's about using terminology that's usefully precise. (For the record, I also think "functional programming" is a uselessly broad category these days, having beco…
It actually is the consensus in the OOP world these days that composition is preferable to inheritance in most cases.
Declaring class inheritance to be the defining feature of OOP just because it was fundamental to 1990s Java courses makes about as much sense as to say extreme late-binding is a fundamental aspect of OOP, like Alan Kay does, and thus neither Java nor C++ are OOP languages. Yippee! Suddenly they are no longer boring, old OOP anymore either! Thanks Alan!
You mention FP being a broad category. Indeed it is. Haskell is all about expressive static types, meanwhile Erlang couldn't care less about types. Yet I dare to argue that this broad definition is not "useless" because both Erlang and Haskell default to immutable data and pure functions, and that defines FP more than anything.
Practically meaning that Erlang and Haskell tend to be massively closer to each other than they are to imperative languages.
The same is the case here. Rust is massively closer to C++ than to Haskell. Mutable ADTs+methods+interfaces, as opposed to free functions and (immutable) "raw" data defines the code style way more than questions like subtype vs. parametic polymorphism
If you think that the fact that your dog does not "inherit" from mammal but instead has the mammal "trait", means you are doing a fundamentally different kind of programming, you are wrong. Such differences are of lesser importance in practice.
Re: Announcing Rust 1.20
#67Earlier quoted context omitted.
Isn't all data (outside of unsafe blocks) in Rust already threadsafe? Isn't that one of the big selling points of the language?
Rust isn't inherently thread-safe; not like in the way Java is thread-safe because of how the JVM's memory model is defined. Rust makes it really difficult to share mutable data. But once you do that, such as by smuggling a pointer _through_ an unsafe block, all bets are off, even for code outside an unsafe block. Also, as with Java there will always be bugs in the compiler and runtime. Rust programs were susceptible…
If you use a C FFI in any language, including Java, all kinds of safety are off. Unsafe Rust is equivalent to C (with a lot of mandatory lints) in terms of safety, so Rust is not really less safe.
Re: Announcing Rust 1.20
#68"Associated functions" = class methods "Associated constants" = limited version of class variables Rust keeps approaching C++'s feature set.. I am amazed that the above wasn't in Rust to begin with, though. Can't think of any other languages which has classes but no class methods/variables.
> Rust keeps approaching C++'s feature set.. If there's one thing we C++ programmers can agree on, it's that having tons of features makes C++ a pleasure to work with... ?
I used to be a huge fan of C++. I loved how you could work with a somewhat OO language while still wielding dark powers like: manual memory management, mix-n-match polymorphism (aka. virtual inheritance), templates, type-erasing.
Then I got a full time job working with a large C++ codebase. Since then I've been dealing with:
- uninitialized variables / members
- NULL checks
- buffer overflows, especially with C-strings
- (mutable) global variables
- exception safety
All these things don't exist in (safe) Rust. I'm sold.
Foot note: the only thing I'm really missing in Rust right now is specialization in generics, which is being worked on here: https://github.com/rust-lang/rust/issues/31844.
Re: Announcing Rust 1.20
#69I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…
Have you considered leveraging crates.io? I'm not sure of your exact constraints, but I've heard some good things about petgraph: https://crates.io/crates/petgraph . It sounds like you might also want to check out some implementations of arenas.
Re: Announcing Rust 1.20
#70What happened to the exhaustive list of unnamed Github contributors? I thought that was a really powerful marketing method: dear unnamed Github user x1230134384, your contribution has been acknowledged! Feedback without requiring identification, it's kindof very cool in a project like this.
If you click on the final link to thanks.rust-lang.org, you'll find it there! There have been talks about moving it back, but it's complicated. You can do the "duplicate it" strategy, but that has downsides. You could do an iframe, but then you're using an iframe. You could use JavaScript, but then a whole different crew of people will Get Mad.
But if you use iframes, then Servo will get to show off its intra-page content isolation. :)