I don't have any experience with running the bitwarden server, but the primary selling point for this is that it is less resource intensive than the official server backend. The official backend is written in C#, and is currently using .NET 5. I haven't ever felt like .NET apps were particularly bloated, but I guess it's possible to write bloated code in any language. Does anybody have any insights as to what is done…
Apart from the pain around dealing with .NET itself, Bitwarden's official server only supports MSSQL which is a nightmare in pretty much every conceivable way (licensing, tooling, packaging, and so on). Vaultwarden seems to support plain old Postgres and SQLite.
Bitwarden compatible server written in Rust
91–100 of 116 posts
Re: Bitwarden compatible server written in Rust
#92Earlier quoted context omitted.
> Unlike C# or Python or Java or C++, I don't have to worry that any code could throw an exception at any time. (Rust code can panic, but panics generally represent unrecoverable errors — see http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-are ... ) I just don't understand this logic. Exceptions are the same (C++ exceptions use the very same unwinding mechanism than panics in Rust as far as I can see), why w…
For application code, you can change the behavior of Rust panics. Although I haven't verified this myself, I fully expect that you can achieve saving a document and exiting gracefully. The distinction is that panicking should (almost) never be used for recoverable errors. You can, but that's not idiomatic and would only be appropriate within the confines of your own application. Recoverable errors in Rust should be h…
I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. The only thing that matters is the language spec - everything that fits in there is kosher. Idioms just create pointless fights and tabs vs spaces situations where there doesn't need to be any.
> Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does.
no, you just choose to ignore it. I can also write C++ code with throw and no try..catch and that will give the same result (as I pretty much use exceptions like one would use panic! in rust). I don't know anyone who would say that this is a good idea. My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues, and sometimes, when it turns out that an issue has a way to be recovered (or that maybe it doesn't matter), then someone gets a try..catch block.
Like most articles about exceptions, that Joe Duffy post talks about the problem of "where the control flow goes". I've written my first lines of C++ something like 17-18 years ago now and not once it has actually been an issue. Consultants sure do love selling it as one though.
Re: Bitwarden compatible server written in Rust
#93Earlier quoted context omitted.
You choose golang because you basically want java with less memory usage and static single binary deploys for your backend server applications. Go was designed to be a language that development scales very well with it's focus on simplicity and very fast compile speed. Rust on the other hand, was designed to make certain hard things less hard, at the cost of complexity, ease of learning, speed of development (high am…
Java is way more expressive and better designed than golang. So no, golang is not Java with less memory. It's also possible to deploy Java as a single JAR file.
I agree the single file argument is not extremely convincing. Especially because engineers are often on Mac on Windows machine and compiling for Linux. While Go does support this, as soon as you have to use a c library dependency (in my experience this was sqlite), then we had to start compiling in the environment we wanted. Easy to solve with docker but deployment wasn't the reason I like Go.
I should spend some time thinking about why but overall I just "feel" more productive with Go vs Java (including Kotlin). Go's standard library, docs (with links to the source code), everything just feels super readable and understandable.
I don't see much debate agains Go using less memory. I can confirm this was my experience as well. My experience is that it uses a lot less CPU as well.
Re: Bitwarden compatible server written in Rust
#94Earlier quoted context omitted.
I do still run the bitwarden official server. While I would not considered bloated by 2021 standards, it still eats up more that 2GB of RAM for my single-user setup... It prompted me to upgrade the VPS I run it to a more expensive version with more RAM. So yeah, resource usage is real, especially if you plan to run this on a Pi or on small cloud intances.
>it still eats up more that 2GB of RAM for my single-user setup Call me old fashioned, but that seems like an insanely large amount of resources to host one person's passwords.
Re: Bitwarden compatible server written in Rust
#95Earlier quoted context omitted.
For application code, you can change the behavior of Rust panics. Although I haven't verified this myself, I fully expect that you can achieve saving a document and exiting gracefully. The distinction is that panicking should (almost) never be used for recoverable errors. You can, but that's not idiomatic and would only be appropriate within the confines of your own application. Recoverable errors in Rust should be h…
> You can, but that's not idiomatic I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. The only thing that matters is the language spec - everything that fits in there is kosher. Idioms just create pointless fights and tabs vs spaces situations where there doesn't need to be any. > Not having to deal with "invisible control flow" in Rust is one…
My response is that adherence to common idioms is simultaneously beneficial and harmful. It is beneficial because shared assumptions and shared understanding facilitate cooperation, yet it is harmful because it impedes innovation. Whether it is more beneficial or more harmful on balance depends on the situation and on individual taste.
I'd like to think that our perspectives are compatible.
> > Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does.
> no, you just choose to ignore it.
I guess you could characterize things that way. For example, in the Rust library code I write, I choose to ignore certain unrecoverable errors — e.g. out-of-memory panics from allocating ordinary sized objects, even though such panics can theoretically occur.
But the distinction here is that I also expect e.g. invalid argument values or "file not found" errors to be handled via Rust's Result type. I don't choose to ignore such events — I expect all recoverable errors to be handled via visible control flow, where you can identify every location in the code that such an error might occur. This makes it easier to reason about control flow for all circumstances save unrecoverable errors.
> My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues
Yes, that's an Anders-Hejlsberg-endorsed way of doing things. "The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler." https://www.artima.com/articles/the-trouble-with-checked-exc...
I think the preference for one way of doing things can depend on what problem domain you work in. That approach is highly suitable for applications programming.
(Duffy has done a lot of work on operating systems; my biggest projects have been libraries.)
> Consultants sure do love selling it as one though.
EDIT: I'm not very happy about that take, and I originally wrote up a lengthy response — but it turns out I had incorrectly recalled that this was not the first such interaction we've had. (I was recalling an obnoxious post from a different European with the first initial "j"). I've deleted my response because it's OT and not worth dealing with if it's not something recurring.
Re: Bitwarden compatible server written in Rust
#96I don't have any experience with running the bitwarden server, but the primary selling point for this is that it is less resource intensive than the official server backend. The official backend is written in C#, and is currently using .NET 5. I haven't ever felt like .NET apps were particularly bloated, but I guess it's possible to write bloated code in any language. Does anybody have any insights as to what is done…
Apart from the pain around dealing with .NET itself, Bitwarden's official server only supports MSSQL which is a nightmare in pretty much every conceivable way (licensing, tooling, packaging, and so on). Vaultwarden seems to support plain old Postgres and SQLite.
Licensing, sure. It's more convenient with Free software for small self-hosted instances... But the rest? You can even get a Linux build in a docker container supplied by MS...
Re: Bitwarden compatible server written in Rust
#97As cool as a native code back-end for Bitwarden would be I would be more interested in seeing vendor native mobile apps (Swift/Xcode, Kotlin/Android Studio) and putting the Xamarin code out to pasture. Would also like to see an improvement in the desktop Electron app as well or at least get it to feature parity with the web vault. All of that said Bitwarden is a fantastic product and I recommend that over every other…
The bitwarden mobile apps are using Xamarin? That's actually pretty impressive...I've never had any of the weird issues with the bitwarden app that I've had with other Xamarin apps in the past. The desktop app looks and feels like an electron app, so I'm far less impressed by it. At the very least it would be nice to have it in Qt or something like that.
Re: Bitwarden compatible server written in Rust
#98Earlier quoted context omitted.
The bitwarden mobile apps are using Xamarin? That's actually pretty impressive...I've never had any of the weird issues with the bitwarden app that I've had with other Xamarin apps in the past. The desktop app looks and feels like an electron app, so I'm far less impressed by it. At the very least it would be nice to have it in Qt or something like that.
Bitwarden Mobile: https://github.com/bitwarden/mobile I will freely admit I am strongly biased against Xamarin as there are so few cases where I think it's unequivocally the right choice, and Bitwarden isn't one of them. It would make more sense to take the work done in their desktop electron app and use that as part of an Ionic hybrid mobile app than to screw around with the layercake of bugs and mismatched APIs tha…
> Moreover, since this is a serious app from a security point of view it really should go full vendor native IMO.
hmm
Re: Bitwarden compatible server written in Rust
#99Earlier quoted context omitted.
Once I got used to writing in Rust, I found it really hard to mess up. I sort of like it for applications, although some idioms can be a bit verbose and hard to parse visually and mentally. First, thanks to default immutability of variables and the borrow checker, I trust that I'm far less likely to accidentally mutate something and cause an action-at-a-distance bug. Second, I absolutely love idiomatic Rust error han…
> And unlike Go or C, I don't have to remember to check the error every single time. How do you mean? I’ve been writing Rust frequently lately and you still have to check the case. Do you mean that the compiler will nag you if you stunt so you don’t have to remember to do it because you’ll be reminded? That’s one of the things common Go linters do that I wish was built into the compiler. It’s silly that an unused dep…
It's easy and idiomatic to write code which calls `unwrap`, so that's what everybody does when they don't want or need to write sophisticated error handling code. But that's not the same as forgetting to check a return value — when something goes wrong, `unwrap` panics.
I mean, if you're determined you can definitely drop an error in Rust, e.g. with a `match` arm that does nothing. But the easy path is to `unwrap`.
Re: Bitwarden compatible server written in Rust
#100Earlier quoted context omitted.
You choose golang because you basically want java with less memory usage and static single binary deploys for your backend server applications. Go was designed to be a language that development scales very well with it's focus on simplicity and very fast compile speed. Rust on the other hand, was designed to make certain hard things less hard, at the cost of complexity, ease of learning, speed of development (high am…
Java is way more expressive and better designed than golang. So no, golang is not Java with less memory. It's also possible to deploy Java as a single JAR file.