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

211–220 of 386 posts

Re: Rust – A hard decision pays off

#211

Post by celdon25 »

3pt14159 wrote: post #210
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 disagree. Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. Now you can say that this is a tradeoff for post Series B, and for that I don't know. I've never worked on a massive Python mono-repo for a company that size. But I know what I've done in Python and, yes, it includes performance optimization in Numpy / Scipy / Cython, and other than Ruby, no other…

> Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby.

Is there data on startup lifespan ranked by tech stack? Genuinely been looking for this for awhile now.

Re: Rust – A hard decision pays off

#212

Post by badpun »

3pt14159 wrote: post #210
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 disagree. Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. Now you can say that this is a tradeoff for post Series B, and for that I don't know. I've never worked on a massive Python mono-repo for a company that size. But I know what I've done in Python and, yes, it includes performance optimization in Numpy / Scipy / Cython, and other than Ruby, no other…

> I disagree.

> Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby.

It depends on what your goal is. If you want to get rich off of VC money, Python and Ruby might be a good fit. If you, on the other hand, want to write good, performant, maintenable and (relatively) bug-free software, then there are better choices.

Re: Rust – A hard decision pays off

#213

Post by tialaramex »

Alexendoo wrote: post #204
tialaramex wrote: post #179

Earlier quoted context omitted.

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.

TrustedLen will mean it can safely take the upper bound, but Vec for example will still use the lower bound of the hint when something isn't TrustedLen https://doc.rust-lang.org/src/alloc/vec/spec_from_iter_neste...

Ooh nice, I hadn't seen that. OK, so there are probably places where I assumed the iterator won't do as nice a job of collect() as I did manually but I was wrong.

I wonder how the hell I didn't see that when I was tracking down how collect() ends up caring about TrustedLen.

Thanks.

Re: Rust – A hard decision pays off

#214

Post by metaltyphoon »

sharno wrote: post #207
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'd argue that C# (dotnet core) is a much better option than Go for an easy GC language with max productivity and great performance ceiling.

Not only that, but greater tooling too.

Re: Rust – A hard decision pays off

#215

Post by mwcampbell »

benreesman wrote: post #110
fkarg wrote: post #98

Earlier quoted context omitted.

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

Oh I think a hype like this comes along once or twice in a career. Java was every bit as revolutionary in its day and had Sun Microsystems (they were a Big Deal) pouring every spare dollar into fluff pieces about it and it still never achieved a true Jehovah’s Witness vibe.

Well, Java had at least one aspect of a religion: a purity test. Remember "100% Pure Java" from the late 90s?

Re: Rust – A hard decision pays off

#216

Post by nindalf »

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…

The other comments have pointed out this was a simple misconfiguration that was easily fixed.

What I take exception with is "it’s always LLVM’s fault, I know". If you're going to trash other people's hard work in such a glib manner, it behooves you to know the details of what you're talking about. Tell us, why would a language server that doesn't generate any code use LLVM?

Re: Rust – A hard decision pays off

#217

Post by metaltyphoon »

AtNightWeCode wrote: post #83
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…

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/

Event the C# version is simpler :D

https://github.com/dotnet/Docker.DotNet#example-create-a-con...

Re: Rust – A hard decision pays off

#218

Post by synergy20 »

throwaway894345 wrote: post #148
dls2016 wrote: post #143

Earlier quoted context omitted.

> but man Rust was a breath of fresh air with the amount of tooling that helped me solve problems The tooling is the #1 reason I'd like to learn rust. I have not kept up with C++ and I'm not sure I ever will... sometimes plain C seems more straightforward. But those languages (C++ especially) have suffered from lack of standard tooling, in my opinion. Even C# being a few years younger than Java seems to have made a h…

Tooling was the reason I left C++. Having to do your own package management and script your own build system was deeply dull work. The IDE story was also pretty miserable, although I think clangd has improved it a bit. Getting decent information out of core dumps also sucked a lot. The language actually didn’t bother me too much after c++11, but everything else was such a bear that I jumped ship. Rust has been very r…

I actually filed a ticket at Carbon project saying c++'s top 1 problem is tooling, modern c++ is pretty nice to use already, no need for Carbon there in fact, at least not as needed as tooling.

Re: Rust – A hard decision pays off

#219

Post by throwaway894345 »

nomel wrote: post #170
throwaway894345 wrote: post #154

Earlier quoted context omitted.

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.

I'm not sure what you mean. You don't have to deal with index variables in a for loop:

    for item in iterator {
        vector.push_back(foo(item));
    }
You're not explicitly indexing the source iterator or the destination vector at any point.

Re: Rust – A hard decision pays off

#220

Post by infamia »

throwaway894345 wrote: post #101
hnfong wrote: post #72

Earlier quoted context omitted.

I think this is a bit unfair. As always, blanket statements in software engineering aren't really meaningful. 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. I also agree that 'Python has been a s…

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

> This might be true for certain Django CRUD apps, but it's patently untrue in the general case. I've seen Python work fine for a prototype data science app, but fall over when real customer data was introduced.

The cognitive dissonance embedded in this statement is rather striking, considering Django itself is written in Python and is known for its ruggedness and code quality. Django manages all of this without even taking advantage of somewhat newer features in Python like typing.

Post reply on HN