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

161–170 of 386 posts

Re: Rust – A hard decision pays off

#161

Post by bluejekyll »

gk1 wrote: post #24
bluejekyll wrote: post #18

Earlier quoted context omitted.

> But as someone who likes Rust and wants to like it more: don’t lead with that. The original title appears to be “Inside the Pinecone”, but seeing as they submitted it themselves I’m guessing they wanted the uptick on the Rust. The article itself doesn’t discuss their transition to Rust until the end. So I wouldn’t say they led with it originally, but perhaps didn’t get traction on the original title.

> seeing as they submitted it themselves I'm grateful to muizelaar but I don't know who that is, so we can't take credit for this one.

Oh, sorry. I misattributed that. I saw the domain origin and confused that for the submitter. In that case, the submission actually is against the rules of HN, as I understand them (use the original title rule).

Re: Rust – A hard decision pays off

#163

Post by drran »

throwaway894345 wrote: post #120
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 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…

Now, compare a parallel version of both.

Re: Rust – A hard decision pays off

#164

Post by pdimitar »

qsort wrote: post #116
throwaway894345 wrote: post #101

Earlier quoted context omitted.

> As I understand it, the article talks about switching from python to rust in a non-trivial database service that is required to be fast and robust. I can't imagine python to do well in this regard, especially when C/C++ extensions are required to enhance the performance. The article specifically talked about following the conventional Python advice to use C/C++ for the fast parts and Python for the "glue". This is…

> I think it's incredibly reckless to start a new commercial project in Python in almost all cases... > I don't usually make blanket statements, but Python really is so bad that this is a blanket statement I'm pretty comfortable with. Speaking as someone who agrees with you that something static is very likely better than python for a large project, how do you square this with the existence of a lot of Python project…

Just fine, you say? I had dozens of colleagues being in medium to large Python projects and every single one of them was terrified of every small change in the projects because inevitably something fails in an unexpected way.

These guys and girls are heroes. They are like the plumbers and electricians working at 3:00 AM so your water and electricity never stop while you're awake.

"Just fine" is likely only your external observation. I'd give them medals and help them retire at 35 for all the horrors they have endured. It's "just fine" because they tirelessly made sure of it.

Things were just fine despite Python. Not because of Python.

Plus, none of us has statistics that prove a theory beyond any doubt. Forget about that; this scarcely (if ever) existed in the programming world and likely will not exist anytime soon. We should apply our experience and the intuition that grows out of it.

Finally: a pile of anecdotal evidence can be treated as an objective evidence with, say, 50-60% probability. Insisting that the real world must comply with academically pure practices is not going to get us anywhere (and is misguided).

Re: Rust – A hard decision pays off

#165

Post by Xeoncross »

xmonkee wrote: post #96
golergka wrote: post #47

Earlier quoted context omitted.

> I've heard generally good things about TypeScript, but I'd be concerned about its performance even if it is better than Python I wouldn't recommend Typescript for CPU-bound tasks, but for I/O-bound tasks with complicated business logic it's type system is on the order of magnitude better than Go, and makes you able to get really close to the "make invalid states of the system a type error" ideal of functional langu…

I am launching my startup on Typescript (backend and frontend). So far, it's been an amazing experience - I can define the problem in terms of types even before I start writing any executable code, and refactoring is a breeze if you make your types hard enough. There are mature libraries, you can share code between the two sides, infinite options for PaaS providers who can "just deploy" a typescript codebase. As a so…

> I can define the problem in terms of types even before I start writing any executable code

This is how code is supposed to be written. Sort out the logic first, don't write the actual implementation details until later (models, http handlers, file parsers).

The support for this type of SOLID design is much more common in Go than in Typescript projects which often seem to inherit bad practices from Javascript developers.

Re: Rust – A hard decision pays off

#166

Post by skrtskrt »

pdimitar wrote: post #157
skrtskrt wrote: post #99

Earlier quoted context omitted.

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.

Most recently I've run into Hyper not having tracing support

Re: Rust – A hard decision pays off

#167

Post by thinkharderdev »

throwaway894345 wrote: post #120
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 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…

Yep, agree wholeheartedly with this. I came to Rust from Scala where writing an explicit for loop is looked at as one step above using goto :) and it took me a while to just give in and write the imperative version.

Re: Rust – A hard decision pays off

#168

Post by brightball »

johnisgood wrote: post #112
brightball wrote: post #74

Earlier quoted context omitted.

That’s why Elixir developers like to make NIF callouts with Rust. It’s dangerous to do anything outside of the BEAM but Rust negates all of those concerns.

Is it possible to use Ada instead of Rust?

I believe you can made a NIF with just about anything.

Re: Rust – A hard decision pays off

#169

Post by jon_richards »

wooque wrote: post #94
nu11ptr wrote: post #55

This doesn't surprise me and matches my own experience. Rust literally makes a codebase nearly void of most bug classes with the exception of logic bugs (Unfortunately, in a huge codebase, there can still be tons and tons of logic bugs). Still, when I migrated my Python codebase to Rust I got rid of whole classes of bugs and honestly code faster in Rust on a "per debugged line of code" basis. In Python, every line MU…

>with the exception of logic bugs this is one big exception, because logical bugs are most common and most problematic.

I strongly disagree. The vast majority of bugs I see are unhandled None or exceptions and typos in dictionary keys and class attributes.

Re: Rust – A hard decision pays off

#170

Post by nomel »

throwaway894345 wrote: post #154
mamcx wrote: post #142

Earlier quoted context omitted.

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.

I disagree. If I can avoid an index variable, I’m going to have less bugs since I won’t have to index.
Post reply on HN