overview for BB

Is the async_trait still necessary for dync Trait with async methods? by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 4 points 4 days ago

dyn compatibility of the trait itself is another matter. In this case, an async method makes a trait not dyn-compatible because of the implicit -> impl Future opaque return type, as documented here.

But OP didn't mention whether dyn is actually needed or not. For me, dyn is almost always a crutch (exceptions exist).

Is the async_trait still necessary for dync Trait with async methods? by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 6 points 4 days ago

If I understand what you're asking...

This leaves out some details/specifics out to simplify. But basically:

async fn foo() {}

// ^ this roughly desugars to

fn foo() -> impl Future<()> {}

This meant that you couldn't just have (stable) async methods in traits, not because of async itself, but because you couldn't use impl Trait in return positions in trait methods, in general.

Box<dyn Future> was an unideal workaround (not zero-cost, and other dyn drawbacks). async_trait was a proc macro solution that generated code with that workaround. so Box<dyn Future> was never a desugaring done by the language/compiler.

now that we have (stable) impl Trait in return positions in trait methods, all this dance is not strictly needed anymore, and hasn't been needed for a while.

Why is Rust so bare-bones? by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 1 points 6 days ago

I was just referring to the fact that they are macros.

Why is Rust so bare-bones? by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 27 points 1 week ago

Not sure if you're talking about the language, or the core/alloc/std libraries, or both/something in-between?

Can you provide specific examples, an which specific languages are you comparing against?

10

Wild linker v0.8 released (and updated benchmarks) (github.com)

submitted 1 week ago by BB_C@programming.dev to c/programming@programming.dev

0 comments fedilink

`ffmpReg`: a complete rewrite of ffmpeg in pure Rust by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 23 points 3 weeks ago

An actually serious project that is not at the "joke" stage. Zero LLM use too:
https://nihav.org/

For audio at least, people should be aware of:
https://github.com/pdeljanov/Symphonia

16

koto v0.16.0 released (koto is a scripting programming language) (github.com)

submitted 6 months ago* (last edited 6 months ago) by BB_C@programming.dev to c/programming@programming.dev

4 comments fedilink

35

[OC] Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead! (programming.dev)

submitted 10 months ago* (last edited 10 months ago) by BB_C@programming.dev to c/programming@programming.dev

0 comments fedilink

https://nlnet.nl/news/2025/20250321-call-announcement-core.html

Notes

Projects meaningfully sharing two programming languages get 0.5 a point each, even if the split is not exactly half-half.
Two projects are listed under "Multi/Misc/Other" which is opinionated, and some may disagree with.
Three points (5 projects) are assigned to "Unaccounted/Not Available". Two of the projects have no code at all (related to the grant, or otherwise). One project with no published code is (charitably) listed under "Python", however, since the author mentions Python+QT as the choice for implementation.

1.5 (3 projects) C++

https://github.com/IObundle/iob-versat
(software part = 0.5, hardware is Verilog)
https://github.com/overte-org/overte
(0.5 C++, 0.5 JS)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code, but KDE/Plasma is C++, so charitable 0.5 for C++, 0.5 unaccounted)

1 Clojure

https://github.com/NyanCAD/Mosaic

1 Assembly

https://lib25519.cr.yp.to
(grant covers NEON vector implementation)

1 Haskell

https://github.com/ghc-proposals/ghc-proposals

1 Julia

https://github.com/PeaceFounder/AppBundler.jl

0.5 Shell

https://git.syndicate-lang.org/synit/synit
(0.5 rust, 0.5 shell)

2* Multi/Misc/Other

https://github.com/IObundle/iob-linux
(build project, a mix of python, Make, and C from OpenSBI)
https://unifiedpush.org
(specification for Android and D-Bus. Implementations in Go, C, Kotlin, and Flutter)

3* (5 projects) Unaccounted/Not Available

https://www.gnunet.org
(possible non-native Android yet to be written)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code but, KDE/Plasma is C++, so 0.5 for C++, 0.5 unaccounted)
https://nlnet.nl/project/LicenseCompatibilityAutomation
(no external link or specific info about the implementation)
https://librediagnostic.com
(fully unaccounted, site pages "under construction")
https://github.com/mapterhorn
(fully unaccounted, from org readme "Coming soon...")

21

[OC] Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead! (programming.dev)

submitted 10 months ago by BB_C@programming.dev to c/rust@programming.dev

0 comments fedilink

https://nlnet.nl/news/2025/20250321-call-announcement-core.html

Notes

Projects meaningfully sharing two programming languages get 0.5 a point each, even if the split is not exactly half-half.
Two projects are listed under "Multi/Misc/Other" which is opinionated, and some may disagree with.
Three points (5 projects) are assigned to "Unaccounted/Not Available". Two of the projects have no code at all (related to the grant, or otherwise). One project with no published code is (charitably) listed under "Python", however, since the author mentions Python+QT as the choice for implementation.

9.5 (10 projects) Rust

https://git.joyofhardware.com/Products/FastWave2.0
https://github.com/slint-ui/slint
https://github.com/stalwartlabs/mail-server
https://github.com/dimforge
https://github.com/DioxusLabs/blitz
https://github.com/fdtshim
https://github.com/trynova/nova
https://github.com/yaws-rs
https://github.com/lycheeverse/lychee
https://git.syndicate-lang.org/synit/synit
(0.5 rust, 0.5 shell)

9 Python (8 + 1 project without code)

https://github.com/owasp-dep-scan/blint
https://github.com/web-platform-tests/wpt
https://github.com/niccokunzmann/open-web-calendar
https://git.xmpp-it.net/sch/Rivista
https://github.com/DataLab-Platform/DataLab
https://codeberg.org/IzzyOnDroid/rbtlog
https://gitlab.com/py3dtiles/py3dtiles
https://codeberg.org/flohmarkt/flohmarkt
https://rackweaver.app
(says python+qt, but no code yet)

6 (7 projects) C

https://mntre.com/sources.html
https://github.com/open-sdr/openwifi
https://wiki.musl-libc.org
https://github.com/LekKit/RVVM
https://github.com/skarnet/s6-rc
https://git.savannah.gnu.org/git/mes
(scheme interpreter, compiler + minimal libc in C = 0.5)
https://www.gnunet.org
(gnunet itself is C = 0.5, Anroid work would presumably use Java/Kotlin/Dart/... = 0.5 unaccounted)

3.5 (4 projects) TypeScript

https://github.com/cartesapp/cartes
https://github.com/edumeet
https://github.com/adorsys/open-banking-gateway
(0.5 Java, 0.5 TypeScript)
https://github.com/janeirodigital/sai-js
(grant is about specification work. But implementation is in TypeScript)

3.5 (4 projects) Java

https://github.com/slovensko-digital/autogram
https://github.com/igniterealtime/Openfire
https://github.com/MarginaliaSearch/MarginaliaSearch
https://github.com/adorsys/open-banking-gateway
(0.5 Java, 0.5 TypeScript)

3 Kotlin

https://github.com/florisboard/florisboard
https://github.com/EventFahrplan/EventFahrplan
https://github.com/tuskyapp/Tusky

2.5 (3 projects) Hardware/Verilog/...

https://github.com/opera-platform/opera-dsp
https://github.com/simple-crypto/SMAesH
https://github.com/IObundle/iob-versat
(hardware part = 0.5, software is C++)

2.5 (3 projects) Scheme

https://codeberg.org/spritely/goblins
https://nlnet.nl/project/SchemeTestingFramework
(no external link in grant page)
https://git.savannah.gnu.org/git/mes
(scheme interpreter, compiler + minimal libc in C = 0.5)

2.5 (3 projects) JavaScript

https://github.com/CycloneDX/cdxgen
https://github.com/overte-org/overte
(0.5 C++, 0.5 JS)
https://nlnet.nl/project/TALER-integration-Nuxt
(no external link)

2 Nix

https://nlnet.nl/project/Nix-ControlPlane
https://github.com/ibizaman/selfhostblocks
(no external link)

2 Go

https://github.com/namecoin/encaya
(namecoint-core is written in C++, but the grant is about encaya)
https://github.com/hockeypuck/hockeypuck

1.5 (3 projects) C++

https://github.com/IObundle/iob-versat
(software part = 0.5, hardware is Verilog)
https://github.com/overte-org/overte
(0.5 C++, 0.5 JS)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code, but KDE/Plasma is C++, so charitable 0.5 for C++, 0.5 unaccounted)

1 Clojure

https://github.com/NyanCAD/Mosaic

1 Assembly

https://lib25519.cr.yp.to
(grant covers NEON vector implementation)

1 Haskell

https://github.com/ghc-proposals/ghc-proposals

1 Julia

https://github.com/PeaceFounder/AppBundler.jl

0.5 Shell

https://git.syndicate-lang.org/synit/synit
(0.5 rust, 0.5 shell)

2* Multi/Misc/Other

https://github.com/IObundle/iob-linux
(build project, a mix of python, Make, and C from OpenSBI)
https://unifiedpush.org
(specification for Android and D-Bus. Implementations in Go, C, Kotlin, and Flutter)

3* (5 projects) Unaccounted/Not Available

https://www.gnunet.org
(possible non-native Android yet to be written)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code but, KDE/Plasma is C++, so 0.5 for C++, 0.5 unaccounted)
https://nlnet.nl/project/LicenseCompatibilityAutomation
(no external link or specific info about the implementation)
https://librediagnostic.com
(fully unaccounted, site pages "under construction")
https://github.com/mapterhorn
(fully unaccounted, from org readme "Coming soon...")

32

Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language (koto.dev)

submitted 1 year ago by BB_C@programming.dev to c/rust@programming.dev

7 comments fedilink

cross-posted from: https://programming.dev/post/23822190

I added this language to my watch list some time ago and forgot about it, until I got a notification about a new release (0.15) yesterday.

I'm someone who is familiar with system languages (C, Rust) and shell languages (Bash, Zsh, ..). But don't have much experience, at a proficient level, with any languages setting in between.

So I gave Koto's language guide a read, and found it to be very well-written, and the premise of the language in general to be interesting. I only got annoyed near the end when I got to @base, because I'm an anti-OOP diehard 😉

I hope this one well start to enjoy some adoption.

49

Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language (koto.dev)

submitted 1 year ago by BB_C@programming.dev to c/programming@programming.dev

12 comments fedilink

I added this language to my watch list some time ago and forgot about it, until I got a notification about a new release (0.15) yesterday.

I'm someone who is familiar with system languages (C, Rust) and shell languages (Bash, Zsh, ..). But don't have much experience, at a proficient level, with any languages setting in between.

So I gave Koto's language guide a read, and found it to be very well-written, and the premise of the language in general to be interesting. I only got annoyed near the end when I got to @base, because I'm an anti-OOP diehard 😉

I hope this one well start to enjoy some adoption.

Intel Arc B580 tested in five games on Linux; you’re better off sticking with an AMD GPU for now by BB_C in c/linux@programming.dev

[-] BB_C@programming.dev 28 points 1 year ago

What serious Linux users buy GPUs based on raw gaming performance on release week?

I personally buy based on open-source driver support. And this includes long-term active support, AND developer approachability.

My current GPU is an AMD/Radeon one because of that. But I'm reconsidering my position when my next hardware upgrade comes.

I reported an AMD GPU driver issue to mesa once. It was tested, confirmed, and patched by a competent AMD developer within a few days. Now you have easily reproducible issues like this not even going past the testing phase after many months. And there are similar issues across all model generations.

If I were to upgrade my workstation next year, I would probably go with an AMD CPU and an Intel GPU, which is the exact opposite of my current setup 🙃. One should never rely on outdated perceptions.

26

kdl 6.0.0-alpha.1 (first version with a KDL v2 implementation) (github.com)

submitted 1 year ago by BB_C@programming.dev to c/rust@programming.dev

3 comments fedilink

74

COSMIC ALPHA 1 Released (Desktop Environment Written In Rust From System76) (system76.com)

submitted 1 year ago by BB_C@programming.dev to c/rust@programming.dev

11 comments fedilink

archived link

PSA: Claude is some much better at rust than ChatGPT by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 24 points 2 years ago

Hate to break it to you, but you're not really learning.

Technically right…? by BB_C in c/software_gore@programming.dev

[-] BB_C@programming.dev 26 points 2 years ago

You should be thankful it's not 18446744073709551615 days to go.

Ladybird announcement by BB_C in c/linux@lemmy.ml

[-] BB_C@programming.dev 38 points 2 years ago

A reminder that the Servo project has resumed active development since the start of 2023, and is making good progress every month.

If you're looking for a serious in-progress effort to create a new open, safe, performant, independent, and fully-featured web engine, that's the one you should be keeping an eye on.

It won't be easy trying to catch up to continuously evolving and changing web standards, but that's the only effort with a chance.

10

cushy v0.3.0 Released (github.com)

submitted 2 years ago by BB_C@programming.dev to c/rust@programming.dev

1 comments fedilink

20

slint 1.6.0 Released (github.com)

submitted 2 years ago by BB_C@programming.dev to c/rust@programming.dev

2 comments fedilink

Examples are not Documentation by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 51 points 2 years ago* (last edited 2 years ago)

Examples ARE usage documentation.

What value is this blog supposed to be adding exactly?
The fact that top-level and API descriptive explanations are important?
The fact that some projects don't have complete documentation?
To whom exactly would this be considered new information?

Rust without crates.io by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 29 points 2 years ago

What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian

[closes tab]

Async Rust Is A Bad Language by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 23 points 2 years ago* (last edited 2 years ago)

fn foo(＆big, ＆chungus)

is out,

async fn foo(＆BIG_GLOBAL_STATIC_REF_OR_SIMILAR_HORROR, sendable_chungus.clone())

is in.

Or maybe you know

fn foo(＆big, ＆chungus)

is out

async fn foo(big, chungus) -> (big, chungus)

is in

Or

async fn foo(big, chungus) {
  // ...
  tx.send((big, chungus)).await?;
  // ...
}

is in

Moving (movable/sendable) data is not limited by number or direction, you know. And that second one even makes use of them great Hoare channels! And gives us control on how long we hold on to data before sending it back (modified or not). But I digress. Let's go back to the important talking point that Hoare was right!