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

Rust – A hard decision pays off

pinecone.io

Post reply on HN
Print view View original

151–160 of 386 posts

Re: Rust – A hard decision pays off

#151

Post by AtNightWeCode »

rob74 wrote: post #134
AtNightWeCode wrote: post #83

Earlier quoted context omitted.

Docker is built with Go. Compare doing things with Docker api between Go and Python. I usually recommend people to "script" things with Go but I start to think that Go has to go... https://docs.docker.com/engine/api/sdk/examples/

I would say in this case it's more the API designers' fault than Go's fault. Looks like the Python API is operating at a higher abstraction level than the Go API - using the Python API you can just call a "macro" that does everything required, in Go you have to call each operation individually.

No post body was provided.

Re: Rust – A hard decision pays off

#152

Post by agumonkey »

throwaway894345 wrote: post #41

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

Started a small project with rust and serde(toml config). Having static checking of config an its parsing felt really good.

Re: Rust – A hard decision pays off

#153

Post by jasim »

brabel wrote: post #122
mhaberl wrote: post #10

> ..complex runtime issues which were almost impossible to reproduce or isolate > That’s when internal murmurs about a complete rewrite started brewing… > We decided to move our entire codebase to Rust > there was still one minor problem - no one on the team knew Rust "We have runtime issues so we will fix them by a complete rewrite in a language that no one on the team knows." I would not call that a "hard decision"…

Yeah, I am really surprised they managed to make it work, actually. Rust is one of those languages it takes time to master... if you write a lot of code in it while you're learning, you're likely to make all sorts of mistakes that later will need to be cleaned up... at least, looking at Rust code I wrote when I was early in the learning process, I can't even imagine any of that code going to production... so I would…

As a relative newcomer to Rust, I'm curious to hear about those early mistakes

Re: Rust – A hard decision pays off

#154

Post by throwaway894345 »

mamcx wrote: post #142
throwaway894345 wrote: post #120

Earlier quoted context omitted.

I actually don't care as much for iterators as I thought I would. Beyond some simpler map().reduce() stuff they tend to fall over pretty fast, and I end up spending too much time trying to make iterator chains work before defaulting to for loops. I also dislike how anemic Rust's stdlib is. I'm sure there are good reasons, but I like that I can just reach for Go's stdlib for annotating errors or dealing with JSON. Oth…

The thing is in Rust this is totally ok. Is NOT un-idiomatic to mix imperative + functional paradigms in the same block.

Agreed, but I think people make too big a deal about iterators. The simple for loops that they’re fit to replace aren’t that hard to read or write, so they aren’t causing real problems, and on the more complex end you’re writing imperative stuff anyway. Iterators certainly aren’t a bad thing, but they’re not the game changer that Go-critics made them out to be in all of the Rust-vs-Go debates.

Re: Rust – A hard decision pays off

#155

Post by tialaramex »

throwaway894345 wrote: post #138
SoftTalker wrote: post #123

Earlier quoted context omitted.

I guess that's subjective, not knowing rust I see a few more lines in the first example but beyond that it does not jump out at me as being "way more complex."

Hah, it took me and a bunch of other people in the Rust discord a fair amount of time to figure out how to get the first example to compile correctly in the first place, and I find the “transpose()” business to be particularly convoluted. I think even Rust people would prefer the imperative version. I also suspect there’s some hindsight benefit at play in that it’s easier to make sense of the first snippet than it wa…

Yes, the imperative version looks like the sane choice to me. Rust's iterator documentation does suggest that this is not a language which favours iterator chains everywhere.

However one reason to prefer an iterator chain in some cases is that the chain might imply an optimisation you'd otherwise have to write manually and might not think of.

For example if I have N things, and I map them, perhaps more than once, but I'm definitely getting N of whatever the output of the last map was, the iterator chain might very well see that I don't actually have any way to change N and so when I collect() that into a Vec the Vec it gives me is constructed with capacity N, saving the (amortized but non-zero) cost of growing it during insertions.

Imperatively I can remember to write Vec::with_capacity(N), and that's safe of course but it's an extra step to remember.

The imperative approach does particularly shine on the opposite edge of this, if I know that I'm getting no more than 100 items out of this pipeline, despite putting N in, Rust almost certainly won't see that and won't make Vec::with_capacity(100) for a collect() call whereas my imperative code can just explicitly write Vec::with_capacity(100) or whatever.

Re: Rust – A hard decision pays off

#156

Post by ywei3410 »

throwaway894345 wrote: post #138
SoftTalker wrote: post #123

Earlier quoted context omitted.

I guess that's subjective, not knowing rust I see a few more lines in the first example but beyond that it does not jump out at me as being "way more complex."

Hah, it took me and a bunch of other people in the Rust discord a fair amount of time to figure out how to get the first example to compile correctly in the first place, and I find the “transpose()” business to be particularly convoluted. I think even Rust people would prefer the imperative version. I also suspect there’s some hindsight benefit at play in that it’s easier to make sense of the first snippet than it wa…

Honestly the closure + `transpose` is really ugly as sin. I had to do a double take and reason through the steps which you took to get that particular snippet (while not reading the imperative one).

Re: Rust – A hard decision pays off

#157

Post by pdimitar »

skrtskrt wrote: post #99
lijogdfljk wrote: post #77

Earlier quoted context omitted.

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or correctness-is-paramount software. I'd add one more addition to use Rust (speaking from an ex-Go dev): Use Rust if you want a robust std lib. Go is good, i used it for ~5 years, but man Rust was a breath of fresh air with the amount of tooling that helped me…

I think this comes with the caveat that there are a lot more mature libraries for Go just as a function of the age of the language.

That might have been true 2-3 years ago but nowadays whatever I can think of, Rust already has a library for it.

Re: Rust – A hard decision pays off

#158

Post by lowbloodsugar »

throwaway894345 wrote: post #41

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

I would recommend Rust even if writing a simple tool, the kind of thing I might previously have used python for. We had some data munging to do and someone started it in python. On the real dataset it ran for an hour then ran out of memory. I took a crack in rust, as a n00b rust programmer, and the rust version runs successfully in less than a minute. I haven’t tried server side yet, because the learning curve for that is more of a learning cliff, but for small things I am already faster in rust than with my decade of python.

Re: Rust – A hard decision pays off

#159

Post by jhgg »

Writing Rust at scale, I concur with some of these findings. Nowadays, my team exclusively writes Rust. Our rationale is two-fold.

1) We want to write software that is fast and inexpensive to run. Our rust services are quickly growing, but cumulatively, they remain in the sub-1000 core count, while processing many millions of requests per second across our service with excellent latency.

2) We want to write software that won't break and page us in the middle of the night, or blow up when we deploy it. We operate some of the core persistence primitives at our company, so the consequence for error in the worst case could be corruption or loss of user data. Our experience thusfar with Rust is that we're able to confidently iterate and deploy our services. The developer velocity is indeed higher, and continues to grow with your experience in the language.

Our team of 10 (with 3 engineers having started in the last 2 weeks) owns all of the database clusters, and all of the services surrounding them. Our on-call is surprisingly quiet, with maybe 0-3 low sev incidents a week, with most of them being due to the underlying database/hardware, and not the rust services. We are actually writing a Rust control plane for our databases soon, which seeks to automate most of the response and remediation of most of the incidents we experience in a given week, and also to automate a bunch of manual work that we currently do around operations of the databases.

The learning curve can be a bit rough, but our team of engineers is motivated to learn, and we have a great culture of mentorship and teaching from the engineers who are familiar with Rust.

Re: Rust – A hard decision pays off

#160

Post by lowbloodsugar »

the__alchemist wrote: post #56
throwaway894345 wrote: post #41

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

I think Python shines as an interactive calculator, eg an iPython REPL. Calculations, plotting etc. Or for website backends since Django is very nice. Or scripting OS tasks like file manipulation etc. For full projects outside websites, Rust for almost every case.

I like Octave (gnu matlab) for that.
Post reply on HN