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

331–340 of 386 posts

Re: Rust – A hard decision pays off

#331

Post by sitkack »

fwip wrote: post #256
throwaway894345 wrote: post #128

Earlier quoted context omitted.

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

I think the intent of saying "you've always been writing Go" was along the lines of "you can write FORTRAN in any language." E.g, implying that you are not making use of Python's abstractions, but writing it in the same procedural style you would write Go (or C) code in.

That is exactly what I am saying. I not talking trash about Go. But if one isn't using Python for what it is good at, don't use it, use the language you are actually using.

Re: Rust – A hard decision pays off

#332

Post by moreice »

stouset wrote: post #285
s17n wrote: 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. That's not entirely true. As an easy example, Go has a type system but it's relatively anaemic and recreates the "billion dollar mistake" of nil. I have personal experience with Go applications that have broken in production due to nil dereferences, to bugs related to type-swi…

Agreed, also consider C++ whose type system uses implicit conversions and mutability by default, leading to a number of non-memory related bugs.

Re: Rust – A hard decision pays off

#333

Post by arunc »

jhgg wrote: post #321
nazka wrote: post #253

Earlier quoted context omitted.

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

> We have a fully type-safe scylla/cassandra client, that does static validation of the queries

Is this on a crate by any chance? Thanks

Re: Rust – A hard decision pays off

#334

Post by nprateem »

jhgg wrote: post #258
nprateem wrote: post #115

Earlier quoted context omitted.

Don't you find thinking about the borrow checker unnecessary overhead while prototyping?

No. Not anymore. 4 years in and I maybe run into a borrow checker issue very rarely in a given week. Once you understand how the borrow checker works and how to write/structure your code in a way that the borrow checker is happy with it sort of becomes second nature. I think by side effect coding in this style does lend itself to simply writing better to understand code. Nowadays I just write my code this way without…

Interesting. I tried rust maybe 6 years ago and the combination of the BC and its slow compile times drove me away. Actually my main gripe was something to do with it not being obvious when calling a function that it needed a reference (I forget the specifics), but maybe that's been improved with better code completion in intellij. I may take another look.

Re: Rust – A hard decision pays off

#335

Post by elcritch »

blueslurpee wrote: post #178
xmonkee wrote: post #96

Earlier quoted context omitted.

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…

We have similar experiences. I absolutely love Typescript. But I don’t like Node very much. So I keep TS in the browser. I’ve been looking at Nim or Scala for the backend. It’s either that, or just dive into Rust. It really seems if you don’t want to use Node, Java, or Go the available choices for a statically typed backend get quite slim.

If you like doing compile time things with types like typescript enables then Nim is fantastic. I've been learning Rust recently and I'm continually disappointed with how little compile time or type based stuff you can do.

Re: Rust – A hard decision pays off

#336

Post by masklinn »

DoesntMatter22 wrote: post #322
nu11ptr wrote: 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 t…

> In retrospect I realize most of the issue was the frameworks available and all the terrible configuration stuff.

Also that Java’s type system is… not great.

So you have to put in a lot of effort (especially if it was before java 8, to say nothing of Java 5) and you just… don’t get much out of it.

Even more so given the syntactic overhead of defining java types before records (or without Lombok), to say nothing of the performance cost.

Re: Rust – A hard decision pays off

#337

Post by brabel »

jasim wrote: post #153
brabel wrote: post #122

Earlier quoted context omitted.

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…

As a relative newcomer to Rust, I'm curious to hear about those early mistakes

What the sibling comment said is spot on! Rust requires you to design programs very differently than what you do in GC-languages.

You may try to avoid using things like lifetimes for a while, but those are completely undispensable to writing Rust... same with macros. They are really important and widely used in Rust.

One very good way to avoid simple mistakes is to configure Clippy to run on your IDE (or just run it manually): https://github.com/rust-lang/rust-clippy

Re: Rust – A hard decision pays off

#338

Post by moonchrome »

adamdusty wrote: post #200
moonchrome wrote: post #28

Earlier quoted context omitted.

>but modern C++ is great too. No, modern C++ is still cobbled together from tools built in a different era. It doesn't even come with a package manager/build system. Just on the fact that cargo/crates.io exist and it has modules - it would have to be really bad to make me go back to C++ if I ever need to write something at that level.

There are package managers and build systems. MS ships a build system with visual studio and msvc and they have a fairly capable package manager in vcpkg. I like cargo better than any c++ tooling but those tools don't really make a ton of sense for c++ where every platform has a different compiler. Ultimately, I agree. I don't think I'll be going back to c++ any time soon, but for me it's more about the tooling fragm…

I mean sure, there are many environments you can use for any particular platform - but that's not how I develop software these days - I need my code to run on my Mac, my coworkers Windows machine and our deployment servers on Linux - with the least ammount of fuss possible.

I wince when I think about how much time I spent dealing with that crap back when I was doing C++.

Re: Rust – A hard decision pays off

#339

Post by badpun »

ithrow wrote: post #279
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.

If you, on the other hand, want to write good, performant, maintenable and (relatively) bug-free software, then there are better choices. You can do that part when the money comes in.

Once you invite the investors in, the company isn't truly yours, and they expect 1000x growth. There will always be higher priorities than a rewrite.

If you don't take investors' money, then it's theoretically feasible, but, in practice I've seen companies stuck with their Python/Ruby stack for 10 years or longer, always wanting to rewrite but never having the time. Microservice architecture helps (not that it's not a can of worms of its own), and these companies tend to write new functionalities in their desired language (such as Go or Scala) and deploy them as separate microservice. The old code remains in Python or Ruby though, and now they have a multilingual mess that is near-to-impossible to maintain for a small team. Why not start with a better language in the first place?

Re: Rust – A hard decision pays off

#340

Post by foldr »

throwaway234566 wrote: post #319
Thaxll wrote: post #203

Earlier quoted context omitted.

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…

Agreed 100%. Go doesn't have a standard library problem, it has a userland language problem. * No sum types / algebraic data types in 2022. * No exhaustive pattern matching in 2022 * No move semantics / Uses GC * No borrow checker * Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like) Current go users are already sold…

Seems a bit odd to criticize Go for using GC rather than a borrow checker to manage memory. There’s surely a place for GCed languages, even if they’re not the right choice for every domain.
Post reply on HN