31–40 of 43 posts
Earlier quoted context omitted.
What language will it be _next_ year?
Seeing how Rust is consistently at the top of Stack Overflow's most loved languages, I'd wager it's gonna be Rust again.
Over last decade and a half it's been: Ruby -> Node.js -> Go - > Rust and something new will come along. But just like others on the list, they will all live and evolve together.
Earlier quoted context omitted.
Prisma engineer here who's been part of the rewrite since the beginning. We tried GraalVM, but the binary size was huge and we anyways needed to write parts, such as the JDBC drivers in Rust, C or C++ due to GraalVM not being able to compile certain JVM code to a native binary. We distribute the binary with our NodeJS package and hundreds of megabytes of binary size will not work that well for our users.
Oh! That's a valid reason; I'm actually surprised that GraalVM has issues not supporting JVM features, since I've been using it for Clojure code locally (though admittedly just for fun, nothing serious). Definitely makes sense if you're stuck rewriting things anyway, might as well just do it in a more modern language. Thanks for the insight!
What we did in the end is we rewrote parts of the system with Rust, plugged that to the JVM package and we had all our tests ready to use. First the database connectors and at the same time the other part of the team was writing the graphql parsing in Rust. We could all utilize our Scala integration tests which was crucial for our success.
And btw. we still have our tests in JVM, although the rest of the stack is Rust now.
We did a similar thing with a Scala -> Rust rewrite for the http://prisma.io query engine. By rewriting small components and integrating them into the existing project using Javas native interface, our small team of 5 developers were able to pull off this massive rewrite in just under a year. The resulting code base is rearchitected in a few very important ways, but mostly follows the same structure. And because we k…
How many lines of code? (old/new)
And the old Scala codebase here: https://github.com/prisma/prisma/
The old codebase has parts in Rust, so counting the lines is not that straightforward.
Earlier quoted context omitted.
Seeing how Rust is consistently at the top of Stack Overflow's most loved languages, I'd wager it's gonna be Rust again.
Next year is not literally next year. Over last decade and a half it's been: Ruby -> Node.js -> Go - > Rust and something new will come along. But just like others on the list, they will all live and evolve together.
Earlier quoted context omitted.
Seeing how Rust is consistently at the top of Stack Overflow's most loved languages, I'd wager it's gonna be Rust again.
Next year is not literally next year. Over last decade and a half it's been: Ruby -> Node.js -> Go - > Rust and something new will come along. But just like others on the list, they will all live and evolve together.
Earlier quoted context omitted.
I promise that this is asked genuinely and isn't some sort of veiled "gotcha!" (it's tough to tell on the internet sometimes); what was the reason for a change from Scala to Rust? I ask because Scala already has a good type system and the JVM typically has good performance nowadays, particularly with something like GraalVM, so I am actually really curious to why you felt a Rust rewrite was a good idea.
Just some reason I might make a switch from Java/C# to Rust: * you can keep memory use quite a bit lower * you can still sometimes get large constant factors of performance improvements over the JVM in some kinds of problem domains. If this means you can run on 1 server instead of say, 5, you have a much simpler infrastructure. * startup time, especially if you are doing 'serverless' or similar * tail latency - even…
On the long pauses, I've built simulation server systems for multi-user in .Net and the stop the world GC for several seconds now and then was very painful practically speaking.
> However, Rust has a killer feature when it comes to this sort of thing. It can call into C code with no overhead (i.e. the runtime doesn’t need to inject automatic marshalling like C#’s P/Invoke) and it can expose functions which can be consumed by C just like any other C function. As we see below, you may still need to write some code to convert from C types to something that is more ergonomic to use in Rust. But…
Exactly, as much as I love writing Rust code, there is nothing that is more frustrating that maintaining bindings from C to Rust. Then you'd have to create another idiomatic binding on top of it. Sure bindgen is great, but Zig's cImport and Swift's ClangImporter take this further.
They both use clang modules to tackle the first part. A autogenerated idiomatic solution would be great for Rust, but sadly it doesn't exist.
> However, Rust has a killer feature when it comes to this sort of thing. It can call into C code with no overhead (i.e. the runtime doesn’t need to inject automatic marshalling like C#’s P/Invoke) and it can expose functions which can be consumed by C just like any other C function. As we see below, you may still need to write some code to convert from C types to something that is more ergonomic to use in Rust. But…
> As we see below, you may still need to write some code to convert from C types to something that is more ergonomic to use in Rust. But the marshaling ABI-wise is minimal. Exactly, as much as I love writing Rust code, there is nothing that is more frustrating that maintaining bindings from C to Rust. Then you'd have to create another idiomatic binding on top of it. Sure bindgen is great, but Zig's cImport and Swift'…
Earlier quoted context omitted.
I agree with all of your points except the "startup time" and "easier deployment"; GraalVM is pretty sweet and produces nice, self-contained executables.
Prisma engineer here who's been part of the rewrite since the beginning. We tried GraalVM, but the binary size was huge and we anyways needed to write parts, such as the JDBC drivers in Rust, C or C++ due to GraalVM not being able to compile certain JVM code to a native binary. We distribute the binary with our NodeJS package and hundreds of megabytes of binary size will not work that well for our users.