Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

341–350 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#341

Earlier quoted context omitted.

Well, worthwhile in terms of compile times, which makes sense knowing google’s codebase. Most people aren’t compiling massive dependency trees that can’t fit on any single computer when they push a commit. Anyway in C++ land massive compile times are just as much of a problem. Fast code is expensive. Go’s a lot of things, but being good at generating fast code ain’t one of them (looking holistically anyway).

> Fast code is expensive. Indeed, because all bigtech can invest on is LLVM and C++. The research on compilers and optimizations has not been getting the attention because of LLVM monoculture and the monstrosity that is C++.

Well, rust is modularizing, so there will be opportunities for alternative backend (crane lift?).

Re: Rust Is Surprisingly Good as a Server Language

#342

Earlier quoted context omitted.

I am really looking forward to WASM as the technology of choice for language agnostic performant plugins. That is a backend niche.

Dynamic linking has been a thing for 50 years. No need for WASM for that.

Dynamic linking provides no process isolation or higher level constructs through the ffi boundary.

Re: Rust Is Surprisingly Good as a Server Language

#343
post #325

Earlier quoted context omitted.

> If you are going to end up sprinkling clones, heap allocating, and reference counting, then you could have used C#... The memory management system isn't Rust's only good feature. I and others enjoy Rust's type system and functional features, for example. Using Rust also makes it easy to get performance for when writing the parts for which you need it.

A typed language is a typed language, there are other languages that are easy to get performance out of. I’m not a rust dev and I’m highly skeptical it will be used outside of firefox and a few niche projects after this initial hype train dies off. What other features would make me pick rust over golang or one of the interpreted languages?

> a typed language is a typed language Well yeah, but not every type system is equal. For example I vastly prefer Rust's type system to C's because of Options instead of null and enums as sum types.

> what other features would make me pick rust over golang Generics, iterators, pattern matching, etc. There's lots of features Rust has that golang doesn't; that's not necessarily a good thing but for what I do it is. IMO the only good thing about golang's featurelessness is the compile times and the standard library.

As for interpreted languages, IMO it's just better to be able to catch errors at compile time.

Re: Rust Is Surprisingly Good as a Server Language

#344

Earlier quoted context omitted.

In theory and to some degree in practice. The compiler won't fix the code that compiles but runs incorrectly. Besides, there are statically typed functional languages where compiling time is not a problem, see D.

I haven't worked with D, but D isn't a functional programming language ;-)

Julia also has plenty of functional features, but is above all a practical, fast, and fast-compiling language.

The elegance is free.

Re: Rust Is Surprisingly Good as a Server Language

#345
post #343

Earlier quoted context omitted.

A typed language is a typed language, there are other languages that are easy to get performance out of. I’m not a rust dev and I’m highly skeptical it will be used outside of firefox and a few niche projects after this initial hype train dies off. What other features would make me pick rust over golang or one of the interpreted languages?

> a typed language is a typed language Well yeah, but not every type system is equal. For example I vastly prefer Rust's type system to C's because of Options instead of null and enums as sum types. > what other features would make me pick rust over golang Generics, iterators, pattern matching, etc. There's lots of features Rust has that golang doesn't; that's not necessarily a good thing but for what I do it is. IMO…

> Well yeah, but not every type system is equal. For example I vastly prefer Rust's type system to C's because of Options instead of null and enums as sum types.

Fair enough. But I'm not advocating using C here either.

> As for interpreted languages, IMO it's just better to be able to catch errors at compile time.

There are type checked and interpreted languages.

Re: Rust Is Surprisingly Good as a Server Language

#346

Earlier quoted context omitted.

Dynamic linking has been a thing for 50 years. No need for WASM for that.

Dynamic linking provides no process isolation or higher level constructs through the ffi boundary.

Binary interfaces with process isolation have existed for at least 30 years, too.

Re: Rust Is Surprisingly Good as a Server Language

#347
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,…

Disclaimer: I’m only a casual Rust user. > One group loves fast compile times and quickly validating hypotheses In Rust, it’s sufficient to type check (if it type/borrow checks, it will probably work) and Rust can type check in real time via rust-analyzer. This is much faster feedback than running your program or even its tests. Of course, Rust’s type/borrow checker is also choosier than many others, and you still sp…

On the other hand, I've seen a few Java applications that leaked memory (and one case of leaking file descriptors) because developers had mostly gotten away with not thinking about resource ownership. Removing data races isn't the only advantage of refusing to generate binaries when the programmer appears to need to think a bit more about ownership.

Re: Rust Is Surprisingly Good as a Server Language

#348

what about server debugging ? python as an interpreted language have a real advantage here. you can easily patch on production for example to debug or hot fix. you would need to rebuild and upload binary in the case of rust.

I really don't understand the down votes :) yes I've been working on python applications and live patching code for emergency, our app was deployed and running on 64 different machines. I'm not talking about coding in production or whatever, of course once the workaround is done on production a proper solution is implemented and deployed.

why restarting ? when you can reload the new code of the app while it's running ? no service interruption worked for us for years ! but yeah, I agree, better having 4 eyes while patching on prod :)

Re: Rust Is Surprisingly Good as a Server Language

#349

Earlier quoted context omitted.

Just because you have a garbage collector doesn't mean you don't have to worry about memory management. I've see too many problems pop up because people don't understand how memory is managed in their GC'd language.

This isn’t true, in all languages with one you can ignore the garbage collector and still get work done. It may not be the most efficient but you still get work done. Let’s get a fresh out of code bootcamp grad in here and throw two languages in front of them if you want to test this.

You may be able to get work done, but I've seen actual bugs because people didn't understand how memory was managed. For example, not realizing that passing an object to a function was passing a reference, and not a copy. These are things that are explicit in Rust.

Re: Rust Is Surprisingly Good as a Server Language

#350

Earlier quoted context omitted.

This isn’t true, in all languages with one you can ignore the garbage collector and still get work done. It may not be the most efficient but you still get work done. Let’s get a fresh out of code bootcamp grad in here and throw two languages in front of them if you want to test this.

You may be able to get work done, but I've seen actual bugs because people didn't understand how memory was managed. For example, not realizing that passing an object to a function was passing a reference, and not a copy. These are things that are explicit in Rust.

This won't result in any security related bug, you'd be updating the referenced version instead of a copied version. Both testing and use of the written code will show this "bug" if it's in fact a bug for this specific codebase. So now the question is, does rusts difficult learning curve warrant removing this "maybe" bug? There are other things to consider as well, memory fragmentation, performance etc. Have you measured the performance of code that both copies and updates?
Post reply on HN