9 ms·
Rust 1.62.0
- stunt 4y agoHappy Compiler Happy Life
- brundolf 4y ago`cargo add` is such a small thing, but I'm so excited about it. Many tiny instances of friction as you have to open your browser and manually google a crate to find the latest version number so you can copy and paste it into your Cargo.toml
- loeg 4y agoderive(Default) for enums is cool, I like that.
- legerdemain 4y agoDang: "On HN, we handle this [release announcements] by treating submissions of the same-ish story as dupes for a year or so" https://news.ycombinator.com/item?id=23071428 https://news.ycombinator.com/item?id=23071428 Dang deleting Tauri's 1.0 announcement on the basis of this guideline: https://news.ycombinator.com/item?id=31764015#31790125 https://news.ycombinator.com/item?id=31764015#31790125 Meanwhile: - this thread - 1.61.0 https://news.ycombinator.com/item?id=31434936 https://news.ycombinator.com/item?id=31434936 - 1.60.0 https://news.ycombinator.com/item?id=30944709 https://news.ycombinator.com/item?id=30944709 - 1.59.0 https://news.ycombinator.com/item?id=30457261 https://news.ycombinator.com/item?id=30457261 - 1.58.0 https://news.ycombinator.com/item?id=29923390 https://news.ycombinator.com/item?id=29923390 - 1.57.0 https://news.ycombinator.com/item?id=29416915 https://news.ycombinator.com/item?id=29416915 - 1.56.0 https://news.ycombinator.com/item?id=28945420 https://news.ycombinator.com/item?id=28945420 - 1.55.0 https://news.ycombinator.com/item?id=28945420 https://news.ycombinator.com/item?id=28945420 ...
- legerdemain 4y agoIn fact, it looks like every Rust minor version since 1.0, all 62 of them, had a dedicated thread, and none of them were deleted.
- dagmx 4y agoRust, like many languages, rarely tick the major semver version. In Rust's case it may never after 1.x. Therefore, like many programming languages that get posts, the minor version is quite significant and worthy of independent discussion. The discussions aren't interchangeable
- threatofrain 4y agoYes, it's not interchangeable because the 1.0 of an anticipated project is a big deal. Meanwhile on Rust 1.62...
- dagmx 4y agoMaybe actually say what you want to say instead of alluding to some vague notion of trivialness.
- legerdemain 4y agoThat's fine, but beside the point. Let me repeat more clearly. Tauri, a framework (not mine), got robbed of its 1.0 announcement because there had been another thread about it in the past year. Rust, a language, has dozens of threads, roughly one per month, about minor version releases stand without being deleted. Does this make the contrast more clear?
- dagmx 4y agoI see multiple posts about Tauri 1.0 when I search, and saw the posts about Tauri here when they hit 1.0? Maybe it was taken down after, I'm not sure what transpired but perhaps it was a misunderstanding on dangs part, where he may be more familiar with Rust's release cadence. I'm not sure why jumping to the worst possible conclusion and aggressiveness is warranted.
- legerdemain 4y agoRather than rely on me to narrate the facts a third time, I encourage you to look at the linked Tauri thread and check the number and vintage of other threads about Tauri.
- cercatrova 4y agoGeneric associated types were supposed to be stabilized in 1.62 but there has been a recent backlash in the PR of what exactly to stabilize [0]. I posted it as its own separate post here [1]. [0] https://github.com/rust-lang/rust/pull/96709 https://github.com/rust-lang/rust/pull/96709 [1] https://news.ycombinator.com/item?id=31939077 https://news.ycombinator.com/item?id=31939077
- deleted 4y ago[deleted]
- eventhorizonpl 4y agoRust is the language that makes me look forward to the next day at work.
- deleted 4y ago[deleted]
- tempusr 4y agoThe new cargo add feature is a great QoL update.
- epage 4y agoFor those unaware, some ask "why" - No need to look up the version (though some IDEs do it for you) - Auto-completion - It shows you what features the crate has and whether they are activated, making it easier to discover features you need to enable or what you can remove to improve compile times - Make it easier to document how to add a set of dependencies needed for a project (e.g. "Run `cargo add serde serde_json -F serde/derive`") - The opportunity for more QoL improvements, see https://github.com/rust-lang/cargo/issues?q=is%3Aopen+is%3Aissue+label%3ACommand-add https://github.com/rust-lang/cargo/issues?q=is%3Aopen+is%3Ai... It is impressive the amount of work it took to get this ready. I took over the effort almost a year ago and at times was working full time on it (thanks to my employer). Just my part included - a near rewrite of the format-preserving toml parser (toml_edit) - a major revamp of the UI - a major revamp of testing - a near rewrite to make it compatible with cargo's code base
- pdimitar 4y agoThanks for your hard work! Any plans to add `cargo rm/remove` in the future? Or modifying the features in-place?
- cercatrova 4y agoYes, although there's no timeframe in place: https://old.reddit.com/r/rust/comments/vocp5k/announcing_rust_1620/iecf7kw/?context=99 https://old.reddit.com/r/rust/comments/vocp5k/announcing_rus...
- dthul 4y agoIt's very cool that mutexes on Linux don't require an allocation anymore! A very common pattern is to use an Arc<Mutex<T>> for sharing ownership across threads and as far as I can tell this will now only require one allocation instead of two.
- zwerdlds 4y agoNot being too familiar with the underlying mechanics, I'm curious to know- How much will this improve the performance?
- loeg 4y agoMinute -- you're often going to be better off eliminating the Arc/Mutex anyway. A (very) small but concrete win for some workloads.
- staticassertion 4y ago> you're often going to be better off eliminating the Arc/Mutex anyway Not always. Mutexes can be really fast (10-20ns), especially since they often optimistically spin, and Arc in Rust is (often) relatively low cost since you can hand out "free" refs without touching the atomic. If removing the Arc/Mutex would require allocations the Arc/Mutex could easily be faster.
- yakubin 4y agoDon't atomic operations trigger cache synchronisation in CPUs? Doesn't that affect performance negatively? That would mean even a non-contended mutex would affect performance negatively. I suspect it depends a lot on the specific workload (and maybe even what addresses data is stored at in memory), so I'd measure the specific case, but that's my a priori gut feeling.
- loeg 4y agoIf it's non-contended, the mutex's cache line probably stays Exclusive in the local CPU and acquiring is pretty cheap.
- pachico 4y agoI can't really understand why I'm fluent in various languages but not Rust... I might have found my intellectual glass ceiling...
- tmp_anon_22 4y agoIts a feature rich language with a more-complex syntax then many languages and a community that is still discovering its best practices, critical libraries, and more. Its a difficult language to learn full-stop. And its a language that can be used to produce valuable software, but probably should not be the first choice for many applications at most organizations.
- nicoburns 4y agoAre all the other languages fairly mainstream ones? Most procedural/OOP languages are similar enough that if you’ve learnt one you’ve basically learnt them all. Rust is a just a bit different and requires actually learning something new. For 90% of people I think the main hurdle is realising this.
- srvmshr 4y agoWhat is the best way to pick up Rust and its best practices as of today? References welcome (thanks in advance!)
- staticassertion 4y agoWrite some code, listen to the compiler's feedback, don't worry about "good" or "fast", just get things working.
- ArchOversight 4y agoThe Rust Programming Language book is absolutely fantastic: https://doc.rust-lang.org/book/index.html https://doc.rust-lang.org/book/index.html It's a pretty quick read and gives you a good handle on Rust fairly quickly.
- olalonde 4y ago
- nixpulvis 4y agoTotal ordering on floats! Does this mean we can sort &mut [f32] now!?
- kibwen 4y agoYes, but note that it's not an implementation of the Ord trait, it's just a convenient opt-in comparison method. You would need to provide it as part of a custom sorting predicate, as shown in the documentation.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- Bromeo 4y agoFrom the docstring for total_cmp `bois.sort_by(|a, b| a.weight.total_cmp(&b.weight));` So yes, but you were already able to use `partial_cmp` before.
- pavon 4y agoYeah, the difference is that total_cmp can handle NaNs, whereas with partial_cmp you either had to add your own handling, or get panics on NaN if you blindly call partial_cmp.unwrap(). I think in most cases, splitting NaNs across the start and end of the list isn't desired behavior, so I'll probably keep using partial_cmp with my own handling.
- nixpulvis 4y agoDoes SQL define a default order/placement for NULLs in numeric (or otherwise) columns?
- tialaramex 4y agoI think I'd be happier to see total_cmp anywhere that it's clear we want some consistent order and it's not important what the order actually is. The hand-rolled solution risks inconsistency. Given the opportunity to pick the order, people are going to pick different orders, sometimes by mistake, and providing total_cmp fixes that. I can see that in things which decided they should be Ord but internally have a f32 and so they need to implement the comparison themselves, total_cmp seems like it's almost always going to be the right choice for that unless partial_cmp with unwrap() is definitely correct and they're sure of it.
- ridiculous_fish 4y agoEdit: Rust 1.62 uses futexes directly; ParkingLot is a thing but not backing mutex on Linux. Thanks to ibraheemdev for the correction. I'm working to understand how Rust 1.62 avoid allocations for futex-based locks. I think the summary is this: 1. A mutex is a u8. The mutex fast path is locking via atomic ops to set a bit. 2. Contention is resolved by adding the blocked thread into a wait queue. The queue is allocated/discovered via a global hash table, keyed by the address of the mutex. The mutex keeps a stable address while locked, as the lock holds shared ownership and so the mutex cannot be moved for the duration. I ported a POSIX semaphore wrapper from C++ to Rust, and needed an extra allocation for the same reason, to get an int with a stable address. Unfortunately this technique won't work for semaphores, they need to be async-signal safe. So I'm still stuck with `Pin<Box<UnsafeCell<sem_t>>>` where in C++ it's just `sem_t` and a deleted move constructor. Anyways this is a lot of hoops to jump through to avoid non-movable types, hope it's worth it!
- cwzwarich 4y ago> 2. Contention is resolved by adding the blocked thread into a wait queue. The queue is allocated/discovered via a global hash table, keyed by the address of the mutex. The mutex keeps a stable address while locked, as the lock holds shared ownership and so the mutex cannot be moved for the duration. Wouldn't this break any platform-specific priority/importance donation mechanisms, or does Linux have a way to work around this?
- ridiculous_fish 4y agoActually upon reflection why wasn't this just trivial for futex? A Linux futex requires only user-space initialization, and it has a stable address while locked for the same reason, so you can get the same zero-allocations without the use of parking lot.
- ibraheemdev 4y agoIt uses the linux futex api directly, not a user space parking lot as used by the parking-lot crate.
- monocasa 4y agoNeat, although the blog post doesn't make this explicit, the new x86_64-unknown-none target disables the red zone, truly making it useful in kernels where otherwise an incoming interrupt would corrupt your stack.
- guthriej 4y agoI hadn’t heard of the red zone, this article explained it quite well: https://os.phil-opp.com/red-zone/ https://os.phil-opp.com/red-zone/.