retrodaredevil

Good stuff! I'm excited to check it out. I see a lot of other comments here wondering if others still use this... I like MusicBrainz Picard because it makes it really easy to see everything that's going on at once. View the tags, see changes that will be applied, easily switch between configuration profiles, and easily browse to the recording or release page in MusicBrainz.

The manual workflow might not be for everyone, but it's a fantastic GUI application.

I mean, I guess you could say stuff like get(Object) and contains(Object) aren't type safe, but I've never seen that as an issue in practice. Plus there are some ErrorProne checks that'll tell you if you're doing something wrong in regards to calling contains(Object) with the wrong type.

NullAway with JSpecify annotations are a really good way to add null safety to Java applications. Even enforces nullability at the generic level.

Oh yeah, I agree with you on all those points. I guess what I'm trying to say is I feel like modern Java pushes you towards writing null-safer code than something like Go. I don't see the same push in modern Go.

This blog post is a great reference for "when to actually handle the nil case in Go" (and I think these ideas can even be applied to other languages), but there's nothing pushing anyone towards doing it the correct way in Go other than a documented team coding standard or an AGENTS.md/SKILL.md file.

In older Java applications there's also nothing pushing developers towards "correct null handling." A legacy Java application has a bunch of POJOs with getters and setters where all the fields start as null. That's why I think using records+JSpecify+NullAway is incredibly powerful in a Java project. NullAway really forces you to correctly and fully null annotate your code.

Self-discipline is great but static analysis tools actually enforce doing something "the right way." Things slip through code review, but a failing pipeline has to be fixed before the merge can happen.

Adding null checks where they aren't needed means adding branching complexity. It means handling cases that may never need to be handled. Doing all that makes it harder to understand "could this variable ever be null?" If you can't answer that question, it is now harder to write code in the future, often leading to even more unnecessary null checks.

I've seen legacy code bases during code review where someone will ask "should we have a null check there?" and often no-one knows the answer. The solution is to use nullability annotations IMO.

It's easy to just say "oh this is just something a junior would say", but come on, have an actual discussion about it rather than implying anyone who has that opinion is inexperienced.

The big news here is that you now need a premium subscription to use any of Spotify's APIs. This means that if you wish to use Spotify's APIs to more easily share music with others, you must have a premium subscription.

What's gross to me is the language:

> all newly created Development Mode Client IDs will be created under the updated Development Mode rules and will have the following restrictions applied by default > Development Mode use will require a Spotify Premium account

The language acts as if it's possible to have some sort of non-development mode application. If you look further, you'll see that a non-development mode application must be owned by an organization with more than 250k users.

This is a well put together list. One thing that frustrates me is that not all tooling respects mailmap. IntelliJ has an open feature/bug request for integrating mailmap into its git functionality. Additionally, the .git-blame-ignore-revs is more of a convention because you still have to manually configure that to be the file name to use.

Yeah I've noticed the IDEs have this ability, but I think tooling outside of IDEs that can be applied in a repeatable way is much better than doing a bunch of mouse clicks in an IDE to change something.

I think the two things that make this a big deal are: callable from the command line (which means it can integrate with CI/CD or AI tools) and like I mentioned, the fact this is built into Go itself.

I think tooling that can modify your source code to make it more modern is really cool stuff. OpenRewrite comes to mind for Java, but nothing comes to the top of my mind for other languages. And heck, I into recently learned about OpenRewrite and I've been writing Java for a long time.

Even though I don't like Go, I acknowledge that tooling like this built right into the language is a huge deal for language popularity and maturity. Other languages just aren't this opinionated about build tools, testing frameworks, etc.

I suspect that as newer languages emerge over the years, they'll take notes from Go and how well it integrates stuff like this.

I work full time as a software engineer, and I also spend time writing code on side projects. I love working on my side projects because it means I get to spend a bunch of time learning the quirks of whatever tooling and frameworks I decide to use. I often develop opinions and personal standards that I bring with me to future side projects (and sometimes $dayjob), although I've never quite stood up all the components of one of my projects "quickly". I'll always find something to tinker with and learn about, which I think is acceptable for my personal projects, desirable even.

As I get more personal projects under my belt, I believe I'll be able to stand up projects more and more quickly, although it's never perfect. Even though I've been using a similar stack among my side projects for a couple of years now, dependencies get outdated. Sometimes you gotta jump to a new major version. Sometimes you wanna try out the "new way".

I like the idea of building up my own personal stack of tooling, frameworks, and patterns that I use, and could even encourage the use of at $dayjob, but for the reasons outlined above, I agree with the conclusion of the article, which is that an "IKEA of software" doesn't exist currently.

For now I'll keep happily tinkering in my side projects. This article was a good read.

That's simply not true. If you scratch a vinyl record, you've introduced a defect to it. If you scratch a CD, it's probably fine. Some CD players don't like scratched CDs, but for the most part CDs are very durable.

Plus if you damage a CD, simply rip it and burn it to a CDr. (did I mention that ripping a damaged CD usually works?)

You are right about vinyl sleeves being more attractive, though. I think that's its main selling point.

I don't really like that "enshittified" is being used here. You could argue that Plex, MinIO or Mattermost is being enshittified, but definitely not self hosting as a whole.

Enshittification also usually implies that switching to an alternative is difficult (usually because creating a competing service is near impossible because you'd have to get users on it). That flaw doesn't really apply to self hosting like it does with centralized social media. You can just switch to Jellyfin or Garage or Zulip. Migration might be a pain, but it's doable.

You can't as easily stop using LinkedIn or GitHub or Facebook, etc.

There are a lot of incentives to lock people up. Cheap labor is one of them. We should support incentives such as "keeping society safe", but incentives such as "profits and cheap labor" are incentives that may actually incentivize locking up innocent people.

So it's not about which one is worse, it's about not supporting something that could lead to corruption or an unfair system.