U agree it adds a bit of complexity, but all code adds complexity.
Maybe interacted with CIs too much and it's Stockholm syndrome, but they are there to help tame and offload complexity, not just complexity for complexity'a sake
> they are there to help tame and offload complexity, not just complexity for complexity'a sake
Theoretically. Practically, you're hunting for the reason why your GitHub token doesn't allow you to install a private package from another repository in your org during the build, then you learn you need a classic personal access token tied to an individual user account to interact with GitHub's own package registry, you decide that that sounds brittle and after some pondering, you figure that you can just create a GitHub app that you install in your org and write a small action that uses the GitHub API to create an on-demand token with the correct scopes, and you just need to bundle that so you can use it in your pipeline, but that requires a node_modules folder in your repository, and…
Oh! Could it be that you just added complexity for complexity's sake?
Uh, I've used the package repository with GitHub, and I don't remember having to do this! So, I'm not entirely sure what's happening here. I think this might be accidental complexity because there's probably a misconfiguration somewhere...
But on that point I agree, initial set-up can be extremely dauntin due to the amoun of different technologies that interact, and requires a level of familiarity that most people don't want to have with these tools. which is understandable; they're a means to an end and Devs don't really enjoys playing with them (DevOps do tho!). I've had to wear many hats in my career, and was the unofficial dedicated DevOps guy in a few teams, so for better or worse had to grow familiar with them.
Often (not always) there's an easier way out, but spotting it through the bushes of documentation and overgrown configuration can be annoying.
You're sarcastic, but heavens above, have I had some cringe interviews in my last round of interviews, and most of the absurdity came from smaller start-ups too
I don't think it's actually infinit, but it's probably very high! We do have little receptors (cones) in our eyes (retina) that react chemically to light. So the density is the resolution (and different cone types react to different wavelengths, which is why some people are coloured blind, for example)!
- we are all colorblind, as we only see a very small part of the light spectrum
- there are no two individuals that perceive colors in the same way in the world as the receptor distribution changes by person to person (actually, even day by day on a single-individual basis)
Is this one of those things that are meant to sound deep and profound by inventing terminology, but isn't? That's such a like day 2 person thing to do.
(Actually don't know if I used day 2 correctly, feels a bit like trying to use skibidi ohio in a sentence)
In my head, and the way its describe the generic and specific are swapped. The core handles a specific, pure problem. The core is generic (do you get the data via http, databases, filesystem, etc) then becomes irrelevant to the core problem
I think it's just a contrived example. They probably wanted to show more than a single thing composing in a very short post given it's from their Toilet series.
Replace it with `getUsers(filters)` or even a specialised function, and it starts making more sense.
It's exactly this - I do regret using "db" a bit now after reading all of the comments here, as it's taken away focus from the main point. But yes, the post had to fit on a single page, and I needed to pick something that most engineers would be familiar with.
Kinda hints most people haven't used a good ORM, or if they have maybe just don't understand how it really works. Django looks similar to this and would have the same misunderstanding (User.objects.all()), except it actually returns a QuerySet object that would let getExpiredUsers() apply its own criteria and not actually run the query until something tries to read from the object. There's an example up above where someone shows SQLAlchemy doing the same thing.
You described a lot of orthogonal points and highlighted your opinions, more than pointed out flaws in the article.
I use Tailwind at work at a large company, and it's... Okay. Its biggest strength is the documentation, since most companies have poorly documented style guide/component library.
I'd never use it for a personal project though. It's fine to disagree
I know it's not exclusive to Go or any language, but you can most certainly write incomprehensible code in it. If anything, expressiveness and proper abstractions can save you from this.
I think people often get burnt by bad abstractions in expressive languages, but it's not a problem of the language, but the author's unfamiliarity with the tools at their disposal.
If someone starts being clever with abstractions before understanding the fundamentals, it can lead to badly designed abstractions.
So I guess if there's less things to master, you can start designing good abstractions sooner.
So, in my experience, if we invest time to truly understand the tools at our disposal, expressive languages tend to be a great boon to comprehension and maintenance.
But yes, there's definitely been times early in my career where I abstracted before I understood, or had to deal with other bad abstractions
I like to say this: "Only my code is allowed to be clever"
But, on a serious note, I agree with you. Go lacks a lot of power, especially in its type system, that causes a ton of problems (and downtime) that in other languages is trivial to prevent statically.
Formal proof languages are pretty neat, but nobody really uses them in the real world. Among the languages that people actually use on a normal basis, even those that claim to have extensive type systems, they still rely on testing for most everything, and once you're relying on testing anyway the type system isn't any kind of real saviour.
There is, perhaps, some segment of the developer community who believe that they are infallible and don't need to write tests, but then have the type system exclaim their preconceived notions are wrong, and then come to love the type system for steering them in a better direction, while still remaining oblivious to all the things the incomplete type system is unable to statically assert. But that's a rather bizarre place to be.
But doesn't change the tests you need to write, and those tests are going to incidentally cover anything the type system is also going to catch, so the type system isn't going to somehow make your software more reliable.
A much more expressive type system can get you there, but you won't find that in any language anyone actually uses on a normal basis.
Pretty much any null pointer deference error ever?
But it is hardly ever the weak type system that is at fault, just good use of a stronger type system could have prevented the issue.
Once you start to make "invalid states unpresentable" and enforcing those states at the edges of your type system suddenly a lot of bizarre errors don't happen anymore.
>it's not a problem of the language, but the author's unfamiliarity with the tools at their disposal.
If you have to share a codebase with a large group of people with varying skill levels, limiting their ability to screw up can definitely be a feature, which a language can have or lack.
As always, it comes with tradeoffs. Would you rather have the ability to use good, expressive abstractions or remove the group’s ability to write bad ones? It probably depends on your situation and goals.
Yes, there's always sloppy packages, or ones that need side effects (but that's usually very rare, and sometimes even then it's because of sloppyness), but installing something via package manager comes with certain expectations (I can update it, I can uninstall it, it's usually got a few standardised places where its config lives, etc). curl|sh makes most of these things a greater nuisance rather than frictionless
Maybe interacted with CIs too much and it's Stockholm syndrome, but they are there to help tame and offload complexity, not just complexity for complexity'a sake
reply