5 ms·

There’s a comment like this on every post ending in “written in Rust.” The people who care about this include people who follow the development of the Rust ecos

There’s a comment like this on every post ending in “written in Rust.” The people who care about this include people who follow the development of the Rust ecosystem because it’s a sign of how capable the ecosystem is becoming.

PaulDavisThe1st 5y ago
Here's a list of the libraries we use in the Ardour project. Let me know how the, what is it, "crate" situation is for these or equivalent libraries: atk, atkmm, aubio, autoconf, automake, bison, boost, cairo , cairo , cairomm, cmake, cppunit, curl, expat, fftw, flac, flex, fontconfig, freetype, gdk-pixbuf, gettext, glib, glibmm, gnome-common, gnome-doc-utils, gobject-introspection, gtk-doc, gtk-engines, gtk+ X, gtk+ Quartz, gtk+, gtkmm, gtk-osx-docbook , harfbuzz, intltool, itstool, jpegsrcva, libarchive, libffi, libiconv, liblo, libogg, libpng, libsamplerate, libsigc++, libsndfile, libtool, libusb, libvorbis, libwebsockets, libxml, libxslt, lilv, LRDF, lv, libgnurx , NSS, NSS-PEM, pango, pangomm, pcre, pixman, portaudio svn rev, raptor, rasqal, rdflib, readline , readline , redland, rubberband, serd, sord, sratom, suil, taglib, tar, termcap, tiff, util-linux , uuid , vamp-plugin-sdk, xz, zlib
- ironmagma 5y ago
  I don't know, but it's hardly as interesting as whether someone can create a full cross-platform GUI using the ecosystem. Just a year ago the support for that was next-to-nonexistent.
  - PaulDavisThe1st 5y ago
    My point is that for large-scale software like a DAW, you either need a LOT more than a cross-platform GUI, or you will be reimplementing a very very large body of code that has existed in FLOSS form (but other languages) for (in some cases) decades.
    - ironmagma 5y ago
      Or just generating bindings for it. Bindgen exists for this reason. A minority of libraries such as that will require a smarter wrapper but for most it is probably sufficient to just use it in a reasonable way.
      - PaulDavisThe1st 5y ago
        ...sure. But then you start to lose one of the most talked-up benefits of Rust, "safety". Or am I missing something?
        glowcoil 5y ago
        You are missing something. For a piece of Rust software to run in any widely used computing environment, it is required to interface with a large body of non-Rust software via a non-typechecked ABI. Moreover, the Rust standard library itself contains many, many instances of the unsafe keyword. The benefits of Rust safety do not come from building a hermetically isolated tower of pure safe Rust code from the ground up, and those benefits do not become null and void the moment you include one C library used via FFI. Rust safety is about being able to take an unsafe component, encapsulate its implementation details, and encode sound usage patterns for that component in a public API which can then be statically checked by the compiler. This allows the difficult problem of determining whether an entire codebase is sound, memory-safe, and free of undefined behavior to be factored into many smaller, more tractable problems of verifying that individual components are sound given their APIs. You can even do this with wrappers and bindings to C libraries, and there are many examples of this in the Rust ecosystem.
        ironmagma 5y ago
        Wins are often incremental. It's much better to start with the potential of guaranteed safety, sidestepped by a manual (opt-in) sacrifice of it in favor of getting something working, and slowly chipping away at the unsafety over time; than to start with the dispensation of safety as an institution altogether (C/C++) and hope that someday you can work your way to safety. Put another way, as a developer, I'd much rather be part of a project using a language that is safe by default, which opts in to the unsafety it needs yet which hopes to someday simply remove all the `unsafe` keywords, than one that hopes to stumble its way to safety through relentless trial and error, testing, bug reports, debugging, etc. and has no actual measure of its level of safety. On top of that, if you only use, say 10% of one of those libraries, you can easily wrap the 10% of that library in a safe fashion instead of waiting for 100% of the library to have its own safe wrapper.
- BillyDM 5y ago
  That is a great question. While I'm not going through all the dependencies, I can give a brief overview. First off, a lot the crates we use are actually just bindings or abstractions over these essential parts such as os-specific windowing stuff. Winit and Glutin are the main examples. For OS audio stuff, there is cpal, but we found that the way it's designed is not the best for a DAW (no duplex support or MIDI). We may end up creating our own solution under the rusty-daw-io repo, although someone is also looking into creating bindings to RTAudio. We are using femtovg in place of cairo. The developer of our GUI library is also working on improving the text layout and shaping inside femtovg. We are using Symphonia for decoding audio files (although we may end up binding to ffmpeg if it doesn't work out). We aren't using any networking in mvp, but there is no shortage of networking crates in rust. We will also likely use bindings to libsamplerate if we find that a native Rust one is not good enough. I don't recognize a lot of those dependencies. If there is a crucial one I missed, please let me know! Of course some would point out why use Rust if you are using so many non-Rust dependencies? That is a fair argument. Me and my team just really prefer writing in Rust, so we are willing to put in the extra effort of using bindings.
  - PaulDavisThe1st 5y ago
    A large chunk of those libraries come the depstack of our GUI library (GTKmm). Pango, Harfbuzz etc. are all just dependencies for the GUI library, but also our own Canvas library (we had to write our own, since nothing out there came close to requirements; the Canvas is heavily Cairo-based but could fairly trivially be ported to any 2D drawing API). More DSP-y/audio-centric libraries would include: fftw - fastest fourier transform in the west rubberband - the only open source stretcher worth using (though we do have code to use soundtouch also) lilv,serd,sord,sratom,suil - LV2 infrastructure vamp-plugin-sdk - for offline (non-realtime) audio analysis aubio - used by VAMP liblo - almost certainly the best FLOSS OSC library We created our own audio/MIDI I/O abstraction initially based on JACK (which was initially based on Ardour :). The Windows version uses PortAudio which has its pros and cons; the macOS version directly uses CoreAudio; the Linux version directly uses ALSA (and then there is a separate cross-platform JACK one too).
    - 5y ago

PaulDavisThe1st 5y ago

Here's a list of the libraries we use in the Ardour project. Let me know how the, what is it, "crate" situation is for these or equivalent libraries: atk, atkmm, aubio, autoconf, automake, bison, boost, cairo , cairo , cairomm, cmake, cppunit, curl, expat, fftw, flac, flex, fontconfig, freetype, gdk-pixbuf, gettext, glib, glibmm, gnome-common, gnome-doc-utils, gobject-introspection, gtk-doc, gtk-engines, gtk+ X, gtk+ Quartz, gtk+, gtkmm, gtk-osx-docbook , harfbuzz, intltool, itstool, jpegsrcva, libarchive, libffi, libiconv, liblo, libogg, libpng, libsamplerate, libsigc++, libsndfile, libtool, libusb, libvorbis, libwebsockets, libxml, libxslt, lilv, LRDF, lv, libgnurx , NSS, NSS-PEM, pango, pangomm, pcre, pixman, portaudio svn rev, raptor, rasqal, rdflib, readline , readline , redland, rubberband, serd, sord, sratom, suil, taglib, tar, termcap, tiff, util-linux , uuid , vamp-plugin-sdk, xz, zlib

ironmagma 5y ago
I don't know, but it's hardly as interesting as whether someone can create a full cross-platform GUI using the ecosystem. Just a year ago the support for that was next-to-nonexistent.
- PaulDavisThe1st 5y ago
  My point is that for large-scale software like a DAW, you either need a LOT more than a cross-platform GUI, or you will be reimplementing a very very large body of code that has existed in FLOSS form (but other languages) for (in some cases) decades.
  - ironmagma 5y ago
    Or just generating bindings for it. Bindgen exists for this reason. A minority of libraries such as that will require a smarter wrapper but for most it is probably sufficient to just use it in a reasonable way.
    - PaulDavisThe1st 5y ago
      ...sure. But then you start to lose one of the most talked-up benefits of Rust, "safety". Or am I missing something?
      - glowcoil 5y ago
        You are missing something. For a piece of Rust software to run in any widely used computing environment, it is required to interface with a large body of non-Rust software via a non-typechecked ABI. Moreover, the Rust standard library itself contains many, many instances of the unsafe keyword. The benefits of Rust safety do not come from building a hermetically isolated tower of pure safe Rust code from the ground up, and those benefits do not become null and void the moment you include one C library used via FFI. Rust safety is about being able to take an unsafe component, encapsulate its implementation details, and encode sound usage patterns for that component in a public API which can then be statically checked by the compiler. This allows the difficult problem of determining whether an entire codebase is sound, memory-safe, and free of undefined behavior to be factored into many smaller, more tractable problems of verifying that individual components are sound given their APIs. You can even do this with wrappers and bindings to C libraries, and there are many examples of this in the Rust ecosystem.
      - ironmagma 5y ago
        Wins are often incremental. It's much better to start with the potential of guaranteed safety, sidestepped by a manual (opt-in) sacrifice of it in favor of getting something working, and slowly chipping away at the unsafety over time; than to start with the dispensation of safety as an institution altogether (C/C++) and hope that someday you can work your way to safety. Put another way, as a developer, I'd much rather be part of a project using a language that is safe by default, which opts in to the unsafety it needs yet which hopes to someday simply remove all the `unsafe` keywords, than one that hopes to stumble its way to safety through relentless trial and error, testing, bug reports, debugging, etc. and has no actual measure of its level of safety. On top of that, if you only use, say 10% of one of those libraries, you can easily wrap the 10% of that library in a safe fashion instead of waiting for 100% of the library to have its own safe wrapper.
BillyDM 5y ago
That is a great question. While I'm not going through all the dependencies, I can give a brief overview. First off, a lot the crates we use are actually just bindings or abstractions over these essential parts such as os-specific windowing stuff. Winit and Glutin are the main examples. For OS audio stuff, there is cpal, but we found that the way it's designed is not the best for a DAW (no duplex support or MIDI). We may end up creating our own solution under the rusty-daw-io repo, although someone is also looking into creating bindings to RTAudio. We are using femtovg in place of cairo. The developer of our GUI library is also working on improving the text layout and shaping inside femtovg. We are using Symphonia for decoding audio files (although we may end up binding to ffmpeg if it doesn't work out). We aren't using any networking in mvp, but there is no shortage of networking crates in rust. We will also likely use bindings to libsamplerate if we find that a native Rust one is not good enough. I don't recognize a lot of those dependencies. If there is a crucial one I missed, please let me know! Of course some would point out why use Rust if you are using so many non-Rust dependencies? That is a fair argument. Me and my team just really prefer writing in Rust, so we are willing to put in the extra effort of using bindings.
- PaulDavisThe1st 5y ago
  A large chunk of those libraries come the depstack of our GUI library (GTKmm). Pango, Harfbuzz etc. are all just dependencies for the GUI library, but also our own Canvas library (we had to write our own, since nothing out there came close to requirements; the Canvas is heavily Cairo-based but could fairly trivially be ported to any 2D drawing API). More DSP-y/audio-centric libraries would include: fftw - fastest fourier transform in the west rubberband - the only open source stretcher worth using (though we do have code to use soundtouch also) lilv,serd,sord,sratom,suil - LV2 infrastructure vamp-plugin-sdk - for offline (non-realtime) audio analysis aubio - used by VAMP liblo - almost certainly the best FLOSS OSC library We created our own audio/MIDI I/O abstraction initially based on JACK (which was initially based on Ardour :). The Windows version uses PortAudio which has its pros and cons; the macOS version directly uses CoreAudio; the Linux version directly uses ALSA (and then there is a separate cross-platform JACK one too).
  - 5y ago