The nominees are:

• Jakob Degen
• Amanieu d'Antras
• Felix Klock
• lcnr
• scottmcm
• Michael Goulet
• Santiago Pastorino
• Jubilee
• Mara Bos

All these posts about async are making the freedom to choose our runtime seem like a bad thing.

For most people, we can just accept Tokio as the de facto standard, and everything is good. Having the other runtimes only makes things better. Don't do anything weird and it won't be too much work if you need to change.

Any big change you miss is bound to either be implemented in Tokio or be too different for any abstraction to save you from the work.

If you're writing a library that you want to be reusable by everyone, I understand your frustration that it's not easier to make it universal for all async runtimes. You can still choose one, minimize the code you would have to change to implement others, and appreciate that in almost every other programming language you don't get more than one async engine anyway.

A few relevant links:

• website: https://comfyengine.org/
• announcement blog post: https://comfyengine.org/blog/first/
• dev: https://loglog.games/

A short TL;DR for those who don't want to click: Comfy is what LogLog games has been using for their games for the past year or so. It's 2D only, opinionated, and simple.

Comfy is mostly similar to macroquad, but it's much more batteries included and bakes in a lot more things.

in sequelize (javascript) it's pretty straightforward to either find a record, or create it if it doesn't exist. I don't see anything similar with sea-orm. There's a 'save' method that seems to insert or update, but I need to know details about the record ahead of time :/

Any ideas?

https://sequelize.org/docs/v6/core-concepts/model-querying-finders/

100x faster, 100x smaller, and it runs in the browser!

The “tl;dr” is that we rewrote it (mostly) in Rust which compiles to WebAssembly for VS Code or the web, and to native binaries for Python. It’s over 100x smaller, over 100x faster, much easier to install & use, works fully in the browser, and is much more productive & fun for the team to work on.

The Matrix Authentication Service has been created to support the migration of Matrix to an OpenID Connect (OIDC) based architecture as per MSC3861.

It is not intended to be a general purpose Identity Provider (IdP) and instead focuses on the specific needs of Matrix.

Furthermore, it is only intended that it would speak OIDC for authentication and not other protocols. Instead, if you want to connect to an upstream SAML, CAS or LDAP backend then you need to pair MAS with a separate service (such as Dex or Keycloak) which does that translation for you.

Whilst it only supports use with Synapse today, we hope that other homeservers will become supported in future.

If you need some other feature that MAS doesn't support (such as TOTP or WebAuthn), then you should consider pairing MAS with another IdP that does support the features you need.

https://matrix-org.github.io/matrix-authentication-service/

https://github.com/matrix-org/matrix-authentication-service/

Some context https://hachyderm.io/@Mara/111102308828739597

🦀 Have you ever purposely made use of the UnwindSafe or RefUnwindSafe traits in #rustlang?

I'm wondering if Rust would have been better off without these (somewhat confusing) traits.

1.72.1 resolves a few regressions introduced in 1.72.0:

• Partially revert codegen change, improving codegen

• rustdoc: Fix self ty params in objects with lifetimes

  • Fix regression in compile times
  • Resolve some ICEs in the compiler: #115215 #115559