Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removed rust to gain speed

prisma.io

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Removed rust to gain speed

#31

Post by 9rx »

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…

Brainfuck also exists for a reason. That doesn't imply that you should use it.

Re: Removed rust to gain speed

#32

Post by AnotherGoodName »

RedShift1 wrote: post #26
AnotherGoodName wrote: post #23

Earlier quoted context omitted.

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…

Honestly database schema management doesn't scale particularly well under any framework and i've seen those issues start to crop up in every org once you have enough devs constantly changing the schema. It happens with ORMs and with raw SQL.

When that happens you really really should look into the much maligned no-sql alternatives. Similarly to the hatred ORMs get, no-sql data stores actually have some huge benefits. Especially at the point where db schema maintenance starts to break down. Ie. Who cares if someone adds a new field to the FB Newsfeed object in development when ultimately it's a key-value store fetched with graphQL queries? The only person it'll affect is the developer who added that field, no one else will even notice the new key value object unless they fetch it. There's no way to make SQL work at all at scale (scale in terms of number of devs messing with the schema) but a key-value store with graphQL works really well there.

Small orgs where you're the senior eng and can keep the schema in check on review? Use an ORM to a traditional db, escape hatch to raw SQL when needed, keep a close eye on any schema changes.

Big orgs where there's a tons of teams wanting to change things at high velocity? I have no idea how to make either SQL or ORMs work in these cases. I do know from experience how to make graphQL and a key-value store work well though and that's where the above issues happen in my experience. It's really not an ORM specific issue. I suggest going down the no-sql route in those cases.

Re: Removed rust to gain speed

#33

Post by Sytten »

ameliaquining wrote: post #12

An important part of the story here, not mentioned in this post but noted elsewhere ( https://www.prisma.io/blog/from-rust-to-typescript-a-new-cha... ), is that they gave up on offering client libraries for languages other than JavaScript/TypeScript. Doing this while mostly sharing a single implementation among all languages was much of the original reason to use Rust, because Rust is a good "lowest common denominato…

Yeah, the whole point of Prisma 2 was to be multi language and multi-DB with a Rust server in between you and the DB. There are a lot of advantages to that approach in enterprise. You can do better access control, stats, connection pooling, etc (Formal is a YC company in that space). Prisma 1 was a scala implementation of that vision.

Anyway, end of an era. There were a couple community bindings in Python and Java that are now dead I assume. I was heavily invested in Prisma around 4-5 years ago, that is funnily enough what got me started on my Rust journey.

Re: Removed rust to gain speed

#34

Post by kstrauser »

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

Meanwhile, earlier this week we had a big conversation about the skyrocketing costs of RAM. While it's technically true that GC doesn't mean a program has to hold allocations longer than the equivalent non-GC code, I've personally never seen a GC'ed program not using multiple times as much RAM.

And then you have non-GC languages like Rust where you're hypothetically managing memory yourself, in the form of keeping the borrow checker happy, you never see free()/malloc() in a developer's own code. It might as well be GC from the programmer's POV.

Re: Removed rust to gain speed

#35

Post by 9rx »

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 not sure your characterization is all that accurate.

Originally, they thought they could build a product that worked across many languages. That necessitated a "lowest common denominator" language, which is a void that has always been strangely lacking in choice, to provide an integratabtle core. Zig had only been announced a few months earlier, so it wasn't really ready to be a contender. For all intents and purposes, C, C++, and Rust were the only options.

Once the product made it to market, it became clear that the Typescript ecosystem was the only one buying in. Upon recognizing the business failure, the "multi-language" core didn't make sense anymore. It was a flawed business model that forced them into using Rust (could have been C or C++ instead, but yeah) and once they gave up on that business model they understood that it would have been better to have been written it in Typescript in the first place — and it no doubt would have been if it weren't for the lofty pie in the sky dreams of trying to make it more than the market was willing to accept. Now they got the opportunity to actually do it.

Re: Removed rust to gain speed

#36

Post by BenoitP »

theamk wrote: post #27
mwkaufma wrote: post #25

Earlier quoted context omitted.

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.

Most programs should be written in GCd languages, but not this.

Except in a few cases, GCs introduce small stop-the-world pauses. Even at 15ms pauses, it'd still be very noticeable.

Re: Removed rust to gain speed

#37

Post by 9rx »

kstrauser wrote: post #34
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).

Meanwhile, earlier this week we had a big conversation about the skyrocketing costs of RAM. While it's technically true that GC doesn't mean a program has to hold allocations longer than the equivalent non-GC code, I've personally never seen a GC'ed program not using multiple times as much RAM. And then you have non-GC languages like Rust where you're hypothetically managing memory yourself, in the form of keeping th…

> And then you have non-GC languages like Rust

Rust is a GC language: https://doc.rust-lang.org/std/rc/struct.Rc.html, https://doc.rust-lang.org/std/sync/struct.Arc.html

Re: Removed rust to gain speed

#38

Post by Ygg2 »

9rx wrote: post #37
kstrauser wrote: post #34

Earlier quoted context omitted.

Meanwhile, earlier this week we had a big conversation about the skyrocketing costs of RAM. While it's technically true that GC doesn't mean a program has to hold allocations longer than the equivalent non-GC code, I've personally never seen a GC'ed program not using multiple times as much RAM. And then you have non-GC languages like Rust where you're hypothetically managing memory yourself, in the form of keeping th…

> And then you have non-GC languages like Rust Rust is a GC language: https://doc.rust-lang.org/std/rc/struct.Rc.html , https://doc.rust-lang.org/std/sync/struct.Arc.html

By that token so is C.

GC is a very fuzzy topic, but overall trend is that a language is GC if it's opt-out of GC. Not opt-in. And more strictly, it has to be tracing GC.

Re: Removed rust to gain speed

#39

Post by 9rx »

Ygg2 wrote: post #38
9rx wrote: post #37

Earlier quoted context omitted.

> And then you have non-GC languages like Rust Rust is a GC language: https://doc.rust-lang.org/std/rc/struct.Rc.html , https://doc.rust-lang.org/std/sync/struct.Arc.html

By that token so is C. GC is a very fuzzy topic, but overall trend is that a language is GC if it's opt-out of GC. Not opt-in. And more strictly, it has to be tracing GC.

You can add your own custom GC in C — you can add your own custom anything to any language; its all just 1s and 0s at the end of the day — but it is not a feature provided by the language out of the box like in Rust. Not the same token at all. This is very different.

Re: Removed rust to gain speed

#40

Post by oskarkk »

theamk wrote: post #27
mwkaufma wrote: post #25

Earlier quoted context omitted.

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.

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

Is UI even a large part of Firefox? I imagine that the rendering engine, JS engine, networking, etc, are many times larger than UI.

Post reply on HN