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

121–130 of 386 posts

Re: Rust – A hard decision pays off

#121

Post by throwaway894345 »

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…

Survivorship bias. You don't hear about the failures. Moreover, many of those things (e.g., lots of Python at Google) was written at a time when there weren't better options, so you weren't struggling to make Python work while your competitor is writing Go or TypeScript.

Re: Rust – A hard decision pays off

#122

Post by brabel »

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 say it worked for them either because they are highly skilled and can learn difficult things like Rust quickly and efficiently... or their previous code was so completely broken than anything else would be better :D...

Re: Rust – A hard decision pays off

#123

Post by SoftTalker »

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…

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

Re: Rust – A hard decision pays off

#124

Post by tialaramex »

benreesman wrote: post #34
tialaramex wrote: post #31

Earlier quoted context omitted.

Search your heart, do you think this story ends similarly if they decide to all do "modern C++" instead? My guess is that even with initial discipline in the form of code review and style enforcement by one or two people, the C++ descends into a riot of different opinions about, as usual, which are the good bits. A similar piece of software could be written in C++ but I doubt it gets written successfully, in similar…

You might want to take that up with the authors of RocksDB and FAISS. They seem to have shipped some cool stuff.

RocksDB, as I understand it, is a pretty old piece of software, forked from a Google product, which was already a pretty old piece of software, all written in C++. Doesn't seem to have previously been written in Python, doesn't seem to have a team of non-C++ programmers who decided to just learn as they went, and so it's not clear what parallels you expect to draw.

Maybe they're doing a Rust rewrite too? I'd be interested to read about that.

Re: Rust – A hard decision pays off

#125

Post by coder543 »

benreesman wrote: post #100
mustache_kimono wrote: post #90

Earlier quoted context omitted.

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…

You linked to an issue from over a year ago to support your case? And the solution in that issue was just "switch to the right extension"? That's hardly a compelling argument. By all appearances, that person’s environment was completely broken since they reported the other extension did nothing at all, and a broken environment isn’t really a reflection on the tool. I can set up a broken environment for any tool and then complain about it. The absence of a bunch of other people encountering the same issue in that thread indicates this was not some big issue with rust-analyzer.

If I search for "Rust" in the VS Code Extension Marketplace, it shows the extension you linked to... but it is clearly marked as deprecated, and VS Code won't even let me install it. So, it’s even more of a non-issue today than it was a year ago.

The actual rust-analyzer extension works fine for me. I think Go's tooling is slightly better in my experience, but both are far better than any experience I've had with C++ tooling.

Re: Rust – A hard decision pays off

#126

Post by reitanqild »

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'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 don't hate it like you, I just find it amazingly backwards, and I think I can explain why:

The community has the same persistence as certain teachers when it comes to locking things down and making things harder than necessary for no good reason, all for our own good.

Prime example: announcing a supposedly cutting edge language without generics in 2009, launching version 1.0 without it in 2012, 8 years after notoriously conservative Java got it, then waiting until 2022 before listening, that is some hardcore teacher mentality IMO.

Re: Rust – A hard decision pays off

#127

Post by hu3 »

golergka wrote: post #84
throwaway894345 wrote: post #75

Earlier quoted context omitted.

I sort of agree, but I also think type systems are somewhat overrated compared to performance, static compilation, native compilation, easy cross compilation, good tooling, expansive ecosystem (esp devoid of C dependencies). I think TS and Go are on par with respect to tooling and ecosystem, but I would rarely trade Go's static, native compilation model (distributing a single static binary is pretty awesome) for some…

> distributing a single static binary is pretty awesome It is, but does it really matter when you write backend? I've written and operated Node-based backends at scale, and I can't honestly remember any bugs or outages that would have been prevented by this. At the other hand, there's a lot of potential bugs and problems that didn't happen because proper usage of TS's type system prevented me from committing them.

> I've written and operated Node-based backends at scale.

I'm interested in producing fullstack typesafe web projects using typescript on both backend and frontend.

My question is how do you scale nodejs since it is single-threaded? Say I need 10k concurrent connections. These connections doesn't have to be all hammering the system at once but I need to accept 10k connections and perform something like 2k requests/s.

How do I approach this? One server with clustered nodejs? pm2?

I ask because there are a ton of outdated info on how to scale nodejs.

Some rudimentary benchmarking with clustered or pm2 nodejs tells me that 95 response times go from 30ms to 1000ms once I hammer the server. Whereas Go and C# keep it under 100ms without any effort or extra tooling, just using standard library.

Re: Rust – A hard decision pays off

#128

Post by throwaway894345 »

sitkack wrote: post #108
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…

If Go replaces your Python this easily, you have always been writing Go. The abstractions available in Python are in a totally different class than that of Go. Nothing you said is verifiable.

> Nothing you said is verifiable.

Right, I was pretty explicitly speaking from experience. See my first paragraph.

> If Go replaces your Python this easily, you have always been writing Go

Go is only a 10 year old language, and I've been writing Python professionally for 15 years. I definitely have more hours on Python by a wide margin.

> The abstractions available in Python are in a totally different class than that of Go.

Python definitely is more abstract than Go, but I don't think that's a feather in its hat. Moreover, most of my criticisms of Python had nothing to do with its abstract nature.

Re: Rust – A hard decision pays off

#129

Post by throwawaymaths »

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…

Those projects were started when python was the least bad choice and grew out quickly enough that they could hire legions of developers to work around pythons problems.

Re: Rust – A hard decision pays off

#130

Post by mustache_kimono »

benreesman wrote: post #100
mustache_kimono wrote: post #90

Earlier quoted context omitted.

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 crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890

So -- this guy used an extension (named Rust) with rust-analyzer, a configuration known to not work, it didn't work(!), and the extension author recommends he tries the extension made for rust-analyzer.

Hardly a case for the ages. Guy uses unsupported config and things don't work?

> What clangd does is work.

Don't doubt it. I'm just saying -- I haven't had any problems with the rust-analyzer extension since it became the Rust default. But, yes, I had a few hiccups and crashes beforehand, no doubt. I just have to imagine it's both younger, and doing more/different things than clangd.

Post reply on HN