I'll take Richard Hipp's C code over just about anyone's Rust code any day of the week. The man is a national treasure!
It says it is alpha about 5 times in the readme. What gave you the impression that this was already more robust than SQLite?
An embedded database written in Rust
41–50 of 74 posts
Re: An embedded database written in Rust
#42Earlier quoted context omitted.
Indeed. This is why I aggressively checksum everything and pay particular attention to throwing away all data that was written after any detected corruption during recovery. This is easier with the log-only architecture. It's also totally os and filesystem agnostic. I was happily surprised yesterday when it passed tests on fuchsia :]
So you might end up throwing away everything. (I know, it's not your fault)
Users can rely on sequential recovery. At some point I'll probably write a partial recovery tool that gives you all versions of all keys that are at all present anywhere in the readable file though, which won't be much work. Typical best practices encourage moving away from single disk reliance for particularly valuable data, but this library will also work on phones etc... So it is important to support people when a wide variety of things go wrong.
Re: An embedded database written in Rust
#43Earlier quoted context omitted.
In Rust abstractions are free.
If that was so, there wouldn't have been a need for the unsafe mode.
Unsafe does not exist for performance.
Quoting from the rust book:
> Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler is trying to determine if code upholds the guarantees or not, it’s better for it to reject some programs that are valid than accept some programs that are invalid. That inevitably means there are some times when your code might be okay, but Rust thinks it’s not! In these cases, you can use unsafe code to tell the compiler, “trust me, I know what I’m doing.” The downside is that you’re on your own; if you get unsafe code wrong, problems due to memory unsafety, like null pointer dereferencing, can occur.
> There’s another reason Rust has an unsafe alter ego: the underlying hardware of computers is inherently not safe. If Rust didn’t let you do unsafe operations, there would be some tasks that you simply could not do. Rust needs to allow you to do low-level systems programming like directly interacting with your operating system, or even writing your own operating system! That’s one of the goals of the language. Let’s see what you can do with unsafe Rust, and how to do it.
Re: An embedded database written in Rust
#44Does rust compile reliably to embedded targets yet? Last time I checked there were a lot of problems with armv5.
I'm not sure about ARMv5, but v7 and v8-A are Tier 1 for Firefox, so we get a pretty decent smoke test out of them. The thing about embedded is that it's quite diverse, so speaking about it in broad terms is tough. It goes from "lol nope" to "barely works" to "pretty decent" to "great", depending on which thing you're talking about.
We have a whole working group this year working on embedded.
Re: An embedded database written in Rust
#45Re: An embedded database written in Rust
#46Earlier quoted context omitted.
If that was so, there wouldn't have been a need for the unsafe mode.
Unsafe does not exist for performance. Quoting from the rust book: > Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler is trying to determine if code upholds the guarantees or not, it’s better for it to reject some programs that are valid than accept some programs that are invalid. That inevitably means there are some times when your code might be okay, but Rust thinks it’s not…
As the person who wrote those paragraphs, yes. The fundamental reason unsafe exists is not for performance reasons. That being said, the parent is also true that sometimes, unsafe is used to enhance performance. But that's not the usual case, and in fact, can even hurt performance in ways. For example, &mut T can't alias, but *mut T can, and so &mut T can be optimized more aggressively. (We recently turned these optimizations back on: https://github.com/rust-lang/rust/pull/50744 )
Re: An embedded database written in Rust
#47Earlier quoted context omitted.
In Rust abstractions are free.
If that was so, there wouldn't have been a need for the unsafe mode.
Re: An embedded database written in Rust
#48Earlier quoted context omitted.
In Rust abstractions are free.
Do you realize "zero-cost" abstractions are not specific to Rust?
Your parent didn't say that. Speaking about Rust in a thread about a Rust project seems to be very on-topic?
(I would also disagree with that statement, but in a different way: Rust enables zero-cost abstractions, but nothing inherently means they have to be. I can also make quite costly ones, and they'll compile.)
Re: An embedded database written in Rust
#49Earlier quoted context omitted.
Do you realize "zero-cost" abstractions are not specific to Rust?
Your parent didn't say that. Speaking about Rust in a thread about a Rust project seems to be very on-topic? (I would also disagree with that statement, but in a different way: Rust enables zero-cost abstractions, but nothing inherently means they have to be. I can also make quite costly ones, and they'll compile.)
I would answer "you can write trash in any language, in Rust you need to find ways how to do it, when in other languages - how to avoid it".
Looks like ycombinator now is the place when people just looking for negativity and what else ti disagree with.
Re: An embedded database written in Rust
#50Earlier quoted context omitted.
Do you realize "zero-cost" abstractions are not specific to Rust?
Your parent didn't say that. Speaking about Rust in a thread about a Rust project seems to be very on-topic? (I would also disagree with that statement, but in a different way: Rust enables zero-cost abstractions, but nothing inherently means they have to be. I can also make quite costly ones, and they'll compile.)
> Your parent didn't say that.
Yes and it's more disturbing. It says "In Rust abstractions are free" when an algorithm was discussed.
Rust having "free" abstractions does not change the performance characteristics of an algorithm: this is what the grand-parent was talking about.