Live data from Hacker News

Rust Is Surprisingly Good as a Server Language

stu2b50.dev

131–140 of 352 posts

Re: Rust Is Surprisingly Good as a Server Language

#131
post #101

Earlier quoted context omitted.

As a datapoint for your hypothesis, when working in a typed language I will build my code only a few times a day. I much prefer working from a logical and thoughtful approach rather than iteration. At the point where I start a build I am already reasonably confident that it will do what I want it to. There are some bugs where I will need to re-build several times consecutively but these are relatively rare for me (I…

That's spot on. I mostly work with C#, F# in a day to day job and I build my code only a few times. This is also true when I work with Java, Angular and TypeScript. When I pick a new feature to implement I design that on paper with pencil and then mostly translate that to code. Mostly I can code for hours without compiling since this is where Typed Languages have strength.

That's very interesting. I can never work that way. I compile constantly (C++)

Re: Rust Is Surprisingly Good as a Server Language

#132
post #94

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.

Yes, that was my point, not the article.

Honest question: how many hours would you say it took you to grok the ownership/borrowing stuff and then reason about it in a natural way so you were as productive as with the language you were coming from?

Re: Rust Is Surprisingly Good as a Server Language

#133
post #115
post #48

Earlier quoted context omitted.

You mean a REPL, or an interpreted language? I'd love a REPL that could somehow load the state of my entire app so I could test stuff out, but I've never found a language that could do that and also had reasonable type safety guarantees.

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.

Re: Rust Is Surprisingly Good as a Server Language

#134
post #104

Earlier quoted context omitted.

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

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

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

Re: Rust Is Surprisingly Good as a Server Language

#135
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.

> And file upload can be solved by just more code. Yes, but it's a papercut. How many other papercuts are there, compared to more developed ecosystems for this domain? That's not an easy question to address.

Or take the ORM as an example. Doesn't even begin to compare with 2012's ActiveRecord from Rails land. Not to be surprised, as Rails used a lot of dynamic magic that is simply not doable in Rust.

Granted, it's more than enough for a lot of use cases but it wouldn't seem to me like the most appropriate approach for, say, and e-commerce platform in terms of maintainability and time to market. Of course, the performance speedup would be huge on the other hand.

Re: Rust Is Surprisingly Good as a Server Language

#136
post #48

Earlier quoted context omitted.

You mean a REPL, or an interpreted language? I'd love a REPL that could somehow load the state of my entire app so I could test stuff out, but I've never found a language that could do that and also had reasonable type safety guarantees.

Some of the best solutions to that world right now seem to be things like lisps with dynamic typing added. You get a great set of repl support, but you can also build components and systems into easy wrapper scripts to load them as needed.

I assume you mean static typing enabled. Because lisps are already dynamically typed to begin with.

Re: Rust Is Surprisingly Good as a Server Language

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

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.

Re: Rust Is Surprisingly Good as a Server Language

#138

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 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 ;-)

Re: Rust Is Surprisingly Good as a Server Language

#139
post #71
post #63

Earlier quoted context omitted.

Well, I like an instantaneous edit-compile loop too, bit I was never bothered by rust compile times. Once you get your cache warm, it's pretty much instant. If not, run `cargo check` instead of `cargo run`. You can also use rust-analyser for an in-editor <1s feedback loop.

Copying this from someone else I replied to: No, it's an issue for warm caches as well. 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. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to.

If you were using `cargo run` or `cargo build` instead of `cargo check`, these 10 seconds could be spent in linking the final binary and not running the compiler frontend. for that matter 10 secs is not unheard of for large libraries with a lot of debug symbols.

That's why you should use `cargo check` instead : it will only run the rust compiler frontend, but not the LLVM linker.

Re: Rust Is Surprisingly Good as a Server Language

#140
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.

Yes, that was my point, not the article. Honest question: how many hours would you say it took you to grok the ownership/borrowing stuff and then reason about it in a natural way so you were as productive as with the language you were coming from?

I didn't measure in terms of hours, but it certainly didn't take more than a month for me. Also for others I taught.
Post reply on HN