Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

Post reply on HN
Print view View original

291–300 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#291

Post by estebank »

fooyc wrote: post #170

It's sad that we still have to make async I/O explicit in the code to obtain some efficient concurrency in 2020. Async/await is a huge improvement over callback hell, but this doesn't fix everything. The "function color" problem still exists [1], and seems to be more than binary in rust. This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that…

> This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library".

Having to write async versions of the sync APIs doesn't need to be the case: https://docs.rs/smol/0.1.18/smol/ lets you use blocking APIs in async contexts without blocking (by dispatching them to different threads). What the ecosystem is seeing is a few different projects trying things out in different ways to explore the design space. This is not necessarily a bad thing.

> Rust is ground breaking in some areas, but also completely lacks innovation in others.

Other than the borrow checker Rust is a very boring language for language designers. That is intentional :)

> But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ?

async/await lets the compiler perform some extra inferences on how you're using your data, which makes writing an `async fn foo();` much easier than `fn foo() -> impl Future;` if you are dealing with borrowed data. Of course, the same underlying threading primitives are still available to use.

Re: Rust Is Surprisingly Good as a Server Language

#292

Post by entha_saava »

deleuze wrote: post #250
entha_saava wrote: post #236

Earlier quoted context omitted.

I'd say Go is a fair comparison here. Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow. Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.

The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop

I told type system is not the bottleneck, codegen is.

Even if you count the size of ode after monomorphization, I am pretty sure the Go compiler compiles it much faster. Because the compiler is not in the benchmarks rat race of adding one optimization pass from every academic paper in the world for diminishing returns. That would be unnecessary for a development compiler.

Go compiler could have an optimized slow build option, in ideal world, but that's a different matter altogether.

Re: Rust Is Surprisingly Good as a Server Language

#293

Post by entha_saava »

monadic2 wrote: post #249
entha_saava wrote: post #236

Earlier quoted context omitted.

I'd say Go is a fair comparison here. Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow. Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.

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++.

Re: Rust Is Surprisingly Good as a Server Language

#294

Post by amelius »

zozbot234 wrote: post #246
amelius wrote: post #213

Earlier quoted context omitted.

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.

> when using closures you really don't want to be thinking about memory allocation You don't have to think about this with Rust - and you don't need a GC either. The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case.

> The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case.

No, the borrow checker will merely give you an error when your closure may outlive the captured variables. This is often not useful, and is an impediment to being productive. As a programmer you don't want to be solving the same boring problem of memory management over and over again, unless perhaps when you're doing really low-level stuff and there is no other option.

Re: Rust Is Surprisingly Good as a Server Language

#295

Post by deleuze »

65a wrote: post #287
deleuze wrote: post #250

Earlier quoted context omitted.

The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop

If you're casting to interface{} non-stop, you are doing something against the grain of the language. It works, but there's probably a better way of getting the result you are looking for.

Right, building generic, reusable code is against the grain of the language.

Re: Rust Is Surprisingly Good as a Server Language

#296

Post by pengaru »

kungtotte wrote: post #231
mlindner wrote: post #218

Earlier quoted context omitted.

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

I don't have a good idea about the compilation speeds of C++, so I don't doubt you on that point. That's hardly the only other AOT language competing with Rust though, and while some of them are simpler on a language level (i.e. C) the compilers do a fair share of work in the optimizing stage of those simpler languages. There's also several languages that do quite a bit of heavy lifting during compilation, like Zig a…

If you want to use rust, and can achieve fast enough performance by simply buying some newfangled threadripper machine with a boat load of ram, what difference does it make?

The OP sounded like they wanted to use rust except for this one issue of compilation being too slow for their development style.

How fast is fast enough and is that achievable just by throwing some money at the machine?

Perfect is the enemy of good enough as they say.

Re: Rust Is Surprisingly Good as a Server Language

#297

Post by smt88 »

nicoburns wrote: post #224
smt88 wrote: post #87

Earlier quoted context omitted.

> I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling. I know exactly what you mean. Front-end development can be this way, too. I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now.

> I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now. I think that's true, but only because of the slow compile times. Which is why they're so frustrating. Rust would otherwise be an excellent language for these use-cases.

I see where you're coming from. The good news is that compile times are something we are certain will get better. Rust's maintainers know it's a high priority, but even if they didn't, we would still benefit from increasingly powerful machines used for graphics/gaming development.

Re: Rust Is Surprisingly Good as a Server Language

#298

Post by stjohnswarts »

ragnese wrote: post #233
johnfn wrote: 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,…

I don't have that much to add to the discussion, really. I just wanted to ruminate on something: > I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. It's amazing how little I understand your point of view. And I'm being genuine and not critical of you at all. To me, all of the features of the languag…

The time to compile these small web apps is not worth worrying about after the initial compile. I'm not sure what he's getting at to be honest. While it's certainly not instant, it's not that bad.

Re: Rust Is Surprisingly Good as a Server Language

#299

Post by johnfn »

steveklabnik wrote: post #194
johnfn wrote: 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,…

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I am interested in how you got that impression, because at least in our official surveys, it's often one of the most-requested improvements to Rust, and it's something that we're constantly working on improving. Still a ton of work to do though! For what it's worth, my workflow is closer…

Here's the exact thing that I checked when making this conclusion a few weeks back, the most up-to-date state of the compiler roadmap that I could find: https://rust-lang.github.io/compiler-team/minutes/design-mee... I see 16 top-level goals on here for next year (under the Goals section). The only thing that seems related to compile speed is to continue working at incremental compilation (no new initiatives?). And even there, the only action item for the entire year is to create a working group.

I love rust-analyzer! But I'm not sure what you mean by "it compiles the code every save." I love how fast it can type-check my code, but I was unaware it could actually compile my code into something I can run? I thought it was just a LSP provider.

Re: Rust Is Surprisingly Good as a Server Language

#300

Post by johnfn »

ragnese wrote: post #233
johnfn wrote: 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,…

I don't have that much to add to the discussion, really. I just wanted to ruminate on something: > I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. It's amazing how little I understand your point of view. And I'm being genuine and not critical of you at all. To me, all of the features of the languag…

Believe me, I love the same things you love about rust. Move semantics, sum types, error handling are all amazing, to say nothing of the ridiculous perf!

I think our difference is I spend a lot of time on graphics and games, where there's a lot of manual tweaking that you have to do. (Is 20px far enough? 25px? Is 1 second long enough for the explosion? Maybe 0.5s instead?) There's just no way to test it outside of rerunning the app.

Post reply on HN