Actually I like using snap. Sure, it's not perfect, but for some things it just works. Sometimes it's really nice just to execute one line without downloading/extracting/installing stuff by yourself.
But flatpak does the same and has broad distribution support. The problem isn't necessarily that snap is bad (though, I would argue generally inferior in a couple regards) but that it's doing the typical Canonical thing of recreating a solution to a problem everyone else is putting efforts to already, just causing more general fragmentation of the ecosystem.
I would bet flatpak doesn't do this by default since it doesn't hijack a native package's namespace in the way Canonical is forcing people with snap hijacking apt install, and gives you a choice.
This lets me run multiple different Chromium flatpaks alongside the native package (stock Debian apt Chromium, official Chromium flatpak, Ungoogled Chromium flatpak) without issue, for example.
Don't forget the fact that it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on. Even generics in Go were a heated debate because they make the language more complex. All in all Go was created by geniuses and it shows.
> it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on
Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a single HTTP handler actually does.
A certain number of developers will be able to complicate any language or mechanism you provide them, it's how they feel important. I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else, except they aren't, so they build extremely complex systems, because they think that's what smart people do. They are interestingly often extremely well versed in their tool of choice.
You are mistaken if you think that the abundant use of interfaces etc. is motivated by anything along those lines. As someone who often puts basically everything behind an interface and abstracts everything in sight, it's not because it has anything to do with being smart, quite the opposite; it's the only way I can keep any meaningful portion of the code in my head. Give me a 5000-line straightforward / unabstracted implementation of something and I'll struggle, but give me thingDoer.doThing(), behind an interface so I don't even have to know how to construct one, and I'll be happy and able to focus on the task at hand. This applies even if I'm the one who wrote the ThingDoer interface and its implementation(s), and even if it was only 30 minutes ago.
> They are interestingly often extremely well versed in their tool of choice.
This has become a red flag to me; over attachment to a tool or paradigm means that they're driven by and making decisions using feelings, not through actual analysis.
Very well put.
"They are interestingly often extremely well versed in their tool of choice."
People who are, shall I say unwise, but very good at what they do is one of the most annoying things wrong with the world.
> I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else
I've also seen the opposite where people revolve their entire identity around not being the person and they swing too far the other direction and end up being a masochist and doing things the dumb way because they're too afraid of coming across like a snob.
No one is safe from bad developers. I've seen go SDKs for paid products that were clearly written by people with only a vague idea what the target language offers. I have to assume such libraries were hammered until the compiler just accepted what was given
There is this odd thing where the actual syntax and features of a language are (at least partly) independent of how it ends up being used. A culture forms around the language (that the authors have limited influence over). Java does not have to be used the way most people tend to (factoryfactoryimplfactory!). And some go projects (notably at least early k8s are go in Java style).
A lot of what people comment on is less the language and more the dominant culture.
I disagree because I've seen some readable Go codebases but I wholly agree that bad Go codebases are a nightmare.
Try comparing the Honk source (clear, direct, modulo the unangst wacky names for everything) with GotoSocial (unreadable, interfaces and abstractions out the wazoo).
(Yes, I know GTS supports the MastoAPI but that doesn't force the hellish onion-layer abomination they've created.)
That's very strong language. Go was created by some smart people that have completely ignored programming language developments that happened after the 70's.
Go made a lot of odd choices from a language design perspective. It's pretty much "C, but with better types and a garbage collector!"
It certainly has its usages and does some nice things. But at the same time, the obsession with compile speed has, IMO, has been a detriment to the language as a whole. We see this in the way generics ultimately entered go after years of causing problems by not existing from the get-go.
I'd say that the hands-down improvement over C is simplified threading and proper utf8 support. The utf8 alone (because of the notion of rune) is a good reason to use golang over C or C++.
Yeah, but advanced languages are also a problem for long-term maintainability.
Remember, Go was developed at Google - jokingly, while waiting for stuff to compile. They deal with tens of millions of lines of C++ written by thousands of engineers with varying skill levels and career paths. The advancedness of C++ did not reduce the compile times or readability of the code. At those scales you can't rely on being familiar with a particular section of code; you need to be able to drop in anywhere and know what's going on, without having to learn which subset of the advanced language they used for that particular feature.
Advanced languages can compile quickly - it depends on the feature set chosen. For example, do-notation is an advanced feature not found in most languages, but it compiles quickly as it is syntactic sugar. Operator overload, on the other hand, might require a solver and thus compile slower. It's not a particularly advanced feature, however. Binary optimization passes do not make the language any more advanced (on the user side), but will slow down compilation. Advanced design and compile-times are pretty orthogonal.
As for maintainability, it's not clear to me that reams of imperative code is easier to maintain than something terse and declarative. In fact, probably the opposite.
It depends on what libraries you use and how you structure your code. Yes, you can create inheritance hell within Java code. But you can also use composition (what Go uses) within Java and create sane code bases.
Inheritance is a foot gun that got overused in the '90s and early 2000s. But people have learned mostly to avoid it unless really needed.
I remember looking through this insane taxonomy of abstractions of a button to find the code for when it got pressed. There weren’t that many buttons and they had no special requirements. Just trying not to find some real actual code that does the thing. I work on much bigger projects now with much less abstraction and my quality of life is much higher
Go was first and foremost created to serve the needs of Google. Kudos to them for releasing, open sourcing and backing it but it was designed to serve their needs. It’s not a criticism but it explains why it’s quirky in many areas. The authors being genius is not as important as the goals and intentions.
They may be geniuses, but some - mainly Ken Thompson - are also luddites, eschewing things like syntax highlighting. I mean they have a point - if you need colors to make your code readable, your code isn't readable.
But yeah, I love how everything is well thought out and they just say "no" a lot.
Before joining a corporation I really thought that this is an exaggeration by people who are unsatisfied by their own fate at the companies to which the consultants come. I was shocked by how true this statement is. A lot of PowerPoint slides and very little value in them.
I previously worked for a large management consulting firm, but in one of their newly acquired tech/implementation teams.
There are quite literally analysts and sr analysts on every project whose entire job is just creating and editing powerpoints, sending them to their partner managing the case, getting feedback and repeat. Nothing else, just powerpoints. They may sit in on some meetings themselves but don't really offer much in the way of actual expertise in any meaningful way. Many of these people have literally never worked in the sector/field they are supposed to be consulting/advising on
They all have due dates basically every night for a new powerpoint presentation and that is literally the only deliverable for many of the people on a given case (client project).
While I was paid a lot for the job, often multiples of the developers working for any given client and it was hyper stressful, there's probably not a single project I can think of where the client wouldn't have been better off just doing things themselves and hiring full-time positions or even contractors who aren't one of these giant complex expensive firms.
Now that isn't to say there aren't a handful of very valuable/knowledgable people staffed to a project, but I'd wager on the average project only like 10-20% of people have anything of actual value to offer.
Yup. I've gone in as a workflow software / network company to clean up after some of these top consultants' "recommendations" (i.e., make and/or replace their systems so they'd actually work as advertised).
With what I've seen, these "consultants" are the most vulnerable segment to LLMs, especially LLMs tuned to the corporation's information store. Which means that the consultant's largest clients will disappear first.
Of course the consultants will try to sell "we will help you implement these LLMs for your business".
That is best case scenario. In a company I worked in, they managed to create reorganization ... without actually talking to anyone who would know what people and departments do.
The two most capable managers looked at new organization they were supposed lead and left. So it was headless for next two months. Remaining people inckuding manageme t spent a lot of time doing nothing for months complaining in the kitchen. We all got used to low productivity as normal. Then I left, not sure what happened after.
This. The number of times I’ve had to mess with or write yaml and gotten some ridiculously unhelpful error because I forgot a space somewhere or needed dashes in my sub-whatever are equal to the number of times I’ve had to write yaml. I’d seriously rather work with XML than YAML. It’s worse to read and 10x worse to write than JSON for anything nontrivial. It’s the TAI64 of serialization. It’s like JSON that you have to type the spaces out to format visually yourself for each thing. I don’t understand the mindset of folks who prefer it. Quotes in yaml are as much fun as they were with mysql_real_escape_string. The only way I work with any significant amount of YAML is by converting it to json. Terrible format, 0/10, let’s just write everything in acme::Bleach since significant whitespace is so darn cool right?
I'm aware that yq has a lot more editing features, so it's not apples-to-apples, but I'll also draw ones attention to gojq's --yaml-input flag <https://github.com/itchyny/gojq/blob/v0.12.13/README.md?plai...> (they have yaml out, also, but I use that a lot less often) allowing leveraging the same language for both input formats
Canonical sent me a 30 question "written interview" which asked all sorts of personal and irrelevant questions as the first step in their interview process. I ghosted them.
I didn't explain enough and thank you for clarification! I think the problem will be that I will not get the project which is using MinIO right now to comply with AGPL.
