GORM VS bun

Hello, I want to communicate with a database in my go API. My API is for a website that allows you to track finances and budgets, so the reason I need a database is to store the user's expenses and allow them to search and find each one and which one is costing them the most. I also am going to implement login soon, but I don't think that matters for now. I'm now stuck on how to communicate with my database (Postgres). Should I go with an ORM like gorm, database/sql package, sqlx, or any others? Advice is appreciated

For more information on Gorm's operation of MySQL, please refer to Gorm

To access PlanetScale, we can use ORM from Go called Gorm, and since the PlanetScale database is built on top Vitess (MySQL), install the MySQL driver as well.

Just my opinion, so it it for what it’s worth to you, but I haven’t been especially impressed with the ORM landscape in Go. I have tinkered with a few ORMs - I gave gorm a serious whirl a few months ago, but ended up ditching it in less than a month. If time is on your side, I’d strongly encourage you to experiment with what the standard library’s database/sql package has to offer.

If it is to low-level for your liking maybe take a look at sqlx or even gorm.

Sigh... If you're using gorm V2, you need to pass a dialector to gorm.Open as the first parameter. See the V2 example here: https://github.com/go-gorm/gorm/issues/3565

Framework - Gin ORM - Gorm

You could try running the current code in bun.sh instead of `node` or `deno` and check out how many concurrent requests it can process. You should have perf improvements right out of the box.

When you look at the current web ecosystem, you'll see players like Deno, Bun, Qwik all pushing the frontier on performance in their own domain.

Is your sense also that this is the root cause of Bun's outstanding speed? Node.js is written in C++ which also requires low-level control over memory.

Is there something about C++ that makes it less well-suited for what Bun does than Zig?

Or is the problem with Node.js that it relies too much on JavaScript and Python alongside C++ in hot paths?[2]

[1] https://bun.sh/

[2] https://github.com/nodejs/node

Not yet. MongoDB requires resolving SRV dns records and we haven't implemented support for that yet (just A/AAAA via geraddrinfo()-like APIs currently)

Tracking issue: https://github.com/oven-sh/bun/issues/1822

Please add musl build here:

https://github.com/oven-sh/bun/releases/expanded_assets/bun-...

Little disappointing that he points out/measures a huge source of slowness, but unfortunately we can't really do anything about it (for valid reasons, he points out the tool fragmentation, etc).

Originally, I was hoping that "fast module resolution of huge projects" is something that Deno would have solved from day 1 when they said "meh we don't need npm" and had the opportunity to clean-slate the design. Granted, they do support npm now, but personally I think they only had to back-peddle because their non-npm approach didn't have any huge advantages (i.e. perf wise) for most users to bother with.

Like if Deno had fixed this "30% module resolution overhead for large test suites / app startups" when it first came out, I would have gotten our app on to it immediately.

IANAE / I haven' tried it yet, but I believe bun's `bun bun` command is the best (only?) innovation trying to tackle this problem:

https://github.com/oven-sh/bun#bun-bun

I really should it try, my hope is that it's the "I am _immediately_ moving to bun" carrot that Deno never delivered.

I've recently been working on a little personal finance app as a way of learning and experimenting with Bun and SolidJS.

Bun: support Fetch out-of-the-box

Although Bun is called experimental software even by its creators and is currently available in a public beta version, it has sparked great interest among developers. The GitHub repository of the project has already received 37k stars!