[fjksksvdjsjd]

It’s good.

Net/http is still less mature, but this an absolutey massive golang ecosystem. You can certainly write http clients and servers today.

Unicode, string processing, regex—all of these have performant, stable implementations, either in std or in crates. Recently i’ve been doing audio processing in rust; the code there is at least as good as the equivalent in go. Overall I’d say I haven’t had issues finding a package for something in a couple years, though the quality varies from “has a full support community” to “DIY if you need something”.

However, rust really shines with datastructures. Heap? Btree? Doubly linked lists? It’s all high quality, performant, and type-safe code (though the internals are unsafe as hell), which was my major pain point in go. Doing anything with a typed datastructure feels a lot like copy/paste coding in go, though apparently templates formalize this.

[fb03]

Can you tell me about your audio coding endeavours in Rust? Are you into writing VSTs or stuff?

I've been reading more and more about Rust and while I've fallen in love with its premises I still fail to tackle the real world task of starting to do stuff with it. Would you give me some pointers?

I work with Python and C professionally and have more than 15 years coding backend stuff for un*x systems, to give you some bg.

thanks in advance!

[fjksksvdjsjd]

I haven’t played too much with VSTs beyond a proof of concept for logic tools. However I have been doing plenty of realtime processing! It’s great: it integrates seamlessly with the C ABI—I wrote my own core audio binding (though there is already on on crates) to get to know the API, and I was far more restricted by the poor documentation than the FFI itself.

But, rust has everything you need: find-grained control over memory and ownership, inline assembly and intrinsics (I haven’t attempted autovectorization yet), bindings to common audio formats, and excellent parallelization. The datastructures are extremely expressive, especially if you come from a C background; so far I really just want better VLA support, which is mostly annoying to work around (you have to manually poke the values into memory at the correct offset in an unsafe block).

I did find that tokio-rs wasn’t suitable as I had hoped for realtime work with an async/future api and fell back onto ringbufs locked with mutexes. The good news is you can wrap that in futures itself and have a great async api that does its work eith shared memory, minimizing the viable races.

Rust will definitely be a player in the audio workstation world; right now you’ll be implementing the bindings yourself, but you can go out and write plugins today so long as the ABI is C.

[steveklabnik]

If you're into audio, http://www.tzaeru.com/squeezing-rust-into-production-part-2/ was posted recently, and is about production Rust audio stuff.