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.
"Every abstraction on top adds extra complexity and isn't really necessary"
This. In my experience, every project that has non-trivial query requirements starts out as "this ORM is nice, it takes away 90% of my work" and ends with "how do I get rid of that leaky abstraction layer that constantly makes my life harder."
> 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.
Come on, that’s not what you really do, but an oversimplification that skimps on the actually hard parts.
You manage (as few as possible) connections to a DBMS, create prepared statements, cache and transform results, lazily iterate over large result sets, batch writes, manage schema migrations, and more. It’s not very basic, unless you’re cobbling up a prototype.
> In every language I've worked with, there's practically just one SQL library to use.
Curious which languages that were. In practically all ecosystems I know, there are 2-4 contenders.
Same reason IDEs — when you really know them — allow for quicker development compared to using primitive text editors with a bunch of third-party plugins duck-taped together. When you understand the framework, everything is written to the same standard, behaves in similar ways, and is where you expect it to be. Adding things like background job processing requires changing one line of config.
Also, one major thing I'm missing personally is automatically generated OpenAPI specifications + API documentation & API clients autogenerated from it. Last time I checked Go, you had to write the spec manually, which is just ridiculous — the code already has all the necessary info, and duplicating that effort is time-consuming and error-prone (the spec says one thing, the code does another). This may be out of date, but if it still isn't, it is enough to disqualify the stack completely for me.
Also, I don't think there anything similar in the Go world to these administration panels:
I get wanting to be productive and gravitating towards patterns you’re familiar with but in the end it’s all bloat. http can do routing and patterns and cookies and sessions. database/sql can do your DAL work. uuid (various implementations) work for user/tenant uid+oid obfuscation. JWT libs for auth. You can literally json.unmarshal your config for your whole application or use godotenv to use environment variables. template/html for views. Golang has batteries, it’s just you don’t know what you don’t know so you expect a certain perspective that isn’t how we do things. Like joining a new company, things are different here. If you spent some time to learn the “go way” you’d realize that you don’t need the bloat, you just need the structure. The “where I expect it”.
It depends on the framework and other stuff around it but you're right about the API documentation issue, there's godoc if you want to document functions but for something like API endpoints it's not what you'd find from openapi/swagger unless whatever you're using is adaptable to that and then whenever I was working with it an older spec of it too. Always fun to run into a client who expects this from working with most of their people and you're just drooling like a gopher at them but for now if you're writing something in go for pure performance I'm not 100 on what balances best between that and auto spec... Definitely choose an API framework in go that works out of the box for that if it's important. This may be better than when I tried it a couple years back
> automatically generated OpenAPI specifications + API documentation
I'd much rather have engineers write OpenAPI specification files by hand and then generate their server code from that file. Way easier to maintain and actually forces devs to have good documentation for their APIs.
I think it's the issues in "Go plus a few simple libraries". Frameworks come with all the extra features built in. If I need rate limiting, I can just open rate limiting docs and add it to my route, there is no need to search some library or blog post on the "best way" to implement rate limiting middleware in go.
It's a long list. It might be more productive to start with just one example: OpenAPI validation.
In large orgs with customer-facing APIs, it's imperative that you can validate and enforce OAS specifications against all routes. Customers need to know exactly what auth mechanisms they can use and shouldn't be enabled to call undocumented capabilities. It's also important from a practical perspective that developers can scaffold up new routes that are always-already bound to a specification. Depending on the context you either need to do "contract first" specification or "code first" generation based on type system introspection.
Go can let you knock something together yourself but as your team gets larger, the overhead of reviewing and marshaling your team's practices gets more and more difficult.
It's like the problem you have with NodeJS. It's very possible to assemble something that has easy to scaffold routes with strong type-to-spec validation, authn/z, no exposure of undocumented APIs. But without something like NestJS or Adonis each project becomes a special snowflake with no support for interop across repositories.
I want to write `framework init` or something like that and get the whole scaffolding done for me so that I can focus on business logic. I don't want to waste time integrating auth, OTEL logging/tracing/monitoring, SQL dynamic query building, parsing & validation, config management, i18n, unit/integration/e2e testing, routing, http/ws/grpc support, openapi generation, A/B testing, task queuing, background jobs, cron jobs, request control (deadlines, rate limiting, health checks), database migrations, live reloading.
I love that I at my workplace I can use a service template that wires everything together. And I don't understand why people want to do boring solved tasks over and over again.
> 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.
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).
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.
* The KDE system for network protocols ist called KIO. KParts is for user interface components.
AFAIK, Falkon isn't using KIO because QtWebEngine has no extension points for that (and if it did, somebody would need to write HTTP2 and HTTP3 implementations or Qt wrappers for KIO).
Yeah Falkon is not using KIO. Same for Konqueror for network request. In the old time of QtWebkit and even older time of KHTML, the webview would reuse the Qt network stack, but now it's reusing the implementation from Chromium.
Btw KIO is now using QtNetwork for it's http implementation, instead of having it's own. So http2 is now also supported.
Not really. You can use XDG portals to have native dialogues in Firefox, but GTK developers call this an abuse of portals, so this will go away at some point. Portals are intended as a way out of sandboxes like flatpack, not to plug-and-play file picker dialogues.
Wow, I'm not keeping up with all the new developments in the Linux desktop land, but that surely sounds like a step back.
So let's say I'm building an app like Blender or Reaper - I'm sidestepping the need for most of the OS-specific/native-widget components, because I already need to do a whole lot of very complex and custom rendering, and that is the saner choice when going for portability. But I would still like to maintain a certain level of basic OS integration, for example a native menu bar on macOS, matching the light/dark theme with the OS, or perhaps... a native file picker?
What are my choices on Linux? Link with Gtk, and make the app look out of place on KDE? Link with KDE, and pull in half of it with me when installed on Gnome? Link both? Summon Cthulhu?...
Sounds like we've had a solution for a moment, and now we want to remove it, because think of the yaks?
If you use Qt the framework does its best to make sure the native thing will be used where appropriate. QtCore, Gui and Widgets is like 15 megabytes total and that will already allow 90% of Qt apps to run. A bazillion packages being installed if you want to install one Qt app is just the fault of your distro's policies on how software should be distributed
Yeah, about that... fracturing at every possible level.
- Linux vs Free/Open/Net/Dragonfly BSD
- Linux distro 1 vs X vs A vs Ω vs ...
- glibc (with all its warts like versioned symbols) vs musl vs BSD libc
- systemd vs sysvinit vs rc vs OpenRC vs daemontools/s6/runit/...
- Who "owns" /etc/resolv.conf?
- apt vs (yum / dnf) vs pacman vs apk vs xbps vs emerge vs ...
- Flatpak vs Snap vs AppImage
- X11 (and libx11 vs xcb) vs Wayland (which protocols/extensions are supported?)
- OSS vs ALSA vs PulseAudio vs Pipewire vs sndiod vs ...
- Gtk (2/3/4) (with Gnome or without) vs Qt (with KDE or without) vs Tk vs direct X11 vs SDL/glfw/... vs an obscure toolkit last updated 15 years ago
inb4 it's about choice, the heck I'm supposed to choose as an app developer? inb4 "follow the standard", half of these are not standardised but still in widespread use? inb4 distro policies, which distro - top 10 on distrowatch looks like more work than macOS+Windows combined? Delegate to package maintainers, and my app is "fixed"/patched beyond me being able to debug/support? I choose what seems to work (for example, escaping via the XDG portal) and I'm getting rug-pulled?
As an app developer, I ship an appimage and a flatpak based on Qt and things generally work as expected. Supporting macOS which drops compatibility with random things every other version all while providing a super old Clang is in practice much more painful.
Do you have a reference for this portal going away? I was really happy that work was being done in that area, and was optimistic that even Java apps might get sane file pickers in the future...sigh.
With kdeconnect when I have some sound playing in firefox, e.g. a youtube video, I get audio controls directly from my phone. There's a million features, check it out here: https://kdeconnect.kde.org/
KDE has integration with Firefox/Chromium too, via plasma-browser-integration. You can search browser tabs and history via the KDE menus, and share URLs with KDE via the browser context menu.
Firefox is GTK-based. With all its UI garbage like disappearing menus, CANCEL-OK dialogs (normal for Mac users), disrespect for system themes/styles/fonts, etc.
I also started using Falkon, but it still lacks too much for me, unfortuantely. And I wish it could import all history too. (
It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).
