Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Rust_(fungus)
I assumed it was named after the more well-known phenomenon of iron oxidation.
Fun facts about Rust's growing popularity
111–120 of 136 posts
Re: Fun facts about Rust's growing popularity
#112And yet not a single project written in Rust is out. The only project is Servo and nowhere close to production.
100 companies betting money on Rust.
Re: Fun facts about Rust's growing popularity
#113Earlier quoted context omitted.
To me, Swift feels very similar to Rust only a lot simpler. Arc is also (imho) a nicer solution than a GC (though people have different opinions on that). Even better, with future versions, some of the features of Rust (i.e. lifetimes) will also come to Swift in an opt-in way. It is still a young language but fun to code in.
What's coding in Swift like outside of being on macOS? Is the tooling decent on Ubuntu / *NIX or Windows?
On Linux there is official support for Swift.
Re: Fun facts about Rust's growing popularity
#114And yet not a single project written in Rust is out. The only project is Servo and nowhere close to production.
- the parity ethereum client: https://github.com/paritytech/parity
- the exonum framework: https://exonum.com/
Re: Fun facts about Rust's growing popularity
#115Well, a fun fact: there is nothing funny about that list :). It should have been called "Some facts about Rust's growing popularity". Now, my predicament: I love Rust's type system and tooling, but it's really hard to justify to myself the pain of writing correct Rust code (borrowing, lifetimes, etc.) when I know I can get almost the same effect by using a GC language + immutable messages. And I don't need that last…
I need that last drop of performance but only for a very small part of my code. For the rest, it's just painful to either have to implement iterators with tons of boilerplate ownership or declare things as sitting boxes on the heap. Both distract a lot from what I'm trying to do which is annoying. I wish there was a higher level Rust sublanguage where heap allocation and GC was default, and you would use the "bare" R…
Re: Fun facts about Rust's growing popularity
#116And yet not a single project written in Rust is out. The only project is Servo and nowhere close to production.
Re: Fun facts about Rust's growing popularity
#117Earlier quoted context omitted.
Pythonista makes me think of a leftist guerilla in a jungle with a beret and a machine gun.
This is fairly accurate bc they have a Chairman-for-life, and a schism between two groups, one of which denounces the other as revisionist.
Re: Fun facts about Rust's growing popularity
#118Earlier quoted context omitted.
I need that last drop of performance but only for a very small part of my code. For the rest, it's just painful to either have to implement iterators with tons of boilerplate ownership or declare things as sitting boxes on the heap. Both distract a lot from what I'm trying to do which is annoying. I wish there was a higher level Rust sublanguage where heap allocation and GC was default, and you would use the "bare" R…
You might look at LuaJIT as that language, with the inner loop in Rust.
I'd like to see a language that is both systems and high level at the same time, with trivial interop and a common build system + package manager.
This could e.g be a set of low level extensions added to C# (Span, ref returns etc is getting there) or a high level wrapper language/subset for e.g. Rust.
There is always a best tool for the job, and most jobs might require two tools, so it would be great if those two tools were aware of each other and came in the same toolbox.
Re: Fun facts about Rust's growing popularity
#119Earlier quoted context omitted.
>Rusts solution is a more general solution to the "general resource problem" It's true. Ever since I got familiar with the ownership concept, I've taken to writing C# IDisposables with disposable member variables like this: public MyObject(){ this.myResource = new DisposableResource(); this.ownsMyResource = true; } public MyObject(DisposableResource resourceToUseThatIDontOwn){ this.myResource = resourceToUseThatIDont…
I agree and I appreciate what they are trying to do. But just as a counter-argument, look how a simple lock looks like in Rust [1]: fn main() { let counter = Arc::new(Mutex::new(0)); let mut handles = vec![]; for _ in 0..10 { let counter = counter.clone(); let handle = thread::spawn(move || { let mut num = counter.lock().unwrap(); *num += 1; }); handles.push(handle); } //... } [1] https://doc.rust-lang.org/book/secon…
extern crate crossbeam;
use std::sync::Mutex;
fn main() {
let counter = Mutex::new(0);
crossbeam::scope(|scope| for _ in 0..10 {
scope.spawn(|| *counter.lock().unwrap() += 1);
});
println!("{:?}", counter);
}
Four lines to declare a mutex, start 10 threads that all lock that mutex, increase value behind mutex, unlock mutex, and join all spawned threads. There is a lot going on here (unwrap is arguably a noise here however, but the rest is straight to the point).Also, it's possible to use atomic ints here instead of mutex. Verbosity of mutex actually helps a bit, because locking is fairly expensive and it's better to avoid locking if possible.
Re: Fun facts about Rust's growing popularity
#120Well, a fun fact: there is nothing funny about that list :). It should have been called "Some facts about Rust's growing popularity". Now, my predicament: I love Rust's type system and tooling, but it's really hard to justify to myself the pain of writing correct Rust code (borrowing, lifetimes, etc.) when I know I can get almost the same effect by using a GC language + immutable messages. And I don't need that last…
I suggest taking a look at D[0] optional GC if you need to get that low level. A bit older than Rust. [0]: https://dlang.org/
* compiled, statically-typed, GC'd
* _very_ fast compilation (this is DMD; haven't tried the other two implementations (one on LLVM, the other on GCC))
* very fast executables
* easy linking with and use of C libraries
* familiar and practical