> When I enquired ChatGPT why it said "no", this was the response:
> "Because your question was phrased in a way that depended on which year we’re currently in, and I initially answered it generically: “If today is 2025, then 2026 is next year.” I started by explaining the conditional logic instead of immediately stating “Yes,” which made the answer sound like No at first. Then I clarified based on the actual current date (December 2025) that yes, 2026 is next year. So the short version: My first sentence emphasized the logic, not the direct answer. That caused confusion."
I seem to remember Bill Clinton sometimes also talks like this
Also this UI / UX issue isn't just a problem with Spotify but iTunes (Apple Music) to! So I guess it's just a general trend that started for no good reason.
In iTunes, the table view is now only for the main page, and has been gone from the search and the playlist pages. It's so inconsistent. You get the nice old-school table view when you're on default but then when on the search page they display it on grid view. On the playlist page, you're like on this weird half-table half-grid view.
Out of the 4 instruments that are still locked I'd reckon three would definitely be Jupiter 8, Juno, and TR-909. I can't confidently guess the last one though.
I'll try them later at home. Do you think they'll sound as good as the analog counterparts? Hahahaa
I second Bazel. People keep on mentioning how steep the learning curve is, but the conceptual model is really simple, elegant, and intuitive.
What is steep is the technical know-hows:
1. When things don't work as expected. For example, while it worked flawlessly with languages that it natively support such as Java, that wasn't the case for other languages such as Javascript or Python.
2. When you have to do something advanced such as building custom Bazel rule. You'll need to understand Bazel internals and unfortunately the documentation isn't very intuitive and also somewhat sparse.
The http_archive has a sha256-attribute to deal with the "random". You could add multiple urls to point to your local mirror as well. It's a way to pin external dependencies and get reproducible builds without checking in a big blob into your git. pkg-config in my experience is less reproducible and tends to pollute and be affected by system environment, unless you have some build guru who can setup chroot in your project.
Oh I didn't mean "random" as in "could change". In fact "random" was about the unspecified .so blob, not the http archive.
> pkg-config in my experience is less reproducible
But this is what I mean, you only want full reproducibility in a "corporate" environment. In a FOSS desktop environment you often specifically want to use whatever the system has.
I suspect the experience varies pretty widely based on what languages you use and what you’re trying to do with it. If you’re just building Go binaries then I’m sure Bazel is great, but if you’re doing anything with Python 3 or if you’re doing something a little off the beaten path like code generation, it’s probably a frustrating experience.
Lots of things can be complicated in Bazel, but I would not at all consider code generation to be among them. You just write a genrule, and wrap it in a macro if you want to do the same thing more than once. (It can be more complicated than this, of course, but then code generation isn't the hard part of the problem.)
> If you’re just building Go binaries then I’m sure Bazel is great
Compared to other things in Bazel maybe, sure. But if you're just building Go binaries you don't need Bazel. The standard Go tooling is beyond sufficient: it's hard to beat.
> I suspect the experience varies pretty widely based on what languages you use and what you’re trying to do with it.
I second GP's assessment that Bazel is pretty developer-hostile if you are not Google or have Google's resources to maintain Google's build systems.
Case in point: get Bazel to consume system libraries or vended/third-party dependencies in a C++ project. This is a pretty basic usecase, but it was left as an afterthought in Bazel, and it's an uphill battle just to get Bazel to work with them.
I don't doubt that Bazel can be usable if your entire world is locked tight in repos you control and were all forced to migrate to Bazel. It's the same thing with GYP, another developer-hostile build system spawned there. However, that is not how the world outside of Google works.
The only way I see Bazel become relevant and usable for non-Google/FANG-size orgs is if a higher level build system like CMake supports generating Bazel code, so that all these shortcomings are brushed under the proverbial rug. However, if we get to that, are we really using Bazel, or is Bazel relegated to an implementation detail?
The very fact that this occupation exists pushes me away from Bazel, having never used it. Makefiles are horrible, but they are well documented and I've been able to google my way out of every problem that I've either run into, inadvertently caused, or had to debug from somebody else's mess (it's always a mess).
I don't actually want a better build tool. I want a tool that I spend as little time as possible thinking about.
But that’s not really how it works. Build systems exist in a complex domain — whether we like it or not, that complexity can’t really be hidden away, it will leak one way or another.
The complexity need not "leak" - it could be an explicit feature of the tool. Make kinds sorta does this, as the learning curve is steep from the beginning but stays constant. Tools that are easier to use at first but then smack the user with "leaked complexity" set the user up for situations he is not experienced enough to handle.
That might be fine in an enterprise setting where the user likely has a mentor or support contract to turn to. But it's not what I want at home.
The problem with Bazel has nothing to do with learning curve. It's a pretty simple model as far as build systems go.
It's that it requires a lot of boilerplate and has a very rigid nested structure... which compounds boilerplate, unless you venture into custom plugins/build rules.
Some of the basic ideas are absolutely right, e.g. separating the resolution of dependencies from the build, and purity, but it's just soooo much boilerplate.
I think many of the ideas/techniques behind Bazel are excellent: hermiticity, distributed caching, dependency analysis, massively parallel execution, etc. There are so many things every other build system out there can learn and apply from Bazel that could make them 10x more effective.
But IMHO Bazel's fundamental flaw is that it tries to be a one size fits all solution that's supposed to work for all languages and ecosystems. That pretty much guarantees that it will have more need for boilerplate/configuration, be less performant, have more bugs, and at the end of the day just offer a worse user experience than a build system that applies all of Bazel's underlying ideas/techniques while being designed solely for a single language/ecosystem and more deeply integrated into it.
I think the eventual best case scenario for Bazel is a jack of all trades, master of none, but in its current state, for most of the languages/ecosystems it claims to support, it would be way too generous to even call it a jack of the trade in terms of overall UX.
It doesn't do union types yet, but it's got type inheritance, type inference, type-safe joins (with its "relation" feature). It's quite cool what you can do with it when you can express complex domain with the language.
> "Because your question was phrased in a way that depended on which year we’re currently in, and I initially answered it generically: “If today is 2025, then 2026 is next year.” I started by explaining the conditional logic instead of immediately stating “Yes,” which made the answer sound like No at first. Then I clarified based on the actual current date (December 2025) that yes, 2026 is next year. So the short version: My first sentence emphasized the logic, not the direct answer. That caused confusion."
I seem to remember Bill Clinton sometimes also talks like this