Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

211–220 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#211
post #30

I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust,…

In dynamic languages like JavaScript or Python it's necessary to continually run your code in order to validate that the API (of the standard library or of dependencies) was used correctly, that the types match, etc. Rerunning your code continually is no longer necessary in a language like Rust, because the compiler already does that for you. People complaining about slow compile times in static languages like Rust,…

Rust's type system doesn't have a notion of "looks right visually," so the compiler is ipso facto unhelpful there

Re: Rust Is Surprisingly Good as a Server Language

#212

Earlier quoted context omitted.

Swift / Vapor is amazing as well. They just released version 4, which streamlined and tidied up lots of things, can't recommend it enough. There's just something solid about Swift's strictness and compile time checks, that make it easy to be sure you're handling all possible code paths, and you can be reasonable confident it works and won't break all the time. Also very lean on dependencies, mostly unopinionated, and…

That con is a pretty big one. Macs have less than 10% desktop market share.

In this case Swift is being used on the server, so that could be an officially supported platform[0] which if I recall correctly is macOS, Ubuntu, CentOS, Amazon Linux 2, and Windows as of Swift 5.3.

Re: Rust Is Surprisingly Good as a Server Language

#213
post #156

Earlier quoted context omitted.

Ownership reasoning is not a productivity history in a web server, where the lifetime of pretty much everything is a single request which is handled and then disposed of. This is pretty much the simplest case for ownership. In a different application (say, one running a GUI with many objects which live for indeterminate amounts of time and can be shared across views), ownership reasoning can be extremely complicated.…

The thing with ownership reasoning in Rust is that you can opt out of it whenever it makes sense to do so. If you really have "objects which live for indeterminate amounts of time and can be shared across views", that's not an increase in complexity; you just acknowledge that reasoning about ownership and sharing at compile time is not going to be feasible, write Rc > (with a documentation comment to that effect) and…

Yes, but you still can't write garbage collected code, which is tremendously useful in many circumstances. E.g. when using closures you really don't want to be thinking about memory allocation, and closures have proven a very useful concept. There are countless of reasons why the availability of a GC is a productivity booster.

So I wouldn't describe Rust as a language that fits all domains and/or programmers well.

Re: Rust Is Surprisingly Good as a Server Language

#214

Earlier quoted context omitted.

Having to care for memory management is by definition very low level.

But I don’t? The borrow checker takes care of that? String vs &str is trivial to get ones head around, usually it’s really easy to decide whether you’d like to pass a reference or ownership, and worst comes to worst, sprinkling some copy/clone etc to get things sorted quickly still yields a binary that’s faster and more robust than something I can whip up in Python...

The borrow checker only checks, it does not solve the problem. In other languages the problem does not even exist to begin with.

It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up development by avoiding the problem altogether.

If you are going to end up sprinkling clones, heap allocating and reference counting, then you could have used C#, Java or JS to begin with which are plenty fast with their JIT/VMs and not think about memory at all.

Finally, comparing against Python is a very, very low bar for performance.

Re: Rust Is Surprisingly Good as a Server Language

#215
post #45

Earlier quoted context omitted.

>> in a normal day I'd probably average hundreds to a thousand compilation cycles! Maybe it's time to switch to an interpreter ? :-)

Or a language like Go, C or Nim that can compile tens of thousands of lines of code in a few seconds.

My day job is in C and compile time is 30 minutes. It really depends what you're working on.

Re: Rust Is Surprisingly Good as a Server Language

#216
post #125

Earlier quoted context omitted.

Rust is interesting in that it may eventually end up as a very useful language for WASM work. Rust has the advantage that when compiled to WASM it won't require a runtime library. So the prospect of Rust as a fast, low overhead, use anywhere language is tempting. Since Rust is a relatively new language it's worth checking to see how it's maturing over time against small low risk projects exactly as the author has don…

All that applies to several other very mature languages that can target WASM, like C. Nevertheless, WASM is not ideal for server work. It is intended for the frontend.

Sorry, I may not have explained my point clearly enough.

I'm not suggesting that you would use WASM for server work at all.

I'm suggesting that Rust would be interesting for WASM on the frontend because it doesn't depend on a runtime.

Given that you might want to use Rust for WASM you may also want to use it on the backend (that's without using WASM on the backend).

The assessment of Rust via small projects says nothing about the suitability or not of C or any other language.

It's just about the suitability of Rust right now and how it's changed from the last time you assessed it.

Re: Rust Is Surprisingly Good as a Server Language

#217
post #177

Earlier quoted context omitted.

> I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. Why compile again after adding a comment?

In fast-compiling languages, it's viable to have recompile-on-file-save or even continuous recompilation. Modern (and they aren't that modern anymore) IDE's will show red squiggles under code with compilation errors without requiring any action at all.

That's already provided by other tools than the compiler like rust analyzer.

Re: Rust Is Surprisingly Good as a Server Language

#218
post #61

Earlier quoted context omitted.

Is this not something you can just throw more hardware at?

Other languages are able to compile much faster than Rust on the same hardware. So while adding hardware helps (up to a point), Rust is definitely an outlier when it comes to compilation speed.

This really isn't true compared to C++. Also Rust is doing more than basically every other language, so it's provably slower.

Re: Rust Is Surprisingly Good as a Server Language

#219

Earlier quoted context omitted.

Maybe. At the rate I hit :w, probably not :)

How do you have Vim (or neovim) set up to do that and report errors inline?

I use VS Code with the vim plugin.

I hear you can get this working with vim/neovim but I haven’t done it myself.

Re: Rust Is Surprisingly Good as a Server Language

#220

Earlier quoted context omitted.

Maybe with some heuristics, you could hide some latency by beginning to compile before saving.

Maybe. At the rate I hit :w, probably not :)

One of the first computer system I used frequently was Windows ME. This system used to crash (BSOD) extremely frequently (depending on what you were doing, it could be as frequently as every 20 minutes), and any unsaved work would be lost.

I have therefore developed a reflex where I hit Cmd-S every time I finish typing. I actually have to put conscious effort in to stop this when using software where saving is slow.

Post reply on HN