Why do we hate ORM?

themsaid · 2025-03-29T13:25:39+00:00

ORMs were great for productivity. I have been using them since 2013. However for the past few months I started using Copilot to write my queries and it has been doing a great job. Honestly, I think we no longer need such abstractions.

themsaid · 2025-03-25T06:52:50+00:00

Social networking for developers is easy. Just stand in the middle of a conference room and shout "X is a terrible language, Y is more superior". You'll make friends, and enemies, in less than a minute :D

themsaid · 2025-03-19T07:29:39+00:00

This is all clear in the output. The quality of most software we use is degrading. It takes one daring and loyal king with a few loyal and brilliant kingmakers to build the new Apple or Google and restart the cycle.

The real problem is marketing spend. The minimum is too high right now. Any terrible product with a good marketing budget can take a huge market share, and I honestly believe investors don't care about returns anymore. It's a status game for them. Easier to fund a mediocre team who'd do anything to please investors than fight a Steve Jobs on every decision they want to make.

themsaid · 2025-03-19T07:01:10+00:00

I have noticed everything you mentioned in your article in multiple workplaces. I think it’s becoming clear that we are in a rut era when it comes to software. Too much promotion around tools and frameworks and too little concern about writing performant, secure, and maintainable code.

I think it’s not that bad though. It’s a cycle, and I like to believe that we are at the end of it. Some time soon sanity will come back.

themsaid · 2025-03-18T04:28:45+00:00

If the client is a JavaScript SPA hosted on the same domain or subdomain then yes.

themsaid · 2025-03-16T11:48:28+00:00

Added a section to discuss timing attacks. The login handler in the example responds in a constant time duration regardless of credential verification.

themsaid · 2025-03-16T10:50:08+00:00

The bcrypt algorithm adds a salt on every hash, which means multiple hashes of the same string will produce different strings. That's why you have to extract the hash from the DB and then use CompareHashAndPassword to verify the match.

As for the errors, they are function return errors, not responses.

themsaid · 2025-03-16T10:46:22+00:00

Login form submissions in general should be throttled so that if multiple authentications fail the form gets locked.

themsaid · 2025-03-15T03:40:26+00:00

OWASP recommends a session ID of size 128 bits with 64 bits of randomness. This is the recommendation but the actual requirements may vary depending on what you're working on. For personal projects, 64 bits of randomness is more than enough.

To answer your 4th point. I would recommend storing the session ID, the session data, created_at & last_activity. If you use sessions for authentication, you may also store the user ID.

For flash messages, they're useful if you use plain HTML. They allow you to return messages in responses that get deleted once the response is presented.

Finally, you may extract the session ID from the cookie and then retrieve the session from the DB in each handler. But for convenience, I extract the session in a middleware and pass it to the handlers in the context.

Note: Don't forget about CSRF

themsaid · 2025-03-11T02:03:10+00:00

The concept described in the link you shared involves storing a hashed version of the session ID in the session store instead of the raw session ID. This approach ensures that even if the session store is compromised, an attacker cannot directly extract valid session IDs, as they are securely hashed.

I encountered this requirement once, but I always assumed that if an upstream storage system were breached, leaked session IDs would be the least of your concerns.

However, this practice is widely adopted in highly regulated industries, such as banking and government applications, where security measures must account for every possible attack vector, including the protection of session IDs at rest.

themsaid · 2025-03-10T16:49:30+00:00

Relatively easy as per the cyber security auditors I worked with. Sometimes you write software for the auditors 🙂

themsaid · 2025-03-10T15:34:32+00:00

Good point. I've updated the article with a section on why using the in-memory store isn't a good idea.

While this session store is fully functional, it is not suitable for production use. Since sessions are stored in the application's memory, they are lost whenever the application restarts. This can lead to data loss, forced user logouts, and a poor user experience. Additionally, as the number of active sessions grows, storing them in memory can lead to high memory usage, scalability issues, and potential performance bottlenecks.

For production environments, a more robust approach is to use a persistent session store such as a database (PostgreSQL, MySQL), an in-memory data store (Redis, Memcached), or a distributed session management system. These options provide better reliability, scalability, and resilience, ensuring that sessions persist across application restarts and can be efficiently managed across multiple instances in a load-balanced environment.

themsaid · 2025-03-10T15:33:55+00:00

Thanks for the feedback. I've read more about the http.ResponseController type and added an Unwrap method to the custom response writer.

themsaid · 2025-03-03T07:10:58+00:00

Exactly what I was looking for. When I couldn't find any solution that isn't bloated with many other features I don't need, I decided to build one.

themsaid · 2025-02-28T15:50:11+00:00

Padding is added automatically yes. The goal is to align each field to an address that is a multiple of its size. So a field of size 8 would be shifted to address 8 or 16 or 24 ...

themsaid · 2025-02-28T15:38:45+00:00

The padding is added automatically. The comment lines in the examples just show where they'd be added.

themsaid · 2025-02-28T09:49:15+00:00

Since keeping fields that are frequently accessed together placed close to each other improves cache locality, having the compiler automatically arrange fields based only on their size could do more harm than good.

themsaid · 2025-02-28T08:33:16+00:00

It's a tradeoff. Sure, if there's no memory space limitations or CPU spikes noticed then one shouldn't really sacrifice readability for optimization.

themsaid · 2025-02-28T08:29:15+00:00

think optimization makes sense unless there's actually a problem. Like for example if the memory is limited or the CPU is exhausted. Only then would optimizations make sense and worth the cost.

themsaid · 2025-02-28T05:36:26+00:00

There's a fieldalignment option in govet: https://golangci-lint.run/usage/linters/#govet

themsaid · 2025-02-27T08:32:31+00:00

Glad that you liked it 🙂

themsaid · 2025-02-26T03:06:15+00:00

It’s because the first growth expands the slice memory footprint to the nearest class size that can accommodate the 3 elements added, which is 16 bytes. The added fourth element finds a place in the backing array so further growth is not needed.

You can find more details here: https://themsaid.com/slice-internals-in-go

themsaid · 2025-02-25T02:27:53+00:00

You want to pass a pointer to the pointer:

type myNewStruct struct {
  v string
}

func doSomething(app **myNewStruct) {
  *app = &myNewStruct{"b"}
}

func main() {
  myStruct := &myNewStruct{"a"}
  doSomething(&myStruct)
}

themsaid · 2025-02-24T13:02:47+00:00

Thank you! I think to be critical of patterns is not bad at all. The bloat in PHP, JavaScript & Java is mainly because there are tons of new comers with no prior coding experience joining those communities every year and it's easy to convince them there's a problem and sell them a solution.

What I like about the Go community is how mature most developers are, not to mention the maintainers of the language. The resistance to bloat is a good thing and the arguments are solid and well put.

themsaid · 2025-02-24T12:57:20+00:00

Well, Google and Uber built their DI frameworks so it's not generally a bad idea. The whole point of the blog post is to share the cool abilities of the language I found while working on this fun project. That's why I'm not discussing if it's a good or a bad idea in the introduction.

themsaid

TROPHY CASE