6 ms·
> All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibili
by DarkNova6 1y ago
> All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include:
- Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
- Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
- Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
- Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
- Rust needs a mechanism to recover gracefully from OOM errors.
- Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.
- steveklabnik 1y ago1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. 2. This has been demonstrated. 3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated. 4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is Rust specific. I know the Ferrocene folks have done some of this work, but I don’t know the current state of things. 5. Rust as a language does no allocation. This OOM behavior is the standard library, of which you’re not using in these embedded cases anyway. There, you’re free to do whatever you’d like, as it’s all just library code. 6. This also hinges on a lot of definitions, so it could be argued either way.
- wrs 1y agoFor a little more color on 5, as a user of no_std Rust on embedded processors I use crates like heapless or trybox that provide Vec, String, etc. APIs like the std ones, but fallible. Of course, two libraries that choose different no_std collection types can't communicate...but hey, we're comparing to C here.
- dathinab 1y agoeven OOM isn't that different like there are some things you can well in C and this things you can do in rust too, through with a bit of pain and limitations to how you write rust and then there is the rest which looks "hard but doable" in C, but the more you learn about it the more it's a "uh wtf. nightmare" case where "let's kill+restart and have robustness even in presence of the process/error kernel dying" is nearly always the right answer.
- gerdesj 1y ago"1. Rust has had ten years since 1.0. ..." Rust insists on its own package manager "rustup" and frowns on distro maintainers. When Rust is happy to just be packaged by the distro and rustup has gone away, then it will have matured to at least adolescence.
- steveklabnik 1y agoRust has long worked with distro package maintainers, and as far as I know, Rust is packaged in every major Linux distribution. There are other worlds out there than Linux.
- gerdesj 1y agoSo why insist on rustup?
- steveklabnik 1y agoDistributions generally package the versions of compilers that are needed to build the programs in their package manager. However, many developers want more control than that. They may want to use different versions of the compiler on different projects, or a different version than what’s packaged. Basically, people use it because they prefer it.
- dathinab 1y agodifferent goals the rust version packaged in distros is for compiling rust code shipped as part of the distro. This means it - is normally not the newest version (which , to be clear, is not bad per see, but not necessary what you need) - might not have all optional components (e.g. no clippy) but if you idk. write a server deployed by you company - you likely want all components - you don't need to care what version the distro pinned - you have little reason not to use the latest rust compiler for other use cases you have other reasons, some need nightly rust, some want to test against beta releases, some want to be able to test against different rust versions etc. etc. rustup exist (today) for the same reason why a lot of dev projects use project specific copies of all kinds of tooling and libraries which do not match whatever their distro ships: The distro use-case and generic dev-use case have diverging requirements! (Other examples nvm(node), flutter, java etc.). Also some distros are notorious for shipping outdated software (debian "stable"). And not everything is Linux, rustup works on OSX.
- QuiEgo 1y ago> Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. I’d love to see rust be so stable that MSRV is an anachronism. I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable.
- aw1621107 1y ago> I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable. What other languages satisfy this criteria?
- hoppp 1y agoFortran, cobol, C or other old languages that stopped changing but are still used.
- aw1621107 1y agoAll three of the languages you list are still actively updated. Coincidentally, the latest standard for all three of them is from 2023(ish): - C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf - Cobol 2023: https://www.incits.org/news-events/news-coverage/available-now-2023-edition-of-isoiec-1989-cobol https://www.incits.org/news-events/news-coverage/available-n... (random press release since a PDF of the standard didn't immediately show up in a search) - Fortran 2023: https://wg5-fortran.org/N2201-N2250/N2212.pdf https://wg5-fortran.org/N2201-N2250/N2212.pdf C2Y has a fair number of already-accepted features as well and it's relatively early in the standard release cycle: https://thephd.dev/c2y-hitting-the-ground-running https://thephd.dev/c2y-hitting-the-ground-running
- pklausler 1y agoCan’t compile with just a PDF file, though.
- csande17 1y agoOne question towards maturity: has any working version of the Rust compiler ever existed? By which I mean one that successfully upholds the memory-safety guarantees Rust is supposed to make, and does not have any "soundness holes" (which IIRC were historically used as a blank check / excuse to break backwards compatibility). The current version of the Rust compiler definitely doesn't -- there's known issues like https://github.com/rust-lang/rust/issues/57893 https://github.com/rust-lang/rust/issues/57893 -- but maybe there's some historical version from before the features that caused those problems were introduced.
- steveklabnik 1y agoEvery compiler has soundness bugs. They’re just programs like any other. This isn’t exclusive to Rust.
- csande17 1y agoIn general, the way Rust blurs the line between "bugs in the compiler" and "problems with how the language is designed" seems pretty harmful and misleading. But it's also a core part of the marketing strategy, so...
- deleted 1y ago[deleted]
- steveklabnik 1y agoWhat makes you say this is a core part of the marketing strategy? I don’t think Rust’s marketing has ever focused on compiler bugs or their absence.
- csande17 1y agoYou are correct that Rust's marketing does not claim that there are no bugs in its compiler. In fact it does the opposite: it suggests that there are no problems with the language, by asserting that any observed issue in the language is actually a bug in the compiler. Like, in the C world, there's a difference between "the C specification has problems" and "GCC incorrectly implements the C specification". You can make statements about what "the C language" does or doesn't guarantee independently of any specific implementation. But "the Rust language" is not a specification. It's just a vague ideal of things the Rust team is hoping their compiler will be able to achieve. And so "the Rust language" gets marketed as e.g. having a type system that guarantees memory safety, when in fact no such type system has been designed -- the best we have is a compiler with a bunch of soundness holes. And even if there's some fundamental issue with how traits work that hasn't been resolved for six years, that can get brushed off as merely a compiler bug. This propagates down into things like Rust's claims about backwards compatibility. Rust is only backwards-compatible if your programs are written in the vague-ideal "Rust language". The Rust compiler, the thing that actually exists in the real world, has made a lot of backwards-incompatible changes. But these are by definition just bugfixes, because there is no such thing as a design issue in "the Rust language", and so "the Rust language" can maintain its unbroken record of backwards-compatibility.
- dathinab 1y ago> 2. ironically if we look at how things play out in practice rust is far more suited as general purpose languages then C, to a point where I would argue C is only a general purpose language on technicality not on practical IRL basis this is especially ridiculous when they argue C is the fasted general purpose language when that has proven to simply not hold up to larger IRL projects (i.e. not micro benchmarks) C has terrible UX for generic code re-use and memory management, this often means that in IRL projects people don't write the fasted code. Wrt. memory management it's not rare to see unnecessary clones, as not doing so it to easy to lead to bugs. Wrt. data structures you write the code which is maintainable, robust and fast enough and sometimes add the 10th maximal simple reimplementation (or C macro or similar) of some data structure instead of using reusing some data structures people spend years of fine tuning. When people switched a lot from C to C++ most general purpose projects got faster, not slower. And even for the C++ to Rust case it's not rare that companies end up with faster projects after the switch. Both C++ and Rust also allow more optimization in general. So C is only fastest in micro benchmarks after excluding stuff like fortran for not being general purpose while itself not really being used much anymore for general purpose projects...
- hoppp 1y agoRust has dependency hell and supply chain attacks like with npm.
- steveklabnik 1y agoYou control the dependencies you put in Cargo.toml.
- hoppp 1y agoWhat about the dependencies of your dependencies? I don't put too many things in Cargo.toml and it still pulls like a hundred things
- BrouteMinou 1y agoYour system is going to be owned, but at least, it's going to be "memory safely" owned! P. S. I you don't account all the unsafe sections scattered everywhere in all those dependencies.
- ghosty141 1y agoThen don't? In C you would just implement everything yourself, so go do that in Rust if you don't want dependencies. In C I've seen more half-baked json implementations than I can count on my fingers because using dependencies is too cumbersome in that ecosystem and people just write it themselves but most of the time with more bugs.
- rendaw 1y agoDirect and transitive dependencies are locked and hashed.
- steveklabnik 1y agoIf you care about not having any dependencies, then choosing dependencies that themselves don't have many dependencies should be going into the ones that you choose.
- mamcx 1y ago
- drnick1 1y agoI think Rust (and C++) are just too complicated and visually ugly, and ultimately that hurts the maintainability of the code. C is simple, universal, and arguably beautiful to look at.
- metaltyphoon 1y agoThese are all opinions.
- krior 1y agoC is so simple, that you will need to read a 700-page, comitee-written manual befor you can attempt to write it correctly.
- guest_reader 1y ago> C is so simple, that you will need to read a 700-page, comitee-written manual befor you can attempt to write it correctly. The official C99 standard document is typically about 210 pages.
- pjmlp 1y agoExcept the little detail that you need to complement that with all the manuals of the C compilers being used.
- krior 1y agohttps://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf Admittedly the 700 pages include the appendix and it is only a draft version, but still...
- simonask 1y agoC is simple. As a result, programming in C is not simple in any way.
- casparvitch 1y agoWhy can't `if condition { panic(err) }' be used in go as an assert equivalent?
- Jtsummers 1y agoBecause C's assert gets compiled out if you have NDEBUG defined in your program. How do you do conditional compilation in Go (at the level of conditionally including or not including a statement)?
- casparvitch 1y agoAh apologies I misunderstood, thanks
- echoangle 1y ago> How do you do conditional compilation in Go (at the level of conditionally including or not including a statement)? https://stackoverflow.com/questions/36703867/golang-preprocessor-like-c-style-compile-switch https://stackoverflow.com/questions/36703867/golang-preproce... Wouldn't this work? Surely the empty function would be removed completely during compilation?
- Jtsummers 1y agoThat builds or doesn't an entire file. Assert works as a statement. There is not an equivalent in Go to conditionally removing just a statement in a function based on a compile time option.