Re: [go-nuts] Golang ORM Performances

If you want to avoid boilerplate and keep the lightest weight possible, you could have a look at the approach I took recently when I added SQL support in my serialization format, greenpack. See here: (only supports MariaDB/MySQL syntax at the moment) https://github.com/glycerine/greenpack?tab=re

[go-nuts] On 'go install' for plugins

For those of us that think go plugins are the most important piece of technology to come out since the sandwich toaster, being unable to 'go install' a plugin is a problem one wants to solve. Armed only with ignorance, I attacked this problem head on. Plunging directly into src/cmd/go/internal/

Re: [go-nuts] Golang ORM Performances

https://github.com/ent/ent seemed to perform well, and was quite flexible. Will On Thursday, December 19, 2024 at 7:27:46 AM UTC-8 Robert Engels wrote: > I go back and forth on ORMs. I think a lot depends on the complexity of > the project. > > Still, I wouldn’t expect the overhead of an ORM t

[go-nuts] Re: Working with release candidates

You missed go: go 1.24rc1 toolchain go1.24rc1 Go toolchain names¶ The standard Go toolchains are named go*V* where *V* is a Go version denoting a beta release, release candidate, or release. For example, go1.21rc1 and... Once you build, you can verify whic

Re: [go-nuts] Golang ORM Performances

I go back and forth on ORMs. I think a lot depends on the complexity of the project. Still, I wouldn’t expect the overhead of an ORM to be more than 1-2% for IO/db bound systems - if it is I suspect it is not properly configured and it is generating inefficient queries or the database tables lack p

Re: [go-nuts] Golang ORM Performances

Hi Bhavesh, I am also not a fan of ORMs, but I am a big fan of sqlc so I will 2nd Brian Candler's recommendation. Sqlc is one of the few Go packages/tools I consider a must-use for any of my projects that need to interact with SQL databases. -Mike > On Dec 19, 2024, at 8:23 AM, 'Brian Candle

[go-nuts] Re: Golang ORM Performances

I am not a fan of ORMs. Application performance problems are usually down to poorly formed SQL queries (and/or lack of supporting indexes), which ORMs can mask or amplify. For an alternative approach, have a look at https://github.com/sqlc-dev/sqlc In short, you write the set of SQL queries to

[go-nuts] Golang ORM Performances

I read few posts regarding ORMs in golang & realized, few peoples are not happy with it. They mentioned to use raw queries with our own wrapper if want to make few things reusable. I was actually using Gorm, which was super slow, then I started research regarding performance efficient ORMs,

[go-nuts] Working with release candidates

I'm preparing our application for go1.24, including using the tools go.mod directive. I was expecting that I should be able to require rc1 as part of the build process. However, adding go 1.24rc1 toolchain 1.24rc1 lead to either unknown block type: tool invalid toolchain version '1.24rc1': mu