That's what I actually used to fix this one! I'm not too deep into the JVM ecosystem, so I gave Claude a try just in case... and it fixed it :)
Btw I didn't mention it in the blog post, because I think that would have derailed the conversation (after all, the point of the article is not "use LLMs", but "fix your tools"). In any case, I agree that LLMs can make it easier to fix the tools without getting side-tracked.
hey, the idea of Krossover is actually dope! my sole question is, why does it exist?
I understand that one might call Rust from Kotlin for performance reasons (I do that often, Mozilla does, some others too), but Kotlin from Rust? where would it be useful?
Calling Kotlin from Rust (and other languages) is useful when you want access to an existing Kotlin codebase and would rather avoid creating a full-blown port. I guess most people don't do things like this because creating bindings for languages that are not C (or C-like) is usually cumbersome. Krossover is trying to fill that gap for Kotlin. Does that make sense?
I'm still curious about case studies. I can imagine that something has SDK for Kotlin but not for Rust, yet outside of that case, technical benefits are not yet obvious to me.
I'm a heavy Rust user and fan, but I'd never pick Rust for web. There are way more mature ecosystems out there to choose from. Why would you waste "innovation tokens" in a Rust-based web application?
I enjoyed using Rust/WASM for a web application I made. Once I got the build step figured out, which took a week, the application worked like I wanted right away.
I was trying to build an HTML generator in Rust and got pretty far, but I don't think I'll ever be happy with the API unless I learn some pretty crazy macro stuff, which I don't want. For the latter project, the "innovation tokens" really rings true for me, I spent months on the HTML gen for not much benefit.
For a web backend? Rust is pretty mature there, it doesn't even feel like an innovation token - it's by my favorite thing to use Rust for.
You have very mature webservers, asyncio, ORMs, auth, etc., it's very easy to write, and the type safety helps a ton.
In 2020 it might have taken some innovation tokens, but the only things that require a ton less (for web backend) are probably Java, python, and node.js, and they all have their unique pain points that it doesn't seem at all crazy?
It's been a while since I last had a detailed look at web applications in Rust (i.e., stuff with databases, auth, etc). You could use axum for the web server, which is very mature, but I'd say it's too low-level (IIRC you cannot even generate an OpenAPI spec of your endpoints, which IMO is table-stakes). Have you found something more batteries-included, with a similar level of maturity, and actively maintained by a community you can trust? It's a very high bar.
Your reply made me curious about ORMs, btw. Which one would you recommend? Maybe things have improved since I last checked. Last time I didn't like any of them and ended up settling on `sqlx` + hand-written SQL (the code is open source, hosted at https://github.com/rustls/rustls-bench-app/tree/main/ci-benc...).
I love Diesel for ORMs - it's very much in the same spirit as a type safe sqlalchemy, so it depends if you like that. The type safety is a great feature, it always saves me from writing incorrect queries (a huge one is nullability is represented as an option, so nullability mismatches are caught very early). It has an async version that is not as well maintained so it does lag behind, but I've never had an issue with it. To me personally, the Diesel ORM is the #1 reason to be using Rust for a web backend - it has saved me so much pain from having db/model mismatches since they're caught early.
The only other thing I've heard that is close in any language is C#/F# LINQ (I mean I'm sure there's random other projects, but haven't talked to other people about actually deploying backends with similarly type safe ORMs other than that).
And of course, I personally find cargo and the dependencies there to be roughly as ergonomic as python. Its dependency ecosystem for web isn't as deep as python or node.js, but it's pretty solid IMO. It may not have downloadable clients for a lot of pre-existing OpenAPIs etc., but that's also something Claude can port in 5 minutes.
Upon reflection, my comfort with sqlalchemy, diesel, C++ STL, and vibe coding all share one thing in common - I am pretty comfortable liking to code at a high level that is productive, while at the same time going deep to know what the abstractions produce under the covers. E.g. I at least spot check my vibe coded code, I spot check the assembly from C++ STL to ensure zero cost abstraction, I spot check the SQL from sqlalchemy or Diesel.
I am thinking a lot of people are not comfortable with this.
Personally, super high level abstractions where I do know what ultimately results is personally what I want to be productive - so this may color my love of Rust, vibe coding, and Diesel.
Thanks for taking the time! I love being able to see through abstractions too, but for web applications I'm looking for a bit more "magic" (e.g., .NET's EF Core is the gold standard for what I'd look for in an ORM).
I've over the years began to interface with a lot of PHP code and there's a lot of really neat configuration stuff you can do. Ex. creating different pools for the incoming requests (so logged out users or slow pages are handled by the same pool). Like it seems to me for all of the rust web servers you have to still do a lot of stuff all on your own through code and it's not like you can create an existing Pool-ing struct.
I don't think it probably helps with a lot of the super easy stuff like creating a pool with a line of configuration - fair!
I (personally) would rather spend the fixed several hours of doing a few things like that manually, vs. pounding my head on the desk for impossible-to-find bugs.
I think there's a couple stories of people shipping some performant "webapp"-y stuff in Rust... but of course you can just compile those kinds of components and write the rest of your app in any other system
I for one am glad there is a commercial angle to the project. Done right, it means more hours could go into making things better, in a sustainable way. Also, having paying users provides a strong incentive to keep the technology grounded / practical.
Without the commercial stuff, Unison would be just another esolang to me. Now I'm probably going to play with it in upcoming side projects.
> by the time there are only a few relay satellites around a planet.
Based on the limited information I have, I think it will take decades (at least) to get there for most planets. Hopefully the results of this research will be useful for a long time.
I use `jsonata` currently at work. I think it's excellent. There's even a limited-functionality rustlib (https://github.com/Stedi/jsonata-rs). What I particularly like about `jsonata` is its support for variables, they're super useful in a pinch when a pure expression becomes ugly or unwieldy or redundant. It also lets you "bring your own functions", which lets you do things like:
```
$sum($myArrayExtractor($.context))
```
where `$myArrayExtractor` is your custom code.
---
Re: "how did it go"
We had a situation where we needed to generate EDI from json objects, which routinely required us to make small tweaks to data, combine data, loop over data, etc. JSONata provided a backend framework for data transformations that reduced the scope and complexity of the project drastically.
I think JSONata is an excellent fit for situations where companies need to do data transforms, for example when it's for the sake of integrations from 3rd-party sources; all the data is there, it just needs to be mapped. Instead of having potentially buggy code as integration, you can have a pseudo-declarative jsonata spec that describes the transform for each integration source, and then just keep a single unified "JSONata runner" as the integration handler.
It's nice because we can just put the JSONata expression into a db field, and so you can have arbitrary data transforms for different customers for different data structures coming or going, and they can be set up just by editing the expression via the site, without having to worry about sandboxing it (other than resource exhaustion for recursive loops). It really sped up the iteration process for configuring transforms.
Btw I didn't mention it in the blog post, because I think that would have derailed the conversation (after all, the point of the article is not "use LLMs", but "fix your tools"). In any case, I agree that LLMs can make it easier to fix the tools without getting side-tracked.
reply