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

171–180 of 386 posts

Re: Rust – A hard decision pays off

#171

Post by sgeisenh »

tialaramex wrote: post #155
throwaway894345 wrote: post #138

Earlier quoted context omitted.

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…

Depending on how you write it, iterators are much better at this since most iterator methods produce iterators with size hints.

If you use "take" for example, collect should do the right thing: https://doc.rust-lang.org/src/core/iter/adapters/take.rs.htm...

Re: Rust – A hard decision pays off

#172

Post by pdimitar »

nprateem wrote: post #115
Jack_rando_fang wrote: post #61

Earlier quoted context omitted.

Agreed. I still give Python credit for allowing us to write software in an extremely efficient way. But after I wrote the initial version of the software with Python, I always procrastinate on testing, fixing existing issues, and as the software grows larger I simply want to give up as the different issues keep piling up. In comparison, Rust code usually just works out of the box due to the error handling and type sy…

Don't you find thinking about the borrow checker unnecessary overhead while prototyping?

Of course. That's rarely debatable (unless making sure that you have a very small memory footprint is one of the project's critically important goals).

The point is that you pay more upfront but can then iterate much more confidently and quickly.

Re: Rust – A hard decision pays off

#173

Post by lvass »

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.

The first version isn't what I'd write in a purely functional language either, a recursive version would be much saner. Isn't recursion idiomatic in rust?

Re: Rust – A hard decision pays off

#174

Post by salamanderman »

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've seen the transition from a Javascript codebase to a Typescript codebase with all strict checks in place to have a similar step change in dev velocity. The speed of debugging stupid mistakes, confidence in larger changes, and removal of a need for a lot of unit tests that were poor-person's type checking, is really significant. And runtime errors are a lot less weird than they were.

Re: Rust – A hard decision pays off

#175

Post by steveklabnik »

lvass wrote: post #173
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.

The first version isn't what I'd write in a purely functional language either, a recursive version would be much saner. Isn't recursion idiomatic in rust?

Rust doesn't guarantee TCO and so recursion is a bit dicer than in many functional languages.

Re: Rust – A hard decision pays off

#176

Post by AmpsterMan »

throwaway894345 wrote: post #118
xmonkee wrote: post #96

Earlier quoted context omitted.

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 just fucking really hate Go. As a Go fanboy, this made me chuckle. :) > I can't explain it, but I find the language infuriating. It somehow manages to be less expressive, more verbose and more straight up boring than all the other options. I sort of get it. I think people fixate too much on the for loops and the `if err != nil` boilerplate, but there's definitely some validity with respect to "how to properly ann…

I am still fairly early in my career. I've worked mostly in Java, but my current job is a mix of Python for E2E testing, PHP and JS for application work. Go is my preferred language for tools.

My favorite language is by far Java with Go a close second. I dislike the others. The only thing I wish Go had is more functional support, but only in the style of Java's fluent API. I strongly dislike PHP, JS, and Python functional style and would almost prefer they not exist.

Re: Rust – A hard decision pays off

#177

Post by s17n »

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…

The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python. I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

Re: Rust – A hard decision pays off

#178

Post by blueslurpee »

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…

We have similar experiences. I absolutely love Typescript. But I don’t like Node very much. So I keep TS in the browser.

I’ve been looking at Nim or Scala for the backend. It’s either that, or just dive into Rust.

It really seems if you don’t want to use Node, Java, or Go the available choices for a statically typed backend get quite slim.

Re: Rust – A hard decision pays off

#179

Post by tialaramex »

sgeisenh wrote: post #171
tialaramex wrote: post #155

Earlier quoted context omitted.

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…

Depending on how you write it, iterators are much better at this since most iterator methods produce iterators with size hints. If you use "take" for example, collect should do the right thing: https://doc.rust-lang.org/src/core/iter/adapters/take.rs.htm...

Mere hints aren't enough for collect()

It will only care about your hints if you implement the unsafe trait TrustedLen (which promises those hints are correct)

Take is indeed TrustedLen if the Iterator it's taking from is TrustedLen (as in this case it can be sure of the size hint)

If you get to ~100 via some means other than take()ing 100 of them, chances are you don't have TrustedLen as a result.

Re: Rust – A hard decision pays off

#180

Post by cratermoon »

UncleEntity wrote: post #87
cratermoon wrote: post #17

Earlier quoted context omitted.

> it seems irresponsible to move your entire team to a programming language none of them knows Based on my experiences, I would agree. There seems to be a very important difference between my experiences, which probably align with most of the industry, and the Pinecone team. My career has been working with average developers doing ordinary business and internet things. Stuff that takes organization and teamwork, but…

If you start the article at the top instead of where the hot link points (which is its own discussion) it starts by talking about mathematically proving why this form of database is faster than theory suggests it to be. Definitely not your average boot camp devs working on this one.

Precisely. Also, it wasn't one of those cases where management decides to move people off of the language they know to one they read about in InfoWorld or CIO Magazine. Or worse, had a golf buddy tell him how great it is.

In the words, the team wasn't moved, the team moved itself.

Post reply on HN