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

151–160 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#151

Post by emerongi »

jimbob45 wrote: post #17
Nican wrote: post #7

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pr…

What does he think will improve? Migration for the sake of migration is a waste of everyone’s time.

I'd say there is value in learning for the sake of learning.

Even if you later on decide that the Rust implementation is not production-ready, you can draw conclusions from the project, and the next time someone considers Rust for a bigger project, there is a member on the team who can provide insight into potential issues. Of course, the project would have to be sufficiently small to not waste too much time.

Re: Rust Is Surprisingly Good as a Server Language

#152

Post by zozbot234 »

spuz wrote: post #150
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,…

Could someone who is familiar with Rust clarify something for me? If I am using an IDE such as IDEA's Rust plugin, and I write some function which contains a type error, do I have to compile in order for the IDE to tell me there is a type error, or can I rely on automatic type-checking like I can in e.g. Java? In other words, is Rust slow to validate code, or is simply slow to compile code into a runnable binary? If…

> In other words, is Rust slow to validate code, or is simply slow to compile code into a runnable binary?

The latter. Validation/type checking is super quick. It might slow down a little bit if you do a lot of compile-time processing via macros, etc. IDE support is also improving a lot, and many Rust devs use an experimental component known as rust-analyzer to do the IDE-based validation you're talking about.

Re: Rust Is Surprisingly Good as a Server Language

#153

Post by tadzik_ »

spuz wrote: post #150
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,…

Could someone who is familiar with Rust clarify something for me? If I am using an IDE such as IDEA's Rust plugin, and I write some function which contains a type error, do I have to compile in order for the IDE to tell me there is a type error, or can I rely on automatic type-checking like I can in e.g. Java? In other words, is Rust slow to validate code, or is simply slow to compile code into a runnable binary? If…

Something like aforementioned rust-analyzer will catch errors like that within a second of you writing it, there's no need for recompilation.

Re: Rust Is Surprisingly Good as a Server Language

#154

Post by tjoff »

raziel2p wrote: post #123
bad_user wrote: post #81

Earlier quoted context omitted.

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

> In dynamic languages like JavaScript or Python it's necessary to continually run your code No it's not. It's just preferable to do your work in smaller batches so that your feedback loop is fast and you know exactly which change broke things, rather than making 10 changes and then having to figure out which of those changes 4 bugs relate to. And it's better to discover a flaw in your implementation early rather tha…

You get used to it and adapt. That might sound bad but comes with benefits as well. You will train yourself to think and be thorough to get it right the first time without it slowing you down.

Getting feedback quickly can be useful (especially when trying something new), but not needing it is liberating (especially when trying something new).

Re: Rust Is Surprisingly Good as a Server Language

#155

Post by dean177 »

bad_user wrote: post #81
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,…

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

You can have your cake and eat it too, Ocaml & Go both have type systems and compilers that are fast enough to work iteratively

Re: Rust Is Surprisingly Good as a Server Language

#156

Post by joppy »

sanxiyn wrote: post #94
pantulis wrote: post #69

In my opinion, the section which the author called "the ugly" makes it clear that it's not that surprisingly good as a application server language. A file upload is a basic feature that has already been solved yet Rust code contains a lot of boilerplate when compared with Python. Remember the mantra from the 2010's when the dynamic typing craze? Rust is not about optimizing developer time, it's about guaranteeing saf…

The point of the article is that lack of good support for file upload IS a productivity hit, but ownership reasoning IS NOT a productivity hit. And file upload can be solved by just more code. This indeed matches my experience.

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.

I’m not saying having to reason about ownership is bad, I’m just saying that this is not a good test for whether ownership reasoning is difficult or not.

Re: Rust Is Surprisingly Good as a Server Language

#157

Post by brabel »

zozbot234 wrote: post #133
brabel wrote: post #115

Earlier quoted context omitted.

With Jetbrains IDEs (IntelliJ, Webstorm, CLion) you can run a "sketch" that can "see" any module in your project. I use that a lot in Java/Groovy/Kotlin/Rust and it feels much superior to a REPL because I can write not just one-liners, but larger amounts of code, with all the features of the IDE like auto-completion, inline docs, syntax checking etc.

A test suite facility can also be used like this. And Rust adds any "examples" you write in the code (with proper doc formatting) to the test suite, as mentioned elsewhere.

A test suite has a different use case... REPLs/Sketches are useful for exploration... both of your own design and of libraries you're using. Tests can be used for this as well, but it's not as convenient when you're very "early" in your exploration or have no code yet to test at all.

Re: Rust Is Surprisingly Good as a Server Language

#158

Post by pjmlp »

hellofunk wrote: post #134
pjmlp wrote: post #104

Earlier quoted context omitted.

Or OCaml, Java, C#, F#, Eiffel, Delphi,...

Just googling “f# compile times” would beg to differ.

Apparently you didn't bother to read the 3 answers that come up.

Only one of them says anything and it an empty statement like

> F#'s compile times also seem to err on the long side but not very much so, my impression goes.

However it is quite easy to validate write the same algorithm in F# and Rust and then compare.

Ah but Rust is AOT compiled, easy, use NGEN, .NET Native, or Mono AOT for the F# compile time measurements.

Re: Rust Is Surprisingly Good as a Server Language

#159

Post by zozbot234 »

joppy wrote: post #156
sanxiyn wrote: post #94

Earlier quoted context omitted.

The point of the article is that lack of good support for file upload IS a productivity hit, but ownership reasoning IS NOT a productivity hit. And file upload can be solved by just more code. This indeed matches my experience.

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 move on. All it takes is knowing where to add a tiny bit of boilerplate.

Re: Rust Is Surprisingly Good as a Server Language

#160

Post by joppy »

sanxiyn wrote: post #96
rwmj wrote: post #78

Why wouldn't you want a garbage collected language for developing web services? Developer time is at a premium, lots of RAM, likely a single environment managing multiple requests so the GC gets a global overview, and because of network variability you're unlikely to be doing anything with realtime constraints.

The point of the article is that surprisingly, lack of GC does not hurt developer time.

A simple web server barely needs GC - allocate anything and everything needed during a single request from the same pool, and free the pool once the request is handled. The lack of GC can hurt developer time for other kinds of work, where the lifetime of data structures are not scoped to “within a request”.
Post reply on HN