kflgkans

I personally believe ActiveRecord is a gigantic anti-pattern and should be avoided at all costs (by anyone, ever). And I also happen to have had very bad experiences with ORM and feel like most of the time they are not needed at all. So yes. But even if you want an ORM, there's a few popular ORM libraries. You can just include one and start using it, no need to use a framework for that (for ActiveRecord I wouldn't know).

My advice is to just use standard library `database/sql`. Every abstraction on top adds extra complexity and isn't really necessary. Just execute a query, map the results, and there you go.

> While you’re still researching the best SQL library for a project

People do this? In every language I've worked with, there's practically just one SQL library to use. And you just write a query, execute it, and map some results. Very basic.

Could you give a few examples what such frameworks provide that you need, that Go plus a few simple libraries doesn't provide?

> If I want an all inclusive MVC (or similar) web development framework with all batteries included

I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just get in the way.

You might not need a cache. In my previous company (~7 years) all teams around me were introducing caches left and right and getting into a lot of complexity and bugs. I persevered and always pushed back adding caches to apps in my team. Instead focusing on improving the architecture and seeking other performance improvements. I can proudly say my teams have stayed cached-free for those 7 years.

What does integrated with KDE mean? I use Firefox, but cannot imagine any type of integration that I really need.

> That looks like more XSS vectors.

Could you elaborate on that? I don't understand how this leads to more XSS vectors.

You're mistaken. This is no joke.

Was it your intention that the dancing stick figure gives people nightmares?

stick is life

I forgot to follow up on this, I don't know how to make HN give me some kind of a notification on replies to my comments.

I should have been a bit more clear. I love memory safety. But I dislike a lot of other aspects specific to Rust. I would much prefer e.g. C with memory safety (somehow). So that is, for me, why not Rust. Rust is more more than just memory safety.

Last I checked WASM applications are single threaded, not sure if that's changed. GC is concurrent, but not parallelized.

Zig is a completely different language than Rust. Memory safety is just one aspect. I personally find Rust to be very difficult to read and can never manage to be productive in it.

Thanks, that makes sense. Interesting perspective on the UI = F(data), I did not know that. I still wish the mechanics were a bit more... intuitive... I guess? Personally, I'm a big fan of The Elm Architecture [1]. I felt that is a very nice way to separate state and logic. But I'm not such a big fan of Elm itself (subjectively).

[1] https://guide.elm-lang.org/architecture/

Thanks for the additional clarification!

The most common pattern in languages with explicit error handling, is to simply return the error (possibly with some context added) in every function up to the point where the process was started (e.g. an HTTP endpoint handler, or the CLI's main function) to deal with it.

I'm not saying exceptions are good, but I am saying that they do represent the most common error handling pattern.

If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me.

Up until roughly 4-5 years ago I was doing small front-end React apps on the side (I'm a backend engineer) and was feeling very productive with class components. They made sense to me, concerns were nicely separated, and I felt I could reason pretty well about what was called when and how state was manipulated.

Then hooks came around, I tried them a few times, but I just felt so lost. Suddenly everything is intermingled in one function and we're using side effects to react to changes and manipulate state. I could no longer understand when which code was executed, and especially following and manipulating state became impossible for me.

The projects I already, I kept with class components. Haven't done any new front-end projects since then.

Sounds very familiar. I was a Java developer for a long time, and in that ecosystem adding a library to your project can be enough for code to be activated and run. There are plenty of libraries where the idea is: just include it, magic stuff will happen, and everything works! That is, until it doesn't work. And then you have to try and debug all this magic stuff of how Java automatically loads classes, how these classes are created and run, and what they do. Didn't happen very often, but when it happened usually a full week was wasted with this.

I really prefer spending a bit more time to set it up myself (and learn something about what I'm using in the process) and knowing how it works, than all the implicit magic.

I like explicit over implicit. I will take passing down context (in the sense of the concept, not the specific Go implementation) explicitly everywhere over implicit ("put it somewhere and I'll trust I can [probably, hopefully] get it back later") any day of the week.

I've seen plenty of issues in Java codebases where there was an assumption some item was in the Thread Local storage (e.g. to add some context to a log statement or metric) and it just wasn't there (mostly because code switched to a different thread, sometimes due to a "refactor" where stuff was renamed in one place but not in another).

If it is just a transport mechanism, why use context at all ant not a typed struct?

I think it's simply survivorship bias. Thousands of people try this and fail. And occasionally you read an article like this, which is like the one in a million who managed to get lucky with their ideas and manage to make it a success. And I think they underestimate how much luck they had.