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,…
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…
Rust Is Surprisingly Good as a Server Language
101–110 of 352 posts
Re: Rust Is Surprisingly Good as a Server Language
#102Earlier quoted context omitted.
> This honestly is a bad habit. I'd like to hear some justification for this rather than a blanket assertion. Just because our work styles differ doesn't mean that my style is necessarily wrong. > Rust is a language to which the programmer must adapt his way of working and thinking. I mean, Rust is actively attempting to improve compile times. It's not like devs made them intentionally long to cultivate good programm…
The most time wasteful part of programming is debugging. Writing slowly and thinking through your options and double checking what you wrote saves time. Especially since you are doing this while writing and you have the complete picture in your head. Obviously it does not catch everything. But one should strive to minimize detective work.
Re: Rust Is Surprisingly Good as a Server Language
#103Earlier quoted context omitted.
> The main thing that I use compiling for is to validate little off-by-one things. Like, is substring() exclusive on the second parameter? What about range syntax and the slice operator? What if I wrote + 1 instead of - 1 somewhere, or did I'm a really big fan of reading the docs (or, where the docs are insufficient, the source), and will always have docs.rs open alongside my editor. While the examples you provide ar…
Perhaps my examples were a little too trivial. 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. (OK, you could read preferences from a file, but then you'd have to optimistically write every value you'd ever want to recompile to a file. I've tried this, but it's far too much overhe…
But I work on network protocols and file formats and parsers and video transformers and user interfaces (often command line or web) and a long time ago games ;P... I make a small change and then I want to see the behavior difference. I almost always type code that compiles, but that doesn't mean it did what I want when interacting over the network: rust doesn't provide anywhere near powerful enough type abstractions to actually prove my code is correct... it only is proving that my code can't crash and will avoid undefined behavior.
What is so frustrating is that there is nothing about Rust that makes it impossible to make fast. With C++ I get to manually make tradeoff in my code on a file-by-file basis with an assumption that my project will be built out of thousands of mostly-independent fragments that I am able to compile incrementally or in parallel. I can very rapidly isolate individual functions I am working on for fast iteration without having to restructure my project, I can tell the compiler to instantiate templates in different ways to reduce dependencies, and I have designed a system to let me do parallel compiles on AWS Lambda (I haven't yet gotten my build environment to be ready for a -j1000 parallel build, but I am somewhat close).
I have been integrating some rust libraries into my codebase (I haven't even gotten to the point of really coding in it omg) and Rust is just so painful and frustrating to work with... and it really does just seem to be, as you pointed out, a matter of priorities and interest: there is this myth that it is some kind of tradeoff on the type system, but it isn't; it is just that the people who work on rust seem to not work on the same kind of projects that we do, at least in the same way, and so have made a bunch of trade offs like "I would rather never have to type a prototype than save any time compiling" and "I would rather my build system never have to consider dependency management than save any time compiling" and "I would rather provide the highest possible quality resulting binary than save any time compiling" (which is at least one I can appreciate, but only once a month when you cut a release... not the hundreds of times a day that I recompile my C++).
Re: Rust Is Surprisingly Good as a Server Language
#104Earlier 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.
Re: Rust Is Surprisingly Good as a Server Language
#105I'm building with Rust, Rocket, Diesel, and agree with much of the original article. I can also add more: in my direct personal experience, the lead people creating Rocket and Diesel are superb about responsiveness, ongoing communication, and enabling people (e.g. me) to help diagnose issues and fix the them. I'm continually thankful for the quality of participation among the people in the ecosystem. On the technical…
Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.
So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to the previous night that we know works.
Re: Rust Is Surprisingly Good as a Server Language
#106There 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…
Rust is much too low level for most glue/web services. Unless you have a specific high performance requirement (and Go doesn't meet this), there's no real strong case for migration here.
Re: Rust Is Surprisingly Good as a Server Language
#107Earlier 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.
Re: Rust Is Surprisingly Good as a Server Language
#108I 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,…
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…
Re: Rust Is Surprisingly Good as a Server Language
#109Earlier quoted context omitted.
The most time wasteful part of programming is debugging. Writing slowly and thinking through your options and double checking what you wrote saves time. Especially since you are doing this while writing and you have the complete picture in your head. Obviously it does not catch everything. But one should strive to minimize detective work.
After I've been programming for an entire day I will rely on the compile to tell me when I'm wrong with an assumption. I'm honestly trying to conserve mental energy so I've learned that it's better to do it from the start and avoid keeping track of as much stuff as possible in my head. The compile tells me something's wrong somewhere and I go fix it and move on. That's not detective work, at least it doesn't feel lik…
Re: Rust Is Surprisingly Good as a Server Language
#110In 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, 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.