News for hackers. Stuff that matters.

jayy-lmao

This looks really cool!

Have always wanted to dip my toe in EventStoreDB/Kurrent but this looks super intuitive and nice to use. Especially like the js projections, can imagine it being really handy in prototyping or ad-hoc reporting.

Re:Better Error Handling on Monday April 21, 2025 @04:58AM (#43749747)
Nice thing about Monads in JS with tools like neverthrow is that you can create the Monad boundary where you like.

It becomes very similar to try-catch exception handling at the place you draw the boundary, then within the boundary it’s monad land.

If you haven’t wrapped it in a monad, chances are you wouldn’t have wrapped it in a try-catch either!

About a week ago I was thinking about how much something like this is needed in Rust. Especially something web-framework and DB agnostic.

Great work, I’m sure this will save numerous dev-hours

Re:Toasty, an Async ORM for Rust on Saturday November 02, 2024 @09:19PM (#42030516)
But late but I saw this comment and it really spoke to me. I couldn’t agree more.

I have the afternoons of my past week trialling to see if you could achieve something similar to Toasty with just structs and proc macros.

https://github.com/jayy-lmao/sql-db-set-macros

Still WIP but made it past the hurdle of inserts, which I decided to generate a type-state builder pattern to enforce non-nullable fields and skip auto-fields. This is more intended as a proof of concept but I’ll see how much I can grow it and whether I can dogfood at my job

Show HN: I made a CLI tool to generate Rust SQLX models/queries from migrations

https://github.com/jayy-lmao/sql-gen

Still very much a work in progress. But with Testcontainers I've been able to do what I always dreamed of doing with pg-embed in supporting model generation from SQL migrations.- Generate Rust structs and sqlx queries for PostgreSQL database tables or from migrations via a Postgres test container- Queries for a Model Set easily extendable with regular sqlx.- Generate SQL migrations based on...

( Read More... | no comments | on HN )
Re:Show HN: REST Alternative to GraphQL and tRPC on Tuesday October 10, 2023 @08:48AM (#37831374)
After looking at tRPC, and having done a lot in a few jobs with GraphQL codegen & gRPC codegen, I always wondered why there were so few recent OpenAPI based codegen/client-server-contract tools. I think I was searching for this exact tool.

Love that it makes the client somewhat backend agnostic, but the tools for the OpenAPI backend also look great.

Thank you for this, I hope it is successful in achieving some adoption!

Without a doubt DBeaver!

PgAdmin never got me out of the psql terminal but DBeaver has been a pleasure to use

I sure hope this is the unit of measurement and not a Berserk reference
Re:From Erlang to Lunatic on Saturday February 18, 2023 @04:30PM (#34851305)
I’ve got to disagree a little. Revealing my bias: I’m a former TS full stack who now works full time in a company that uses Rust on the backend (not my choice). I’ve done so for over a year now.

I find it’s a bit like C# in some ways, especially it’s ability to scale the codebase. Code navigation is incredibly clear and the libraries have been great. The experience of using async-graphql and sqlx is unbelievably intuitive.

For the bad: the compilation times can still be a little slow (especially in CI). This sometimes makes dev a just slightly awkward. I’ve had to contribute to a couple of libraries we depend on because they are still quite young, and we’ve had to move web framework once. Hiring might also be a slight challenge.

I’m not sure if I’d necessarily pick it again if I was to choose for a small business again - but frankly using it has still been a pleasure and the ecosystem is only feeling better.

Re:Ask HN: What is your favorite Tech Podcasts these days? on Friday January 20, 2023 @06:14AM (#34451522)
Shout out to Unruly Software! Love these guys.

Australian dev duo. Casual conversations around web dev, mostly the experiences of the hosts over the last month or so. Informative but relaxed.

10/10 parasocial relationship

Re:Rust concepts I wish I learned earlier on Wednesday January 18, 2023 @03:19PM (#34432450)
Personally I’ve done a small amount of reading of the Hands On Functional Programming in Rust book. I’ve also found Scott Wlaschin’s F# resources quite transferable (though you may run into some issues with passing async functions around as arguments).
Re:Rust concepts I wish I learned earlier on Wednesday January 18, 2023 @03:17PM (#34432418)
Full time Rust web dev here (have been so for about a year).

Feature delivery was slow to start due to familiarity with the language, the business domain, and the project. Now that the patterns within our project have been established (EDA, Vertical Slice, some DDD for those interested) it’s actually proving quite easy to work on.

Have been a ts dev in a past life, and while I wouldn’t necessarily reach for Rust for future green fields it has been quite pleasing to work with for the last year.

Re:Books for Software Engineers in 2023 on Monday January 02, 2023 @11:05PM (#34227527)
Love the mention of Zero to Production in Rust. Have read a few Rust textbooks at this stage and this one felt the most practical for my 9 to 5.
Re:How to get started with Rust for Web Dev on Monday September 19, 2022 @10:10AM (#32898558)
Full time Rust dev here (For only about ~10m, before that hobby Rust dev). Used to be a full time ts dev.

Others mention the smoothness of Serde. I also really enjoy using sqlx, and the wider tooling and crate documentation makes it a pleasure.

I do really miss the compilation speeds of ts, and even with a lot of fiddling it’s hard to get close to but the borrow checker and dev speed has almost caught up at this point if it wasn’t for the compile times. CI/CD still 5-8 minutes for us even with a lot of caching etc. Lack of enterprise resources is also a little tough though I find C# and F# resources good analogues.

Perhaps my favourite little benefit which I really regret being without on ts services is the ability to clone a repo and then use your own copy as the crate. Allows a lot of debugging power, and allows you to run with your own patches while they’re still getting accepted into the crate. Honestly my favourite feature of crates.

Would I use Rust if I had to start a business from scratch? Maybe. I joke with a friend I’d probably prototype microservices in TS then migrate the high traffic ones to Rust. The memory footprint is great but rarely a business requirement. The volume it can handle might be?

Re:Can anyone recommend event-driven architecture book? on Saturday September 03, 2022 @07:38PM (#32707671)
This book made a lot of things click for me.

External (inter-domain) vs internal (domain) events was super useful to understand.

If you’re trying some idealised event driven architecture I feel this book, and later either Domain Modelling Made Functional (F#) or Domain Driven Design with .NET core could be of use (though this definitely does enough detail on its own).

I think the external events imho are the only must have though. Within the micro service or domain I don’t think event driven is necessarily cleaner or easier Vertical Slice, Clean/Onion, or even layered.

At my work we're building a system to train healthcare professionals.

Instead of using ML to diagnose, we are treating the student as the AI. They're given chatbots which they must treat and diagnose. Fortunately for us clinical sessions usually follow a formula, and so make for a good case for chatbots. (We're called SimConverse in case anyone is interested)

Re:Ask HN: How has GraphQL panned out for your organization? on Saturday September 11, 2021 @04:17AM (#28490297)
Oh and also: If you use typescript in the frontend GQL codegen is super simple to set up and can type all your queries
Re:Ask HN: How has GraphQL panned out for your organization? on Saturday September 11, 2021 @04:14AM (#28490290)
That sounds a lot like our experience. We use GraphQL as a gateway to like 20 different rest endpoints. Places where we have hammered an underlying endpoint are _usually_ places where we would have done so from the client or SSR instead. We do also have all these talking within an internal network which is a huge help.

Have also done Rust and really enjoyed GQL in it, both as hobby and "innovation projects" at work. Feels good.

WRT CDN Caching: Akamai has a pretty good GraphQL caching module that can also do POST requests. Cache directives are marvellous. I'd like to see explore the "private" directive to see if it disables certain queries from being cached.

Really excited to follow this project. Full stack who loves writing Rust, feeling this could be a really neat symphony of technologies. Was actually just going down a rabbit-hole on BEAM and Lunatic yesterday, so this really scratched my itch.

I saw a bunch of stuff on SSVM and their impressive WASM VM performance [0]. Wondering if this can be of any benefit to Lunatic?

Furthermore, would be really interested in seeing getting started guides / examples / maybe even some tutorial articles on an example or two. This could really help adoption if thats the goal.

[0] https://www.secondstate.io/articles/ssvm-performance/

Re:Rust is a hard way to make a web API on Friday January 15, 2021 @07:30PM (#25798576)
I can agree with some of this up to a point. The stuff about compiler slowness is nothing new, and I will happily admit its one of my pain points for working in Rust.

However for getting c++ish performance for a relatively high level syntax I think this fills a different niche than GC'd alternatives. The web-server libraries are still evolving, and I too would love to see a few crates designed for handling auth.

A lot of the issues with difficulty writing/safe practice will just improve once there's more examples/books/tutorials. It takes a little for this stuff to catch up.

Finally I really struggle to see the point about dataloaders - they may be a little confronting initially but its the same thing you often have to do in Nodejs. There's public examples on Github of how to use them with both Juniper and Async-Graphql.

I can understand a lot of this as "its just not there yet". Rust has a much smaller community than Golang/Python/Js, I think its understandable if its taking a little longer to have equivalents in tooling etc. I still enjoy writing it

Re:Tokio 1.0 – async runtime for Rust on Wednesday December 23, 2020 @07:21PM (#25523874)
I've got a few examples of simple web servers within my company, could backport some of it to a public example. Are you just looking to have something a bit like: ``` #[get('/todo')] async fn getTodos(...) -> impl Responder { let todos = reqwest.get('other-api/todos').await?;

  todos
} ```

Obviously this code won't run, just want to gleam the gist of what you want from an example.