cross-posted from: https://discuss.online/post/5803977

About this Book

The Rust programming language is extremely well suited for concurrency, and its ecosystem has many libraries that include lots of concurrent data structures, locks, and more. But implementing those structures correctly can be difficult. Even in the most well-used libraries, memory ordering bugs are not uncommon.

In this practical book, Mara Bos, team lead of the Rust library team, helps Rust programmers of all levels gain a clear understanding of low-level concurrency. You’ll learn everything about atomics and memory ordering and how they're combined with basic operating system APIs to build common primitives like mutexes and condition variables. Once you’re done, you’ll have a firm grasp of how Rust’s memory model, the processor, and the role of the operating system all fit together.

With this guide, you’ll learn:

• How Rust's type system works exceptionally well for programming concurrency correctly
• All about mutexes, condition variables, atomics, and memory ordering
• What happens in practice with atomic operations on Intel and ARM processors
• How locks are implemented with support from the operating system
• How to write correct code that includes concurrency, atomics, and locks
• How to build your own locking and synchronization primitives correctly

Available free of charge. But I doubt I'll ever read it. Never enough time and energy for everything.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

As part of my Sudoku Pi project, I’ve been experimenting with improving the Bevy UI experience. I’ve collected most of my thoughts on this topic in this post.

I found this review very interesting. It goes quite deep into the different problems. The author have done the research and does s good job of presenting it in a clear and understandable way.

cross-posted from: https://jlai.lu/post/4802347

Hi all!

What?

I will be starting a secondary slot/sessions for the Reading Club, also on "The Book" ("The Rust Programming Language"). We will, also, very likely use the Brown University online edition (that has some added quizzes & interactive elements).

Why?

This slot is primarily to offer an alternative to the main reading club's streams that caters to a different set of time zone preferences and/or availability.

When ?

Currently, I intend to start at 18:00 UTC+1 (aka 6pm Central European Time). Effectively, this is 6 hours "earlier in the day" than when the main sessions start, as of writing this post.

The first stream will happen on the coming Monday (2023-03-04).

Please comment if you are interested in joining because you can't make the main sessions but would prefer a different start time (and include a time that works best for you in your comment!). Caveat: I live in central/western Europe; I can't myself cater to absolutely any preference.

How ?

We will start from the beginning of "The Book".

There are 2 options:

1. mirror the main sessions' pace (once every week), remaining ~4 sessions "behind" them in terms of progression through "The Book"
2. attempt to catch up to the main sessions' progression

I am personally interested in trying out 2 sessions each week, until we are caught up. This should effectively result in 2-3 weeks of biweekly sessions before we slow back down. I'm not doing this just for me, however, so if most people joining these sessions prefer the first option I'm happy to oblige.

I will be hosting the session from my own twitch channel, https://www.twitch.tv/jayjader . I'll be recording the session as well; this post should be edited to contain the url for the recording, once I have uploaded it.

Who ?

You! (if you're interested). And, of course, me.

TIL: Sweden had February 30 in 1712 https://en.wikipedia.org/wiki/1712_in_Sweden , so I decided to see how chrono handled that.

use chrono::TimeZone;
use chrono_tz::Europe::Stockholm;

fn main() {
    let feb30 =  Stockholm.ymd(1712,2,30);
    println!("Date: {:?}", feb30);
}

 target/debug/feb30
thread 'main' panicked at /home/snaggen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chrono-0.4.34/src/offset/mod.rs:252:40:
No such local time
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Result (as expected): Not well! 😄

I also tested Java with

ZonedDateTime feb30 = ZonedDateTime.of(1712,2,30, 0,0,0,0, ZoneId.of("Europe/Stockholm"));

with simmilar result

java.time.DateTimeException: Invalid date 'FEBRUARY 30'

So, lets take a minute of silence for all the programmers of history related software, may the spagetti monster have mercy on their souls.

Great to see FIPS support for Rustls, will probably help for government related projects and such.

Hey, I held a talk at the Vienna rust meetup in January about how we use rust to write data pipelines in our company. I really enjoy writing ETLs like this so I wanted to share

Always interesting to hear experiences from larger projects. It addresses the myth about Rust slowing down development (TL;DR: it doesn't), and a bit about async and scientific rust.

I found this page, and thought it might be worth sharing. It helped me find AreWe* pages I didn't know existed, like https://areweideyet.com/ to get an indication about the state of IDEs for rust.

This is a Rust replacement for debsums (on Debian/Ubuntu/...) and paccheck (on Arch Linux and derivatives). It is much faster than those thanks to using all your CPU cores in parallel. What it does is check files installed by your package manager for changes and reports those on stdout.

This is a project I have been working on over the past few weeks. There are more details (including benchmarks) in the readme.

I normally don't advertise my open source projects (having users other than yourself is both a blessing and a curse), but since there was recent discussion on how to grow this lemmy group I'd thought I'd post it. Maybe it is useful to some of you.

I also spent quite some time on optimising this (including a lot of benchmarking, profiling and trying alternative solutions). In the end I'm happy with the performance, though I am considering io-uring for disk IO.

The main goal of this project is not actually the program produced so far, but to continue building this into a library (currently very little is exposed as pub, because the API will change). I have a larger project in the planning phase that needs this (in library form) as part of it.

Hello fellow rustaceans! Recently, there was a thread about how we can grow this community (how can I link to posts across servers?), where I already talked briefly about this topic, saying that I did not know if it is worthy of a full post here, as most things seem to be pretty professional looking links to talks and blogs. I've gotten some encouragement to post it, so here we go:

When to use a library instead of a CLI

I'm working on a little project called Autcrate in my free time, which aims to streamline the release and publishing process (what exactly it does isn't really important for this discussion). Autocrate uses git to get the path of the current repo, tags and pushes releases, generates a change log from commits and so on.

Up until a week ago, I was just using the git2 library crate, which offers the functionalities of libgit2 for rust. While good, using this crate is much more complicated than for example just executing git push from my program using std::process::command. I am only using the porcelain functionalities of git (as of now), so all functionality could be achieved by calling the CLI interface.

Question

When is it acceptable to use CLI Commands instead of using libraries provided for that same software?

Is it generally better to use API/ABI from libraries, or is it maybe even better to use the CLI interface, reducing the list of dependencies?

Pro and Con of using Commands instead of libraries

(this is of course not an exhaustive list. I will edit it if something comes up in the thread.)

Edit

Alright then. Thank you for your answers. While using the git CLI would probably be fine, since it's very stable and available on most systems (especially those for CI/CD), it might change and is at best hacky. I'll be doing the "right" thing and use libgit2 instead of just calling CLI commands.

While working on Kellnr, I updated the dependencies. It seems that the update of cargo breaks the build. I created an issue on github. Maybe somebody here has an idea for a simple fix.

I'm building up to a new idiom for dealing with generic numeric types and traits, but this is the first step. I made it more general than I probably needed for my purposes, but it seemed like a good idea to just solve the whole problem given that I was going to do much of the work anyways.

Credit to the hereditary crate for inspiration on how to do it.

I'm very new at this software publishing thing, so lemme know if I messed something up.

What are you building with Rust?

Are you using Rust at work? Hobby projects?

Why did you choose Rust for your project?

I’m a self taught JavaScript developer. I’ve got many years of experience but I’ve never worked in a language I use to manage memory in any form. I’ve been having a lot of fun learning rust and learning about what’s physically happening when a program is executed.

I’ve been watching Core Dumped (https://youtube.com/@CoreDumpped) and Low Level Learning (https://youtube.com/@LowLevelLearning) and it’s been so helpful. I have also been watching Let’s Get Rusty which is good for learning rust specifically, but I’m looking for more memory focused or detailed videos or channels talking about why things are happening. Do you know if any other channels, videos or resources that could help me learn more about this?

The title says it all: How can we grow the Rust community here on Lemmy? Many users fled Reddit or are here for different reasons. But compared to it's commercial big brother, the Rust community here, feels more or less dead. I would like to discuss ideas, on how we can changes that and make Lemmy the default for Rust related discussions, instead of Reddit.

Just to reiterate what the linked blog post mentions; this isn't a bug with Iced, specifically, but seemed to have been brought into light by having Iced 0.12.0 among the dependencies. Many variants of this bug has been reported to the Rust compiler repository and some seem to be fixed by the next trait resolver.