Live data from Hacker News

Fun facts about Rust's growing popularity

jonathanturner.org

71–80 of 136 posts

Re: Fun facts about Rust's growing popularity

#71

Well, 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…

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.

ARC is nicer than GC and more predictable but in terms of performance for stuff like audio raw graphics processing and so on you still want to use something more low level like Rust, C or C++.

One of the reasons iOS is more smooth than Android there's no "OK I'm going to GC a million objects right in the middle of your scroll" performance dip but it will release all objects more gradually through ARC at a slightly bigger total performance cost.

Ask C devs why they (still) think Swift is a PITA to work with compared to Objective-C. Luckily in most scenarios you can use Objective-C mixed with Swift to get the advantages of both scenarios.

Re: Fun facts about Rust's growing popularity

#72

Well, 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…

You're overlooking that Rusts "solution"(borrowing, livetimes, etc. ) is not only solving the same problem that garbage collection tries to solve. Garbage collection is "only" solving the "memory resource problem". Rusts solution is a more general solution to the "general resource problem" .. like file handles, sockets and of course memory and besides that gives you tools to never get bitten by data races. Nothing (b…

You would still need to have lots of resource management problems to consider using Rust, i.e. it is useful to those high performance/embedded domains that still use C/C++. There are high level dynamic solutions even for things like data races these days (e.g. transacations) if you don’t need to juice every last bit of perf out.

Re: Fun facts about Rust's growing popularity

#73
post #49

Well, 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…

> [...] 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 drop of performance either. You probably write more highlevel code? Rust is --as the name implies-- most suited for close-to-the-metal code. This is often where that "last drop of perf…

> Rust is --as the name implies-- most suited for close-to-the-metal code.

There are a lot of projects that really could be written in a high-level language, but they were started when C was still preferable due to the immaturity of higher-level solutions. I think it is sad that people, looking at these aging and unaudited C codebases, are thinking about rewriting them in Rust, when rewriting them in e.g. Python might make better sense. Very little Free Software needs to be so close to the metal, and it was just a historical accident that we got so much written in C.

Re: Fun facts about Rust's growing popularity

#74

Well, 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…

Rust is not for everything, but for the situations where GC is unsuitable (e.g. you have real-time constraints), and a few others, benefits become obvious (and it's hard to look back once you are there).

Yes it can be a pain to write. But I prefer the pain of making the compiler happy than the pain of debugging a weird segfault.

Re: Fun facts about Rust's growing popularity

#75

Rustaceans? Would recruiting agencies go for that in job ads? "Are you a top rustacean and looking for a challenge in AI and Big Data and want to work in an international team with young and dynamic rustaceans? "

Is "Rust" a positive-sounding name in the first place ? It's old, decaying metal. It's like saying your favorite image editor is Gimp. It is a fine piece of software, but sounds unprofessional for native English speakers.

Re: Fun facts about Rust's growing popularity

#76

For me, A totally cs newbee, the Rust team has established a great community. I have learned a lot from the e-mentor(contribute to rust or rust lib directly with the guidelines from rust core developers). Now I’m the founder of Rustacean group in my school.

Rustacean, that's the first time of heard of that name. Absolutely fantastic

You should enjoy this then: http://www.rustacean.net/

Re: Fun facts about Rust's growing popularity

#77
post #70

Earlier quoted context omitted.

You're overlooking that Rusts "solution"(borrowing, livetimes, etc. ) is not only solving the same problem that garbage collection tries to solve. Garbage collection is "only" solving the "memory resource problem". Rusts solution is a more general solution to the "general resource problem" .. like file handles, sockets and of course memory and besides that gives you tools to never get bitten by data races. Nothing (b…

>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…

Fun fact: what you did is a hand implementation of Rust's "drop flag" (https://doc.rust-lang.org/nomicon/drop-flags.html).

Re: Fun facts about Rust's growing popularity

#78
post #77
post #70

Earlier 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…

Fun fact: what you did is a hand implementation of Rust's "drop flag" ( https://doc.rust-lang.org/nomicon/drop-flags.html ).

That's pretty cool - it never occurred to me that determining drops required anything other than static analysis. Nice that it doesn't affect the layout of the types, either...which I'm guessing is why they added:

>The drop flags are tracked on the stack and no longer stashed in types that implement drop.

Re: Fun facts about Rust's growing popularity

#79

Well, 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…

> So if you just want a native language with a good type system and a growing ecosystem, where do you go? Still Rust or something else?

OCaml is a good choice. The ecosystem is definitely growing, though maybe not very quickly.

Re: Fun facts about Rust's growing popularity

#80
post #70

Earlier quoted context omitted.

You're overlooking that Rusts "solution"(borrowing, livetimes, etc. ) is not only solving the same problem that garbage collection tries to solve. Garbage collection is "only" solving the "memory resource problem". Rusts solution is a more general solution to the "general resource problem" .. like file handles, sockets and of course memory and besides that gives you tools to never get bitten by data races. Nothing (b…

>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/second-edition/ch16-03-shared...

----- edit: Just to clarify my point. The ownership model is a beautiful solution to the resource management problem. And as the parent pointed out, some concepts can be cleanly borrowed/reused in other languages.

But now, in Rust, in practice, you realize that this model requires a lot of boilerplate code just to make the borrow checker happy, even for simple things like using a lock: create Arc(Mutex(data)); clone the arc reference; move the new Arc reference to the new thread.

Post reply on HN