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

231–240 of 386 posts

Re: Rust – A hard decision pays off

#231

Post by labrador »

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.

C# 2022 is much improved over earlier versions. For starts it's cross platform and compiles to reasonably sized single executables (touted as a strength of Go). Moreover, C# designers have started reducing boilerplate as much as possible, so for example, you don't need to declare a namespace, a class or a main to start coding.

That said, Go is a fine language. It doesn't have exceptions last I checked, so that could be a deciding factor. Exceptions are handy in a lot of cases.

Re: Rust – A hard decision pays off

#232

Post by nurettin »

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…

Python is fine, use the typing module, don't be weird with the return types and you will be fine. Sure, you will actually have to think about your algorithm when writing for speed, and naive loops won't work most of the time. But "avoid python in production" or "don't write new code in python" is way too harsh.

Re: Rust – A hard decision pays off

#233

Post by eatonphil »

manfre wrote: post #227
badpun wrote: post #212

Earlier quoted context omitted.

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

Dev teams that are unable or willing to properly architect and test their projects will end up with buggy and difficult to maintainable code regardless of language.

That is unrelated to what the person you're responding to said.

Re: Rust – A hard decision pays off

#234

Post by tlrobinson »

peterkelly wrote: post #223
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…

A lot of people seem to believe that dynamically typed languages make development easier, because you don't have to worry about writing type annotations or going through the extra steps to fix compile-time errors. This is arguably true for small scripts, but for anything non-trivial I find that static typing means I can be more productive, because type errors are caught straight away (rather than potentially in produ…

> I find that static typing means I can be more productive, because type errors are caught straight away

I agree completely. I feel like there’s a pretty common arc among programmers:

1. learn to program using verbose statically typed languages

2. discover fun dynamically typed languages, eschew statically typed languages

3. discover dynamically typed languages are a shitshow for large real-world projects

4. re-discover fun/less verbose statically typed languages that make working on large projects tolerable

Re: Rust – A hard decision pays off

#235

Post by ncmncm »

UncleEntity wrote: post #89
ncmncm wrote: post #69

Earlier quoted context omitted.

> breaking into the Linux codebase Is Linux really your go-to example? Linus is noted for his irrational hostility to C++. His complaints are proved silly or, at best, obsolete by the example of Serenity OS. An example of a measure to make the language easier to adopt is to allow borrow violations to be made a warning when building in debug mode. All violations would need to be patched up before release anyway, so it…

It seems like a bad idea to allow what is arguably the main selling point of the language to be turned off by a compiler flag so someone can build the rest of their program on top of that shaky foundation. Whole hog or no hog, this is the rust way.

I.e., a ridiculous objection that demonstrates wholesale incomprehension of the topic.

This is an example of why I expect the language may still fizzle.

Re: Rust – A hard decision pays off

#236

Post by jxf »

Thaxll wrote: post #203
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…

Rust std lib is subpar compared to the Go one, yes you have iterators but that's it, basic things like async are not even provided just the interface so everyone has to use tokyo. Then for real use cases you're missing http/json/compression/crypto etc ... https://pkg.go.dev/std Overall tooling and std lib are better on Go, actually there are not many languages that are on part with Go to that regard. When you see wha…

Quick correction for anyone searching: it's `tokio`, not `tokyo`. [0]

[0]: https://tokio.rs/

Re: Rust – A hard decision pays off

#237

Post by nindalf »

ncmncm wrote: post #69
mynameisash wrote: post #54

Earlier quoted context omitted.

> its fans are almost uniformly hostile toward any measure that could make it easier to adopt. Do you have an example exhibiting what you mean here? I would self-describe as a fan of Rust, but I also think I'm pretty realistic about its limitations and that every language has its niche. I will say that as far as miracles go, being the most-loved language on SO for seven years seems like a bit of a (minor) miracle her…

> breaking into the Linux codebase Is Linux really your go-to example? Linus is noted for his irrational hostility to C++. His complaints are proved silly or, at best, obsolete by the example of Serenity OS. An example of a measure to make the language easier to adopt is to allow borrow violations to be made a warning when building in debug mode. All violations would need to be patched up before release anyway, so it…

You seem quite certain of your opinions, especially that Rust will fizzle out. I'll bet $100 that in 2025

- it's still used at Meta, Google, Amazon and other large companies. Once a language gains critical mass at a large, profitable company it will be maintained one way or another.

- It will be used in the Linux kernel as well.

If you have any other objective measures of usage/popularity/usefulness, I'd like to hear it.

> In any given week, more people pick up C++ or Javascript to use professionally than the total number now employed to code Rust.

If you can tell me how you measure this I'll take a bet that this is wrong as well.

Re: Rust – A hard decision pays off

#238

Post by obviouslynotme »

t43562 wrote: post #64

Writing something for the second time is a significantly different experience so that makes the conclusion much less definitive to me. Did they need python at all the first time - maybe not. Python "velocity" is, to me, more about the ease with which you can make changes without breaking other code. You can still break other code and if you don't have a proper test suite then you're wasting your time - which is somet…

This is my feeling as well. The biggest problem with new projects is that you don't know what the product will look like in advance, even if you think you do. Restructuring code, especially with full 20/20 hindsight, will make that code much better.

Re: Rust – A hard decision pays off

#239

Post by theptip »

I'd be interested in a bit more detail on the technical migration strategy. Did they just cut over to a version of the project built in Rust? (I.e. vN is Python+C/C++, vN+1 is Rust?) Or something more gradual?

How did they verify that the new code was conformant with the old app's behavior/logic?

> To make matters worse, we would discover issues only after deploying (or in production!) due to Python’s run time nature.

I don't want to infer too much, but this makes it sound like perhaps they didn't have a very robust set of E2E/Acceptance tests, which would make a full-cutover migration scary to me. If you're finding Python bugs only after deploy, how can you find the inevitable rewritten-Rust-code incompatibilities before deploying/production?

I've been digging into Rust/Python interop recently using https://github.com/PyO3/pyo3 and maturin, and this points to an interesting migration strategy; PyO3 makes it quite easy to write a Python module in Rust, or even call back and forth between them, so you could gradually move code from Python to Rust. A migration path to full-Rust might be:

1. Incrementally replace all your fast-path C/C++ code with Rust, still having Python call these compiled modules. End-state: You now have a Python/Rust project instead of Python/C/C++.

2. Gradually grow the surface area of your Rust packages, moving logic from Python into Rust. Your existing Python tests can still run, and your existing entrypoints are the same Python.

3. At some point, you presumably need to cut over the entrypoint layer (the API?) to use pure Rust, instead of Python. This should be a much less scary migration since both versions are calling into the same underlying Rust library code. Depending on your architecture, if you have an API Gateway you can split your service backends to migrate one endpoint at a time to the new Rust API service, while keeping the old Python API service around to fail back to. (They are using k8s so you can do this with your Ingress for example).

I'm interested in others' experiences with Rust/Python interop, are there any rough edges worth knowing about?

Re: Rust – A hard decision pays off

#240

Post by ncmncm »

nindalf wrote: post #237
ncmncm wrote: post #69

Earlier quoted context omitted.

> breaking into the Linux codebase Is Linux really your go-to example? Linus is noted for his irrational hostility to C++. His complaints are proved silly or, at best, obsolete by the example of Serenity OS. An example of a measure to make the language easier to adopt is to allow borrow violations to be made a warning when building in debug mode. All violations would need to be patched up before release anyway, so it…

You seem quite certain of your opinions, especially that Rust will fizzle out. I'll bet $100 that in 2025 - it's still used at Meta, Google, Amazon and other large companies. Once a language gains critical mass at a large, profitable company it will be maintained one way or another. - It will be used in the Linux kernel as well. If you have any other objective measures of usage/popularity/usefulness, I'd like to hear…

Every language you can think of, and many you can't, are in use somewhere at every large company. That is no distinction at all. So, no bet.

If it gets into the Linux kernel in any capacity, obviously it will still be in there as long as anybody still uses whatever it does. That, also, is no distinction at all. So, no bet.

I am not expressing opinions. I am expressing observations, and expectations that seem to follow. If you have other observations that bear on the question, bring them.

Post reply on HN