Live data from Hacker News

Rust – A hard decision pays off

pinecone.io

321–330 of 386 posts

Re: Rust – A hard decision pays off

#321
post #253
post #159

Writing Rust at scale, I concur with some of these findings. Nowadays, my team exclusively writes Rust. Our rationale is two-fold. 1) We want to write software that is fast and inexpensive to run. Our rust services are quickly growing, but cumulatively, they remain in the sub-1000 core count, while processing many millions of requests per second across our service with excellent latency. 2) We want to write software…

I am curious which web framework do you use? Also do you use an ORM like diesel?

We use a mix of axum, and tonic/tower, depending on if the service is internal (grpc) or external (http).

And no, we do not use an ORM like diesel, since we primarily use ScyllaDB. We wrote our own - it's very nice. We have a fully type-safe scylla/cassandra client, that does static validation of the queries (which we define as annotated structs), and also, when the service starts up, it validates that the schema that the service has agrees with the schema the database has. Insofar a making sure that if you say `WHERE id = ?`, and you pass a i32 but it wanted a String, the service will not start.

It also does request coalescing and tracing/telemetry, and will soon do rate limiting, circuit breaking and speculative retries as well.

Re: Rust – A hard decision pays off

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

When I went from Java to Ruby on Rails it was an incredible breath of fresh air, and a massive, massive time saver, and truthfully Ruby can do many things Rails can not, and it worked well.

On a language level though (I still hate java) but the type safety was nice and did save you a lot of worry. In retrospect I realize most of the issue was the frameworks available and all the terrible configuration stuff.

I love that today you have so many more options because for a lot of time you do save time on a per line level..

Re: Rust – A hard decision pays off

#323
post #261

Earlier quoted context omitted.

Iterator-chain version would be a lot better looking if it was actually was a chain and not everything pushed into a single `filter_map`. "Ifs" are weird looking, one branch is using `entry`(I take it's a `DirEntry`?) and another is using `file_name` I suspect both could use the and look like `Self::is_` ? If you're going to write an iterator chain in an imperative way, then you might as well right it imperatively. A…

Forgive me for asking instead of looking, I'm still getting into rust; why do you map instead of getting the result? path.extension().map(|ext| ext == "bundle").unwrap_or(false) vs (path.extension() == "bundle").unwrap_or(false) or further up .map(|e| e.map(|e| e.path())) vs .map(|e| e.path()) Is the .map keeping any value wrapped in an iterator so you can map again? I thought it was interesting what you wrote looks…

Not your parent, but I do know the answer.

extension() returns an Option, because not every file has an extension https://doc.rust-lang.org/stable/std/path/struct.Path.html#m...

map on option says "run this closure on the value if it's Some, or do nothing if it's None https://doc.rust-lang.org/stable/std/option/enum.Option.html...

So after the map, we now have an Option. The unwrap_or method will say "give me the value if it's Some, and give me the argument if it's not https://doc.rust-lang.org/stable/std/option/enum.Option.html...

That means we finally end up with a bool.

  (path.extension() == "bundle").unwrap_or(false)
This code wouldn't work because you're comparing an Option to a &str. Even if that worked, you'd have a boolean, and unwrap_or doesn't make sense on booleans, you'd just leave off that part.

Re: Rust – A hard decision pays off

#324
post #290
post #207

Earlier quoted context omitted.

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.

Garbage collector is still a steaming pile though

Source? I thought .NET GC was tuned for high throughput.

Their performance is, impressive, to say the least.

https://www.techempower.com/benchmarks/#section=data-r21

Re: Rust – A hard decision pays off

#325
post #95

Earlier quoted context omitted.

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.

IMO that "culty feeling" you're getting is the end result of a lot of very experienced engineers encountering Rust, going "holy shit", and trying to preach about it from the rooftops because it feels so much better than the things that have come before it. I find this particularly compelling because Rust generally does not market itself towards novice developers. At least until very recently, I've seen Rust communiti…

No, the culty feeling is this paragraph long explanation about how Rust is objectively good, paired with the downvotes I got from saying I feel like Rust is culty.

Pretty sure most experienced devs will say "use whatever works, there's some art out there written in erlang/JS/C++"

Case in point I think the most valid critique is that Rust is new and lacks a developed ecosystem. As an ML person myself it's not even useful for me to learn Rust unless I want to roll alot of my own stuff. So if your "experienced developers" are preaching about the best languages to promote, to learn as a hobby, etc.. they're not preaching about the best languages for prod unless it's for some specific application.

Also, fucking lmao, get over yourself, Rust isn't that hard to learn

And even if it were, being able to understand what is essentially wacky C++ doesn't mean you've "been in the industry awhile"

Re: Rust – A hard decision pays off

#326
post #308
post #95

Earlier quoted context omitted.

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.

How would you expect the response to something genuinely better to be different, in a non-culty way?

Well there you go, if it's genuinely better it will speak for itself.

See when I'm being an apologist I say shit like

"Python-like syntax but it compiles to assembly"

"You can mess with the AST like in LISP, to make everything differentiable"

"You can type the code for 10x speed, or leave it untyped for readability, multiple dispatch is basically magic"

You don't see me going around saying "Julia is objectively better"

And not only because I don't want to be a cultist but because it isn't and can't be true, something about no free lunch, something about Gödel incompleteness and expressivity, something something...

Re: Rust – A hard decision pays off

#327

Earlier quoted context omitted.

Yes re: Python. Story -- I was a very early adopter of Python, back in the mid-90s. When other people wrote their CGI scripts in Perl, I always reached for Python. The first paid gig I ever had was a CGI script ("resume builder") I wrote in Python in 1996. But almost nobody was using it back then, and I'd get quizzical stares from people in job interviews etc. when it came up. So for many years back then I really rea…

I read "CGI" as computer generated imagery, python was a strong glue language in this field in the 90s. Also I think people misread 'python speed', few c++ masters said it was more about prototyping to converge on good overall design rather than suffering the efforts of early iterations in c++ (90s c++).

Definitely in the context of the times, Python was more pleasant overall for initial prototyping than any static typed alternatives, including Java.

I still use it for quick one-off scripts to "do things" with bits of data and so on. And as a calculator.

Re: Rust – A hard decision pays off

#329
post #177

Earlier quoted context omitted.

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.

> The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python Rust gets safety with its ownership system. The ownership system brings strong guarantees around who is mutating / reading any given object. Python has uncontrolled ownership. Any function can generally mutate / store any variable you pass in. This can definitely cause bugs if a rouge funct…

For those not familiar with ownership concepts, it does apply to many things beyond just memory management. Most obvious example of this is file handles. In python you have to close() them or scope within a context manager to auto close when the block exits. If you need more complex logic around, such as transfer the handle into another function, the context manager is no longer sufficient and you quickly loose track of who should call close(), is it the caller or the callee.

Rust keeps track of this, no matter how deep you twist your logic and it does so for every variable, no context manager blocks required.

Re: Rust – A hard decision pays off

#330
post #177

Earlier quoted context omitted.

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.

> 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. Rust has a very expressive type system[0], which you won't otherwise find before hitting the more functional and research-y side of things. Modelling data in terms of enums (sum types), move types (affine types), etc... makes it a lot more reliable and a lot less faillible as…

Other than Rust the only other "pragmatic" language I can think of that has as much of a robust type system is Typescript. As you say anything else you'd have a hard time convincing the rest of your team to use.
Post reply on HN