5 ms·

How is Rust in regards to the SQLite's requirements now?

by juice_bus 5y ago

tptacek 5y ago
Pretty much the same. Arch support in particular would be a clear dealbreaker, I think.
- tyingq 5y ago
  For some more detail, sqlite has makefiles for things like Windows CE and VxWorks, and the generic configure process builds on almost anything else sufficiently POSIXY, like QNX.
  - estebank 5y ago
    When I see projects like this, with such impressive range of supported platforms, I am always a bit weary at how well tested those platforms effectively are. I know that some bugs have been caught in OpenBSD due to some of the more esoteric platforms making evident some incorrect assumptions, but I also remember Debian boasting a huge amount of packages for, let's say, ARM that would build, but any attempt to use would show they had never been tried out and were wholly unsupported.
    - tyingq 5y ago
      True, though sqlite is pretty universally lauded for their approach to testing. Perhaps not all platforms are tested by the Sqlite team, but if you run their tests on your platform, the coverage is pretty good.
  - steveklabnik 5y ago
    rustc has seven supported vxworks targets, incidentally.
- geofft 5y ago
  Won't rustc_codegen_gcc effectively solve arch support? It's not done and shipped, but it exists and is usable and is landing into rustc, which is a fair amount of progress. (Or is SQLite portable to architectures that GCC does not support?)
  - tptacek 5y ago
    Yes, I imagine it will.
  - marcosdumay 5y ago
    > architectures that GCC does not support Do those exist? (Yeah, there are some microcontrllers that can only be programmed by the manufacturer's C compiler, that doesn't even support the entire language and is full of bugs. But I would be very surprised if SQLite run on a PIC.)
    - masklinn 5y ago
      > Do those exist? IIRC a possible issue is the use of forks of gcc (or something else), I think it used to be common for console toolchains though maybe less so these days.
masklinn 5y ago
> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Didn't make any sense at any point post 1.0. Rust 1.0 code still works today modulo BC breaks required to fix unsoundnesses. > Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages. Also didn't make much sense at any point as the story there was always straightforward. But efforts like librsvg have pretty much demonstrated that (interestingly the libsrvg conversion effort started around the time that page was created, circa 2017). > Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system. Rust is used in a bunch of embedded contexts. Whether Rust can produce object code that works on your embedded device is a more debatable question, depends on the existence (and quality) of the proper llvm backend. I think there's also a gcc frontend in the works, but I expect it's essentially nowhere yet as it was only just started (few months old I think?). Though I believe it has financial support and a fair amount of manpower. I believe there's also an even more recent effort for a gcc backend in rustc. So yeah this one I'd say there's limited progress yet but things seem to be moving in the right direction and picking up. > Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries. Unclear what the issue is there so no idea. > Rust needs a mechanism to recover gracefully from OOM errors. That was always possible by working no_std, though of course required reimplementing your own abstractions. With the linux kernel integration effort, a lot more work is going into "fallible allocation" APIs, and thus the ability to gracefully recover from allocation failures. > Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty. ¯\_(ツ)_/¯
- tptacek 5y ago
  The branch coverage thing is a weird, artificial-seeming requirement that all the branches in the compiled code --- not the code as written, but the code ultimately produced by the compiler --- be testable. In other words: if the compiler generates a bounds check anywhere, it should be possible to test what happens when that specific bounds check fails. The problem is that sane Rust code doesn't give you all the tools you'd need to deliberately trip all the checks the compiler generates, because that is part of the point of being a safe language.
opheliate 5y ago
With the discussion of getting Rust into the Linux kernel, I think there's more interest in graceful recovery from OOM errors. The new Allocator API will (maybe?) help this.
- masklinn 5y ago
  > The new Allocator API will (maybe?) help this. The Allocator API is about the ability to mix allocators and provide "precise" (per-object) allocation strategies. That's orthogonal to fallible allocation, which is mostly about adding fallible versions of possibly-allocating APIs, and being able to statically remove access to the non-failing one (and being able to implicitly reject any dependency relying on those APIs) (and / or providing alternate implementations which expose a fallible API which is what fallible_collections does, but the stdlib seems to have gone with adding fallible APIs and probably adding a compiler feature / flag to be able to disable the non-failig ones)
petters 5y ago
There is a C backend for LLVM. If/when that works, that should solve most of the portability issues.
- masklinn 5y ago
  It's been dead for years, though the julia folks are apparently trying to resurrect it.

How is Rust in regards to the SQLite's requirements now?

tptacek 5y ago

Pretty much the same. Arch support in particular would be a clear dealbreaker, I think.

tyingq 5y ago
For some more detail, sqlite has makefiles for things like Windows CE and VxWorks, and the generic configure process builds on almost anything else sufficiently POSIXY, like QNX.
- estebank 5y ago
  When I see projects like this, with such impressive range of supported platforms, I am always a bit weary at how well tested those platforms effectively are. I know that some bugs have been caught in OpenBSD due to some of the more esoteric platforms making evident some incorrect assumptions, but I also remember Debian boasting a huge amount of packages for, let's say, ARM that would build, but any attempt to use would show they had never been tried out and were wholly unsupported.
  - tyingq 5y ago
    True, though sqlite is pretty universally lauded for their approach to testing. Perhaps not all platforms are tested by the Sqlite team, but if you run their tests on your platform, the coverage is pretty good.
- steveklabnik 5y ago
  rustc has seven supported vxworks targets, incidentally.
geofft 5y ago
Won't rustc_codegen_gcc effectively solve arch support? It's not done and shipped, but it exists and is usable and is landing into rustc, which is a fair amount of progress. (Or is SQLite portable to architectures that GCC does not support?)
- tptacek 5y ago
  Yes, I imagine it will.
- marcosdumay 5y ago
  > architectures that GCC does not support Do those exist? (Yeah, there are some microcontrllers that can only be programmed by the manufacturer's C compiler, that doesn't even support the entire language and is full of bugs. But I would be very surprised if SQLite run on a PIC.)
  - masklinn 5y ago
    > Do those exist? IIRC a possible issue is the use of forks of gcc (or something else), I think it used to be common for console toolchains though maybe less so these days.

masklinn 5y ago

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Didn't make any sense at any point post 1.0. Rust 1.0 code still works today modulo BC breaks required to fix unsoundnesses. > Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages. Also didn't make much sense at any point as the story there was always straightforward. But efforts like librsvg have pretty much demonstrated that (interestingly the libsrvg conversion effort started around the time that page was created, circa 2017). > Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system. Rust is used in a bunch of embedded contexts. Whether Rust can produce object code that works on your embedded device is a more debatable question, depends on the existence (and quality) of the proper llvm backend. I think there's also a gcc frontend in the works, but I expect it's essentially nowhere yet as it was only just started (few months old I think?). Though I believe it has financial support and a fair amount of manpower. I believe there's also an even more recent effort for a gcc backend in rustc. So yeah this one I'd say there's limited progress yet but things seem to be moving in the right direction and picking up. > Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries. Unclear what the issue is there so no idea. > Rust needs a mechanism to recover gracefully from OOM errors. That was always possible by working no_std, though of course required reimplementing your own abstractions. With the linux kernel integration effort, a lot more work is going into "fallible allocation" APIs, and thus the ability to gracefully recover from allocation failures. > Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty. ¯\_(ツ)_/¯

tptacek 5y ago
The branch coverage thing is a weird, artificial-seeming requirement that all the branches in the compiled code --- not the code as written, but the code ultimately produced by the compiler --- be testable. In other words: if the compiler generates a bounds check anywhere, it should be possible to test what happens when that specific bounds check fails. The problem is that sane Rust code doesn't give you all the tools you'd need to deliberately trip all the checks the compiler generates, because that is part of the point of being a safe language.

opheliate 5y ago

With the discussion of getting Rust into the Linux kernel, I think there's more interest in graceful recovery from OOM errors. The new Allocator API will (maybe?) help this.

masklinn 5y ago
> The new Allocator API will (maybe?) help this. The Allocator API is about the ability to mix allocators and provide "precise" (per-object) allocation strategies. That's orthogonal to fallible allocation, which is mostly about adding fallible versions of possibly-allocating APIs, and being able to statically remove access to the non-failing one (and being able to implicitly reject any dependency relying on those APIs) (and / or providing alternate implementations which expose a fallible API which is what fallible_collections does, but the stdlib seems to have gone with adding fallible APIs and probably adding a compiler feature / flag to be able to disable the non-failig ones)

petters 5y ago

There is a C backend for LLVM. If/when that works, that should solve most of the portability issues.

masklinn 5y ago
It's been dead for years, though the julia folks are apparently trying to resurrect it.