I don't think it's always as simple as that. Some wrongs are more important than others. The little wrongs, wouldn't be worth that mark on your career as being seen as unreliable, other wrongs would be worth it.
I would love to self host, but the time and effort I would have to put into doing, maintaining, and convincing my spouse (which is a whole effort by itself) is so significant it will take away from my other goals in life.
It's a stable and well proven technology that still has a lot of developer activity. Businesses are trying to make money, not explore technology, so a lot of them don't want to bother risking deliverables on something they may not have experience with.
I'm curious why there isn't a push for more support in desktop gui for Go.
Is it because desktop gui is not as supported in modern times and Go is a recent language that is carrying that attitude or is it because Go attracts more web developers in general and they already have web applications as their solution for a gui?
In my opinion, there may be two types of problems.
The first is organizational. Maintaining a cross-platform GUI library takes a lot of time, effort, and reasonable knowledge of the platforms it targets, so that would need a dedicated team of at least a few people. Which is not impossible, but you need to actually do this. The closest thing to such project seems to be Gio, but I haven't tried it, so I don't know if it's any good.
The second is technological. Most ways of interacting with (native) GUIs involve FFI, and in particular C. And cgo has known limitations and performance issues, to say nothing about the fact that using cgo make cross-compilation significantly harder. So a lot of Go projects tend to just avoid any project that involves cgo.
I've looked into building cross-platform GUI toolkits before and I think you're underselling the difficulty pretty considerably. To build these toolkits, you need expertise in everything from graphics programming to text rendering (which itself is surprisingly pernicious: https://gankra.github.io/blah/text-hates-you/) to accessibility and more. And then there are things which are just "regular hard" like constraint solvers for layout engines, designing a decent API, etc.
Valid points about FFI. That makes me think if Go devs cared enough about Desktop GUI, then they would try to make that weak point stronger. Their focus is elsewhere (networking, cli tools, web) which doesn't rely on FFI as much.
Eh a lot of people have, the issue is with Go’s memory model and how that maps to the C memory model. It requires what they call “trampolining” which caused a performance hit.
Interestingly, Rust originally used a similar memory model to Go, but then when they hit this problem decided to take another route.
This has the unfortunate side effect of making most machine learning also not practical in Go.
On the other hand, it has had the fortunate side effect of minimizing the amount of code which depends on C, which makes building and packaging software (including cross compilation) super simple.
That said, I'd like to know more about the limitations regarding machine learning. Presumably most machine learning stuff isn't implemented in C?
The ML limitations are that all the low level vector and acceleration libraries are written in C or C++. The GPU libraries are the real kicker, there isn't any great way around this except to trampoline over to C, that trampolining takes time which chews into your acceleration. Ironically Python is much faster than Go for ML because of this.
IMO, it's because the primary use case for Go isn't GUI programming.
The language absolutely is a generalpurpose language, and making great GUI libs with it is certainly possible, as shown by Fyne (yes, I know it's still new, give it time).
That being said, most people using Go build server side code and frameworks with it, aka. things that live as daemons in some rack or in a docker swarm. If there is an front-end to these kinds of applications, it's usually web based.
Absolutely. If I use a SQL db for my applications (I'm a software dev for context), I generally write raw SQL vs using an ORM. I find the long term issues of an ORM to not be worth investing and understanding SQL.
I'm also not having to learn a new library, in addition to the standard DB connection libraries, ~if~ when I switch a language or platform for some project.
Great writeup. Some of the points are moot now that generics are being released, but some very valid concerns.
I would also add that Enums + Exhaustive Switch is a very very weak area in Go that would really benefit the language a ton. I've used those features in other languages and that's one of the things I miss the most, especially when dealing with a ton of web API's that have a defined set of values for properties.
Able to have the confidence that we're checking for every situation that could occur on an enum type across the codebase is one less thing I need to worry about.
> Able to have the confidence that we're checking for every situation that could occur on an enum type across the codebase is one less thing I need to worry about.
If you can write the indulgence (permission to sin) into the code it becomes self-documenting and that seems reasonable
e.g. #![allow(dinosaur::nonsense)] in Rust tells the tools that you know you're not supposed to do whatever dinosaur::nonsense might be, but you want to do it anyway in the following code and the hypothetical dinosaur linter shouldn't bother you about that.
When a maintenance programmer is staring at this block of code later, the fact you explicitly intended to do dinosaur::nonsense is right there, documented where it happens, and they can decide if the proper course of action is to leave that as it is, fix the code to not be dinosaur::nonsense, allow raven::stupidity because the new Raven linter is better but now warns about the same problem under a different name or what.
Golint is the worst precisely because it isn’t configurable, and some of the things it looks for are idiotic. “should replace i += 1 with i++” is probably the worst advice I have ever received.
I can see Go's point here though. Unlike C-style languages where i++ is an expression, in Go it's only a statement, it has no value, which eliminates some footgun opportunities.
It's a halfway house to a language like Swift or Rust where none of the assignments have value. So, in a context where you don't want a value, arguably i++ is a better choice by eliminating a footgun. I don't hate it.
Strongly agree here. I'd rather have this than generics, personally. Having to implement my own sum types every time is laborious (moreso than most boilerplate that people complain about) and it's also hard for users to understand (what are all of the permutations?) and extend (I added a new permutation; where are all of the sites I need to update?).
I'm curious on what the percentage of contribution from the different aspects of loading a website are. How much are from the data center, from the network transfer, from the computer loading the website, etc.
If the data centers could run on cleaner energy, how much does that contribute to the CO2e measurements?
