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

21–30 of 55 posts

Re: My Rust experience after eight years

#21

Post by tinco »

Animats wrote: post #3

Ah, this is a codec guy. That yields an unusual list of desired features. Bit-pushing predominates. Inline assembler and access to SIMD instructions is important. Speed in tight loops is essential.

Their wishlist is composability, being able to write performant code, being able to perform other low-level operations, being able to use assembly and a reasonably easy build system.

I'd argue that's not just a fairly common list of desired features but that if there's more than 1 of those desires not in your own list then there's probably better languages than Rust to consider.

Re: My Rust experience after eight years

#22

Post by singhrac »

miohtama wrote: post #15
jessekv wrote: post #11

Earlier quoted context omitted.

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(): ...

I have written Python since 2003 and used walrus only once. It's unnecessary.

Eh, I write a lot of Python and while it's unnecessary, it can make code easier to read if not overused.

  if (config_fn := base_dir / "config").exists():
      ...
is just a tiny bit shorter than this:

  config_fn = base_dir / "config"
  if config_fn.exists():
      ...
but if you do this enough times (if you are handling a lot of possible errors / missing data, etc.) it can definitely shorten the code.

Re: My Rust experience after eight years

#23

Post by eptcyka »

sigi64 wrote: post #18
ultimaweapon wrote: post #9

For me lack of language specification is not a problem and it is good that Rust only have one implementation so I don't have a headache to support multiple compilers like C++. The only problems I have with trait is lack of const function and trait upcasting, which just solved by 1.86 that released yesterday. For iterator type mismatched it does not cause much problem since I can create a dedicated generic function to…

You can use the parking_lot mutex implementation crate, which includes support for deadlock detection. Personally, I also try to avoid using Tokio's async mutexes.

Tokio mutexes are only useful if a lock needs to be held across suspension points. Since futures can migrate threads between suspension points and most regular mutexes on most platforms do not support being unlocked from a different thread, tokio’s mutex has a very narrow but a well defined use case.

Re: My Rust experience after eight years

#24

Post by aw1621107 »

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…

Wasm sounds right up your alley! From my understanding the Wasm spec is formally specified and they just adopted tooling to generate prose/mechanically-checkable proofs/etc. from the formal spec [0].

[0]: https://webassembly.org/news/2025-03-27-spectec/

Re: My Rust experience after eight years

#25

Post by uecker »

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…

You can not really write a formal spec without having prose first. It would be nice to have a formal spec for C, and C is one of the languages where this is feasible (and also partially done by various people).

Re: My Rust experience after eight years

#26

Post by Xylakant »

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.

Disclaimer: I'm one of the managing directors at Ferrous Systems, so biased.

The FLS was written with that specific intend in mind, but that mostly limits the scope of the spec that Ferrous Systems is/was interested in maintaining. We were also not interested in adopting large scale contributions on parts that Ferrous Systems doesn't need - we're a small outfit after all, 20ish people, and we don't have the capacity to maintain a full specification.

However, that's no fundamental barrier that limits the specification per se - now that the Rust project is adopting it, others can contribute and pick up maintenance slack. We'll certainly continue to contribute to the things that we are interested in seeing, but if someone wants to build a compiler based on the spec, they can contribute the parts needed.

On the upside: The spec in its current shape is good enough to certify the compiler and I know people have started building other things on the FLS. Structurally, the tooling and the content is fine - so I believe it can serve as a good nucleus for the Rust languages spec.

As for the "strange" aftertaste in the process of adopting the FLS that's mentioned in the article:

I don't believe that the Foundation/Project adopting the Ferrocene Language Specification is bad. While Ferrous Systems as a company holds no official position in the project, we consider ourselves very much part of the project. We have people that head working groups, one of our employees was in the governing council, my brother and co-founder is founding member of the Foundation. Rust-Analyzer is maintained by my esteemed colleague Lukas. We draw on the project - after all we certified the projects rustc as we found it. We contribute to the project as part of the work we do. We started writing a spec because no one had written one, and specifically *we* had a need. And that's essentially how things work in open source: We scratch our itch - and in the process lift the tide for everyone. The project taking some time to figure out what the project wants is not surprising: They have their needs, we have ours, and they often overlap but they're not identical. We're not the rust project. The project is not Ferrous Systems.

Re: My Rust experience after eight years

#29

Post by jessekv »

singhrac wrote: post #22
miohtama wrote: post #15

Earlier quoted context omitted.

I have written Python since 2003 and used walrus only once. It's unnecessary.

Eh, I write a lot of Python and while it's unnecessary, it can make code easier to read if not overused. if (config_fn := base_dir / "config").exists(): ... is just a tiny bit shorter than this: config_fn = base_dir / "config" if config_fn.exists(): ... but if you do this enough times (if you are handling a lot of possible errors / missing data, etc.) it can definitely shorten the code.

If you have to wrap it in parens, it might be shorter but it's not really clearer.

In other contexts, parens are a good indication it's time for a new line.

But I can agree something like this does look clean and clear:

  if value := obj.get("key"):
      ...
Post reply on HN