6 ms·

I’ve been really diving into Rust over this holiday break and reading through code bases like this is really helpful. Little things like a shared db connection

• mikece 5y ago
  I know this is off-topic but isn't Rust meant to be more of a systems-level language? It seems to me that Go would be a better choice for server-side API (assuming .NET 5 and 6 are too bloated and slow for your tastes). Or is Rust finding a niche in userpace apps even though it was designed for systems level use? I am not saying apps shouldn't be written in Rust, I just don't understand the appeal. What am I missing?
  • ATsch 5y ago
    It's definitely true that being good for writing services wasn't really a big design goal of rust and it's far from the lowest friction language to do it in. However it is still a mainstream high performance language with a rich type system and amazing compile time error checking and that makes it attractive to use for many other things if you are already used to it.
  • azth 5y ago
    .NET isn't slower than golang, and in fact, can be faster.
    • ViViDboarder 5y ago
      That’s probably true comparing nearly any languages.
  • 12ian34 5y ago
    I'm not very opinionated on Rust's comparison to other languages, but to me it does seem like rewriting things in rust (which now even has its own acronym RIIR) has become trendy. Trendy enough that the very fact that rust tools happen to be written in that language is used as a main selling point.
    • hiptobecubic 5y ago
      This is true for basically every budding community. "Rustaceans" writing tools for writing rust, in rust, seems like a gimmick, but every language goes through this period. JavaScript is probably the single biggest offender I can think of, but other examples include rewriting Vim plugins in Lua even though neovim supports vimscript, rewriting literally anything in Go, rewriting python libraries in Julia, etc.
      • adgjlsfhk1 5y ago
        I don't think the example of rewriting python in Julia is the same. Most python libraries get re-written (or implemented) in a faster language. If your choice is rewriting in C++/Fortran, or writing rewriting in Julia, The Julia version will be way nicer to use, and will probably be faster than calling the low level library from python.
        • hiptobecubic 5y ago
          You're talking about rewriting performance sensitive code when it makes sense to do so. I'm talking about rewriting random libraries because developers like to wallow in their tooling.
  • masklinn 5y ago
    > Or is Rust finding a niche in userpace apps even though it was designed for systems level use? I am not saying apps shouldn't be written in Rust, I just don't understand the appeal. What am I missing? A good type system is appealing regardless of the context. The ecosystem can also be nice (or known) e.g. serde is amazing when dealing with all sorts of serialisation schemes. The tighter resource control can also be useful for application space, and it was most certainly one of the goals for vaultwarden as complexity aside the heft of the official server was a large part of the motivation (e.g. the ability to run it on a Pi or a small VPS) An other longer-term option is that I can imagine e.g. coding something in rust then extracting its core or bits and bobs to libraries, and exposing that in C or Python or what have you. Nowhere near as attractive (or easy) with Go.
  • deleted 5y ago
    [deleted]
  • giancarlostoro 5y ago
    I remember a time when people called Go a systems language, is that time over now?
    • rectang 5y ago
      Go can't be used for many "systems programming" problem domains because it's garbage collected. That objection is always looming when people try to call Go a "systems programming language", so I think a lot of people now classify Go as an applications programming language instead.
    • masklinn 5y ago
      The only people who did that was the Go team itself, and they did so in contravention of the usual interpretation of the term, as by it they meant either the completely meaningless "you can built systems with it", or that you could build systems services or utilities (which is not what is usually meant by "systems language").
      • blub 5y ago
        I'm not aware of any official or standard definition of system programming. There's application programming and anything which doesn't fit in there is system programming which can be low-level, middleware, etc. Go is appropriate for writing services / daemons, command line tools, servers, etc. It's not well suited for writing operating system code and very performance-intensive code (databases, audio/video, etc), but there's still a big overlap with Rust. It seems to me that this whole discussion keeps coming up because parts of the Rust community are worried about the competition. And they have reason to be :-)
        • jatone 5y ago
          golang is absolutely capable of writing databases and audio/video code. the libraries just dont really exist for the audio/video stuff. but there are DBs written in go.
  • rectang 5y ago
    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 handling of returning a Result (especially combined with the question-mark operator). It forces me to deal with error conditions. 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-arent-recoverable-errors http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-are... ) And unlike Go or C, I don't have to remember to check the error every single time. I still have to write functionality tests for Rust code, but once I've done that I feel like the code is mostly locked down. It's harder to get to that sense of security in other languages.
    • mikece 5y ago
      > "Once I got used to writing in Rust..." How long did that take and what resources did you use to learn?
      • rectang 5y ago
        I started off with standard materials like "Rust By Example". I also tried to use Rust for simple stuff like command line utilities. Then I started working on a personal project, which motivated me to bull through lots of difficult problems. (This personal project happens to have been bindings for Apple Core Audio, but the point is to pick something you care about enough to motivate yourself.) Finally, I've found users.rust-lang.org invaluable. The first major challenge for me was the error handling ("WTF is `Box<dyn std::error::Error>`? What is `Box`? What is `dyn`?"). It got in the way as soon as I even tried to write command line utilities. Once you learn it, it's amazing, but out of the gate I continually stumbled and fell flat on my face. The second challenge was harder: coming from OOP languages, I was accustomed to structuring everything as large mutable heap-allocated classes with private fields, accessors, and an emphasis on opaque data structures and encapsulation. That is not idiomatic Rust, so I had to unlearn it and discover architectural alternatives. I don't know exactly how long it took before I felt comfortable, since I was learning in disconnected spurts rather than immersively all at once. It wasn't quick, though.
  • celliopia 5y ago
    Why are the Rust proponents so triggered by what seems to be an honest question about the popularity of Rust? I don't know the first thing about Elixir or Erlang but I realize there are some powerful properties of BEAM and if there seemed to be a trend to rewrite apps into BEAM apps I would want to know what am I missing out on that, if clued-in, I would join the rush as well. I think that's what OP is saying here (perhaps clumsily) but why vote the question down so aggressively? Makes you look like a thin-skinned lot who don't like to explain yourselves which would be a reason to avoid the "Rustacean" community.
    • uncomputation 5y ago
      To be fair, if there were a trend to write things in Erlang and someone posted “why use Erlang and not Rust? what am i missing?” I would also expect that to be down-voted. Nothing specific to Rustaceans here. I don’t agree with downvoting the comment because it is contributing to a conversation which is what HN is all about, but it was probably the assumption that Go is already the winner in the space of networked apps when Rust has many good technical qualities as well. Like you said, clumsily worded.
    • dagmx 5y ago
      Where are you seeing "triggered" comments? Every reply to that person has been very balanced and neutral, and the question seems to have a positive vote at this point.
  • uncomputation 5y ago
    I personally don’t see the appeal of Go. With Rust, I can write a concurrent, safe, and C-performant program with modern programming features like matches, generic programming, and a dedicated package manager (never understood go get). To boot, Rust has a strong ecosystem and the fastest web framework out there (Actix). It takes roughly the same amount of code to do networking stuff in Rust and Go, but with Rust it is more performant and I can sleep better knowing that if it compiled, it is at least safe and won’t have any concurrency bugs. A quick back of the paper example, I am doing Advent of Code this year and the same exact implementation took 40 ms in Rust and 350 ms in Go. Not to mention the Rust implementation, despite being the same semantically, was more concise and clear due to Rust’s extensive Iterator trait methods. A small difference you might say, but it’s just one less reason for me to switch.
    • mikece 5y ago
      Good to know! I've been looking at Go because it's "smaller, lighter, faster" than C# but from this description Rust might be a better next language to learn. Thank you!
      • masklinn 5y ago
        Do be warned that although interesting and rewarding and amazing in all sort of ways Rust is not easy. Where Go was designed such that it takes hours to pick up, Rust requires weeks, and possibly months before you build the intuition around the borrow checker. If you've been looking at go, it's really not much of an investment to try it out (I wouldn't heartily recommend it as I dislike the language but you do you).
      • jatone 5y ago
        learn both. golang is vastly more productive than rust for me. better tooling, faster build times, smaller less complex language. rust is fantastic for building highly performant safe code at the expense of developer productivity. builds times are atrocious and tooling isn't as polished as golang. both at great languages.
        • 5y ago
  • dagmx 5y ago
    Rust has found use in userspace apps. In fact I'd say most prominent use is stuff people interact with everyday. Firefox has portions written in Rust. 1passwd, Dropbox etc... If you use Visual Studio Code, it uses ripgrep which is built in rust. I use Rust for most of my servers now. It's replaced Python + flask in many cases, without too big a difference in my code.
  • blub 5y ago
    Programming languages like C and C++ have been used to write user space apps for decades. A language which can only be used for kernel space code is a niche within a niche within a niche. If Rust were only capable of that it would barely register on anyone's radar and be dead on arrival. In fact it's only recently that serious work was started on using Rust in a mainstream kernel (Linux); every project that Rust is known for is running in user space. People are confused about what system programming means and a lot of that confusion comes from parts of the Rust community which want to carve out a niche for Rust and keep claiming that Rust is particularly suited to system programming, as opposed to Go or D or other languages which are in reality also capable of tackling many system programming jobs, but have a garbage collector.
  • todd3834 5y ago
    I actually know Go very well. Wrote it for years. I like learning languages and using them in all kinds of different ways. I see a lot of overlap with Go and Rust. My interest in Rust is the small runtime and potential code reusability between server, client (mobile and web [wasm]). No GC means much smaller runtime in WASM I’m hoping.
• terhechte 5y ago
  I‘m on Mobile right now, but in that case you’d wrap your db in a Arc<RwLock<~>> (or Rc<> if you don’t need concurrency.). Then, anytime you need to access the DB, you’d try to lock the RwLock’s Writer or reader.
  • andrepd 5y ago
    But isn't this imposing a runtime cost on safety? Isn't rust all about safety and performance?
    • opportune 5y ago
      Under the hood most (all? Hesitate to say all but probably all) clients will have some form of mutex lock to at the very least control access to the file (eg socket) they use to pass messages to the server. If you find an example otherwise I’d like to hear it, though do keep in mind the mutex may not even be implemented in userspace. Which is to say, accessing a client may or may not be thread safe (depending on the client implementation) but assuming it’s not a multiplexing client, it almost certainly uses some kind of locking mechanism under the hood Even if it is a multiplexing client, if you saturate the internal clients you will either need to wait for a client to stop writing to its socket (through perhaps a lockless consumer model) or create a new internal client (slow).
    • jjice 5y ago
      Yes, but I can see it being worth while when you can spare the tiny amount of overhead, especially in a project that's meant to be self hosted like this.
    • vngzs 5y ago
      In Rust, abstractions tend to be zero-cost, but things that actually impact runtime are as fast as you write them. Concurrency problems don't magically disappear because your language can check for them. You still need to use memory-safe patterns, but the compiler will force your hand and prevent you from doing unsafe things accidentally. In the end, this makes it far easier to build correct, concurrent applications. If you decide to try some fancy new pattern that doesn't require locking, the compiler can guarantee the memory safety of your new implementation.