Removed rust to gain speed • Hacker News Board

Re: Removed rust to gain speed

#21

Post by burnt-resistor » Sun, Dec 07, 2025, 6:16 AM UTC

honeycrispy wrote: post #17

theusus wrote: post #15

Earlier quoted context omitted.

> manual memory management Rust has automatic memory management. > Complexity tax Could you be more specific?

The trait/type system can get pretty complex. Advanced Rust doesn't inherit like typical OOP, you build on generics with trait constraints, and that is a much more complex and unusual thing to model in the mind. Granted you get used to it.

OOP inheritance is an anti-pattern and hype train of the 90's/00's, especially multiple inheritance. Especially the codebases where they create extremely verbose factories and abstract classes for every damn thing ... Java, C++, and the Hack (PHP-kind) shop are frequently guilty of this.

Duck typing and selective traits/protocols are the way to go™. Go, Rust, Erlang+Elixir... they're sane.

What I don't like about Rust is the inability to override blanket trait implementations, and the inability to provide multiple, very narrow, semi-blanket implementations.

Finally: People who can't/don't want to learn multiple programming language platform paradigms probably should turn in their professional software engineer cards. ;)

Re: Removed rust to gain speed

#22

Post by burnt-resistor » Sun, Dec 07, 2025, 6:24 AM UTC

ckwalsh wrote: post #8

I'm in the "Pro-Rust" camp (not fanboy level "everything must be rewritten in rust", but "the world would be a better place if more stuff used Rust"), and I love this post. They saw some benefits to Rust, tried it, and continued to measure. They identified the Typescript/Rust language boundary was slow, and noticed an effect on their contributions. After further research, they realized there was a faster way that did…

> I'm in the "Pro-Rust" camp (not fanboy level "everything must be rewritten in rust", but "the world would be a better place if more stuff used Rust")

While techno-religiosity is irrational and unprofessional, but that's some weak, eye-rolling both-sidesism.

The world would be a better place™ if more stuff used better and more formal tools and methods to prove that code is correct and bug-free. This is easier in some languages than others, but still, there's a lot of formal verification tools that aren't used enough and methodology patterns and attitudes that are missing from crucial projects and regular use. Effective safety and security assurance of software creation takes effort and understanding that a huge fraction of programmer non-software engineers don't want to undertake or know anything about. This needs to change and is defensible, marketable expertise that needs to be appreciated and cannot be replaced by AI anytime soon. There's no "easy" button, but there are a lot of "lazy" "buttons" that don't function as intended.

Re: Removed rust to gain speed

#23

Post by AnotherGoodName » Sun, Dec 07, 2025, 6:32 AM UTC

hresvelgr wrote: post #13

I'm sure you could get even greater speed by removing Prisma. All you need is a migration tool and a database connection. Most recent example in my work where we removed an ORM resulted in all of our engineers, particularly juniors becoming Postgres wizards.

Using an ORM and escape hatching to raw SQL is pretty much industry standard practice these days and definitely better than no ORM imho. I have code that's basically a lot of

    result = orm.query({raw sql}, parameters)

It's as optimal as any other raw SQL query. Now that may make some people scream "why use an ORM at all then!!!" but in the meantime;

I have wonderful and trivially configurable db connection state management

I have the ability to do things really simply when i want to; i still can use the ORM magic for quick prototyping or when i know the query is actually trivial object fetching.

The result passing into an object that matches the result of the query is definitely nicer with a good ORM library than every raw SQL library i've used.

Re: Removed rust to gain speed

#24

Post by anon-3988 » Sun, Dec 07, 2025, 6:37 AM UTC

I claim that 99.9999% of software should be written in a GC language. Very, very, very few problems actually requires memory management. It is simply not part of the business requirement. That said, how come the only language closest to this criteria is Go except it hasn't learn about clean water (algebraic data types).

Re: Removed rust to gain speed

#25

Post by mwkaufma » Sun, Dec 07, 2025, 6:39 AM UTC

anon-3988 wrote: post #24

I claim that 99.9999% of software should be written in a GC language. Very, very, very few problems actually requires memory management. It is simply not part of the business requirement. That said, how come the only language closest to this criteria is Go except it hasn't learn about clean water (algebraic data types).

Games are 0.00001% of software? Web browsers? Operating systems?

Re: Removed rust to gain speed

#26

Post by RedShift1 » Sun, Dec 07, 2025, 6:45 AM UTC

AnotherGoodName wrote: post #23

hresvelgr wrote: post #13

I'm sure you could get even greater speed by removing Prisma. All you need is a migration tool and a database connection. Most recent example in my work where we removed an ORM resulted in all of our engineers, particularly juniors becoming Postgres wizards.

Using an ORM and escape hatching to raw SQL is pretty much industry standard practice these days and definitely better than no ORM imho. I have code that's basically a lot of result = orm.query({raw sql}, parameters) It's as optimal as any other raw SQL query. Now that may make some people scream "why use an ORM at all then!!!" but in the meantime; I have wonderful and trivially configurable db connection state manag…

Every project I've come across that uses an ORM has terrible database design. All columns nullable, missing foreign key indexes, doing things in application code that could easily be done by triggers (fields like created, modified, ...), wrong datatypes (varchar(n) all over the place, just wwwhhhhyyy, floats for money, ...), using sentinel values (this one time, at bandcamp, I came across a datetime field that used a sentinel value and it only worked because of two datetime handling bugs (so two wrongs did make a right) and the server being in the UTC timezone), and the list goes on and on...

I think this happens because ORMs make you treat the database as a dumb datastore and hence the poor schema.

Re: Removed rust to gain speed

#27

Post by theamk » Sun, Dec 07, 2025, 6:46 AM UTC

mwkaufma wrote: post #25

anon-3988 wrote: post #24

I claim that 99.9999% of software should be written in a GC language. Very, very, very few problems actually requires memory management. It is simply not part of the business requirement. That said, how come the only language closest to this criteria is Go except it hasn't learn about clean water (algebraic data types).

Games are 0.00001% of software? Web browsers? Operating systems?

Large parts of web browsers (like entire Firefox' UI) is written in javascript already

Operating systems _should_ use GC languages more. Sure, video needs to have absolute max performance... but there is no reason my keyboard or mouse driver should be in non-GC language.

Re: Removed rust to gain speed

#28

Post by jakewins » Sun, Dec 07, 2025, 6:55 AM UTC

PaulRobinson wrote: post #20

hresvelgr wrote: post #13

I'm sure you could get even greater speed by removing Prisma. All you need is a migration tool and a database connection. Most recent example in my work where we removed an ORM resulted in all of our engineers, particularly juniors becoming Postgres wizards.

Congratulations, you have now increased the cognitive load to be productive on your team and increased the SQL injection attack surface for your apps! I jest, but ORMs exist for a reason. And if I were a new senior or principal on your team I’d be worried that there was now an expectation for a junior to be a wizard at anything, even more so that thing being a rich and complex RDBMS toolchain that has more potential…

I think this needs some nuance - this is definitely true in some domains.

Most of the domains I worked in it was the other way around: using an ORM didn’t mean we could skip learning SQL, it added an additional thing to learn and consider.

In the last years writing SQLAlchemy or Django ORM the teams I was on would write queries in SQL and then spend the rest of the day trying to make the ORM reproduce it. At some point it became clear how silly that was and we stopped using the ORMs.

Maybe it’s got to do with aggregate-heavy domains (I particularly remember windowing aggregates being a pain in SQLAlchemy?), or large datasets (again memory: a 50-terabyte Postgres machine, the db would go down if an ORM generated anything that scanned the heap of the big data tables), or highly concurrent workloads where careful use of select for update was used.

Re: Removed rust to gain speed

#29

Post by pjmlp » Sun, Dec 07, 2025, 7:12 AM UTC

hresvelgr wrote: post #13

I'm sure you could get even greater speed by removing Prisma. All you need is a migration tool and a database connection. Most recent example in my work where we removed an ORM resulted in all of our engineers, particularly juniors becoming Postgres wizards.

Same here, I am a big advocate of knowing your SQL, and stored procedures, no need to waste network traffic for what is never going to be shown on the application.

Re: Removed rust to gain speed

#30

Post by pjmlp » Sun, Dec 07, 2025, 7:14 AM UTC

PaulRobinson wrote: post #20

hresvelgr wrote: post #13

I'm sure you could get even greater speed by removing Prisma. All you need is a migration tool and a database connection. Most recent example in my work where we removed an ORM resulted in all of our engineers, particularly juniors becoming Postgres wizards.

Congratulations, you have now increased the cognitive load to be productive on your team and increased the SQL injection attack surface for your apps! I jest, but ORMs exist for a reason. And if I were a new senior or principal on your team I’d be worried that there was now an expectation for a junior to be a wizard at anything, even more so that thing being a rich and complex RDBMS toolchain that has more potential…

SQL injection is only a thing for those careless to ever allow doing screen concatenation to go through pull requests.

If it isn't using query parameters, straight rejection, no yes and buts.

Naturally if proper code review isn't a thing, than anything goes, and using an ORM won't help much either.