Live data from Hacker News

Rust – A hard decision pays off

pinecone.io

91–100 of 386 posts

Re: Rust – A hard decision pays off

#91

I don't want to be dismissive but how much of this success belongs to the team of rock solid senior engineers with enough experience under their belt rather than rewrite in Rust?

A team with no rust experience This mirrors my experience: getting buggy software out is easier and faster in JS (or whatever you're familiar without compile guarantees), getting something out to production is easier with rust. Sometimes you have enough senior developers and discipline to reproduce and catch obscure bugs (which happen more or less based on your software complexity) and you can fix your mess but that'…

The more senior I get (decades of experience now), the more I appreciate languages that simply remove the mere possibility of entire classes of bugs. Even in Objective-C — a dynamic language with compile-time type enforcement — if something very weird is happening you have to start with “is that object really what I think it is?“

Re: Rust – A hard decision pays off

#92
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"…

If you read it carefully you'll see that they "rewrote" it by replacing components of it. Which:

1. Allowed them to evaluate if it would actually work. 2. Allowed them to train the team on it in a scalable way.

The result is that the team learned Rust and Rust fixed a bunch of problems. They were appropriately pragmatic in their approach and Rust was appropriately pragmatic in it's solutions to their problems. If you are ever considering migrating your codebase for some reason this is how you should go about it.

TLDR: You are heavily mis-characterizing their team and this article.

Re: Rust – A hard decision pays off

#93
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"…

I read it as Rust forced the developers to be specific with their implementations and problems went away as a result.

I say this because I'm often _AMAZED_ at just how undisciplined the majority of developers I work with are wrt stability and error propogation.

Re: Rust – A hard decision pays off

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

Re: Rust – A hard decision pays off

#95

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.

I guess I’m rooting for Rust in the long game sense, which is a different set of imperatives than the hang the hashtag on peripheral stuff sense. I use a lot of great software written in Rust, it’s demonstrably a good vehicle for great software. But too many of its fans are advocates , this can start to seem like an agenda. Don’t take engineering advice from people with an agenda.

Thank you for pointing this out. Lately I've been getting a culty feeling around Rust which has been turning me off to learning it.

Re: Rust – A hard decision pays off

#96

> 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 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 solo dev, it's saving me an incredible amount of time to go to market.

I've had experience with large codebases in Python, Java, Go and Javascript before.

Python - as everyone already said, just sucks. Refactoring is a nightmare, you have to test every single line of code for any sort of dependability and that makes refactoring even harder. It allows for too much meta-programming and within 3-6 months your codebase is legacy.

Java is just not fun to write for me, but Kotlin is kinda fun and I could see myself choosing that. The problem is that my product deals with a lot of deeply nested, user-defined objects, and converting JSON (or YAML, or XML) to POJOs is a verbosity nightmare.

I just fucking really hate Go. 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.

Re: Rust – A hard decision pays off

#97
post #70

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…

Talking about Haskell and stuff. You what I want? Rescript to replace entirely Typescript. That will be so much better.

I would endorse that.

TypeScripts's type-system soundness holes kill the fun with that language very quickly, imho. That was a really big disappointment for me.

A "static" language that compiles fine and than crashes at runtime with complete WTF-bugs is not much better than a dynamic language. You just can't trust the compiler and need to double check every line of code anyway. So there is not much additional value in this kind of "type safety".

I would prefer Rescript of Scala.js anytime to TypeScript. Got really disillusioned by TS.

Re: Rust – A hard decision pays off

#98
post #95

Earlier quoted context omitted.

I guess I’m rooting for Rust in the long game sense, which is a different set of imperatives than the hang the hashtag on peripheral stuff sense. I use a lot of great software written in Rust, it’s demonstrably a good vehicle for great software. But too many of its fans are advocates , this can start to seem like an agenda. Don’t take engineering advice from people with an agenda.

Thank you for pointing this out. Lately I've been getting a culty feeling around Rust which has been turning me off to learning it.

but it's the same with every hype: there's something at its core and might be worth checking out

Re: Rust – A hard decision pays off

#99

> 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…

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

Re: Rust – A hard decision pays off

#100

Earlier quoted context omitted.

Credit where credit is due: Rust has done a far better job than most of free-riding on Haskell’s type class system and clang’s optimizer, but rust-analyzer is a dumpster fire next to clangd, that’s not an example I’d use.

Um what? Maybe it's just that I don't understand what clangd provides that's so great, but rust-analyzer, despite a few hiccups I've had with it, seems completely amazing at what it does.

Well we could start with the fact that it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890 (it’s always LLVM’s fault, I know). Or move right along to the insane configuration hacks that are mandatory if you want anything upmarket of VSCode (who doesn’t need a little practice with their Emacs Lisp), or the N^2 whatever that happens when you point it at bindgen output.

What clangd does is work.

Post reply on HN