Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Rust experience after eight years

codecs.multimedia.cx

Post reply on HN
Print view View original

41–50 of 55 posts

Re: My Rust experience after eight years

#41

Post by kelnos »

lfourunderscore wrote: post #6

> My criteria were subjective but simple to understand: the language should introduce new concepts (as Principia Discordia puts it, ’tis an ill wind that blows no minds) [...] I wonder how many people share this opinion. I derive as much if not more value from the refinement of existing concepts than the introduction of new ones. Wanting new concepts just for it's own sake is wild to me.

Wanting to encounter new concepts feels like a basic requirement for intellectual curiosity.

I suppose there's a difference between wanting to encounter new concepts, and wanting to find them as a part of a programming language you've decided to learn and use, though.

Re: My Rust experience after eight years

#42

Post by rob74 »

lfourunderscore wrote: post #6

> My criteria were subjective but simple to understand: the language should introduce new concepts (as Principia Discordia puts it, ’tis an ill wind that blows no minds) [...] I wonder how many people share this opinion. I derive as much if not more value from the refinement of existing concepts than the introduction of new ones. Wanting new concepts just for it's own sake is wild to me.

The whole list sounded a bit strange to me - it looks more like a list he compiled after the fact to explain why he chose Rust, rather than some criteria he had decided on before evaluating several languages. Of course, I can sympathize with wanting to use a language that tries new concepts, but there's something to be said in favor of languages like Go that make a point of only using tried and tested concepts and making sure that they work well together too...

Re: My Rust experience after eight years

#44

Post by akubera »

nottorp wrote: post #34
eptcyka wrote: post #20

Earlier quoted context omitted.

Sharing resources is always a source of deadlocks and bugs, I don’t see a feasible resolution to that in a programming language. I don’t think one gets into deadlocks more often than any other language with Rust, but you are not experiencing most other concurrency bugs, which makes it feel like deadlocks are a bigger issue.

Wait, I've been told by "evangelists" that besides not having any security vulnerabilities, you also can't have deadlocks in Rust!

As others have said, Rust's ownership model prevents data races, as it can prove that references to mutable data can only be created if there are no other references to that data. Safe Rust also prevents use-after-free, double-free, and use-uninitialized errors. Does not prevent memory leaks or deadlocks.

It's easy to write code that deadlocks; make two shared pointers to the same mutex, then lock them both. This compiles without warnings:

    let mutex_a = Arc::new(Mutex::new(0_u32));
    let mutex_b = mutex_a.clone();
    
    let a = mutex_a.lock().unwrap();
    let b = mutex_b.lock().unwrap();
    println!("{}", *a + *b);

Re: My Rust experience after eight years

#45

Post by rob74 »

zem wrote: post #12
unwind wrote: post #7

Earlier quoted context omitted.

I was not familiar with the term, so I had to look it up. It's about code like this: a := b the `:=` looks vaguely like a walrus. The most common reference language seems to be Python [1]. The usage is for making assignment remain an expression, so you can do stuff like area = (width := get_width()) * (height := get_height()) or something, and have the top-level expression remain valid since the sub-expressions are a…

python's use is the unusual one; the most common use (dating all the way back to algol) is to use it for assignment, so you can use = for equality. https://en.wikipedia.org/wiki/Assignment_(computer_science)#...

Go uses "==" for equality checks, "=" for assignments, and ":=" for "declaration/assignment with type inference" - so it's different from both Python (you can use ":=" as part of an expression in Go too, but you can also use "=") and Algol/Pascal (where it's used only for assignment).

Re: My Rust experience after eight years

#46

Post by nottorp »

aw1621107 wrote: post #37
nottorp wrote: post #34

Earlier quoted context omitted.

Wait, I've been told by "evangelists" that besides not having any security vulnerabilities, you also can't have deadlocks in Rust!

Those "evangelists" would be wrong, then. Rust prevents data races by default, but doesn't prevent deadlocks by default. It is possible to use Rust's type system to statically ensure the lack of deadlocks [0], but that's not provided by default. [0]: e.g., https://docs.rs/lock_ordering/latest/lock_ordering

I should have bookmarked the HN post that said it :)

It was one of the usual "if you'd have rewritten it in rust you'd have had no problems" posts. But instead of the usual memory safety list, they also added no deadlocks to the benefits.

Re: My Rust experience after eight years

#47

Post by onetoo » 

  > Even more annoying is that I have to duplicate the iterator code: as I often work with frames that may be flipped bottom-up I want to write code like
  >
  >    let mut iterator = if !flipped {
  >       data.chunks_mut(stride)
  >    } else {
  >       data.chunks_mut(stride).rev()
  >    };
  >    for line in iterator { ... }
  >
  > but I can’t since objects have different type (and probably size) and there’s no realistic way to coerce them to the same interface.
For this specific case there is a relatively ergonomic solution using dynamic trait objects + temporary lifetime extensions, available since Rust 1.79:

  let iterator: &mut dyn Iterator = if !flipped {
    &mut data.into_iter()
  } else {
    &mut data.into_iter().rev()
  };
  for line in iterator { ... }
Alternatively, if this is not a feasible solution (e.g. we want to return the new iterator to an outer scope, or the overhead of dyn indirection is unacceptable in this context), one can consider using itertools::Either instead:

  use itertools::Either;
  fn conditionally_flip_iter(
      data: I,
      flipped: bool,
  ) -> impl Iterator {
      if !flipped {
          Either::Left(data.into_iter())
      } else {
          Either::Right(data.into_iter().rev())
      }
  }
  // ...
  let mut iterator = conditionally_flip_iter(data, flipped);
  for line in iterator { ... }

Re: My Rust experience after eight years

#48

Post by rich_sasha »

jessekv wrote: post #11
unwind wrote: post #7

Earlier quoted context omitted.

I was not familiar with the term, so I had to look it up. It's about code like this: a := b the `:=` looks vaguely like a walrus. The most common reference language seems to be Python [1]. The usage is for making assignment remain an expression, so you can do stuff like area = (width := get_width()) * (height := get_height()) or something, and have the top-level expression remain valid since the sub-expressions are a…

Its also one of the more controversial features and its introduction sparked Guido's stepping down. Since it was introduced, I have been looking but there has been only a handful of times where I could use it to write clearer code. I'm curious if anyone actually likes it. edit: A quick search shows that I do use it regularly in while loops, e.g.: while result := my_fun(): ...

IIRC he stepped down because he thought it's a good feature and people pointlessly moaned about it. Not because he thought it's controversial and has enough.

I used it a small handful of times. But it also seems like quite a source of footguns. Many examples here: https://github.com/satwikkansal/wtfpython rely on the misuse of the walrus operator.

Re: My Rust experience after eight years

#50

Post by pklausler »

jabl wrote: post #13
weinzierl wrote: post #2

"Of course you can argue that Rust recently adopted language specification, but if you take a second to learn more about it you’ll find out that it comes essentially from outside." It is worth noting that the Ferrocene specification is made for the certification of the Ferrocene compiler as its sole purpose. It is neither intended nor suitable to implement a compiler based on it.

I'm not familiar at all with the Ferrocene specification, but in general I do wonder if the ISO C/C++/Fortran (singling these out as I'm somewhat familiar with them, not saying there aren't other languages with similar spec processes) process of a prose spec is really the best way to go in this day and age? Those languages certainly have their historical reasons for the specs being the way they are, but I'm not convi…

A language standard without a reference implementation or blessed test suite can be a real problem due to ambiguity, contradiction, and omissions. When there are existing implementations of a language that are expected to keep up with an evolving standard that doesn't have these things, you can end up with a messy situation like Fortran has, in which the portability of code across compilers becomes a pragmatic job that's not related much to standard conformance.
Post reply on HN