That being said, the richest are effectively _not_ paying the highest marginal tax rate considering all the tax structuring they do. Claiming that they would be paying the highest income tax in the world is misleading, for one. Secondly, the richest in the world _should be_ paying the highest income tax.

Imagine if this was a new language that the dev community was seeing for the first time. It's hard to imagine it gaining much traction.

However, I never expected Opus 4.6 to be removed for the cheaper plans. I expected the pricing model to change, but not to lose access to the model. Moving to being token-based makes sense. It makes the cost more closely aligned with user pricing.

It was nice while it lasted. I got Opus 4.5 to do a lot of work from the beach by assigning it to detailed issues. With this news I've cancelled my Pro subscription. That will help a bit with their capacity issues.

- `_*` = any string

What have folks tried?

When you can directly write assembly with either, comparing performance requires having some constraints.

For what it's worth, I think coding agents could provide a reasonable approximation of what "average" code looks like for a given language. If we benchmark that we'd have some indication of what the typical performance looks like for a given language.

Coming from Python, I needed to work on some legacy Perl code. Perl code looks quite rough to a new user. After time, I got used to it. The syntax becomes a lot less relevant as you spend more time with the language.

Distribution can also be a lot easier if you don't need to care about the user having a specific version of Python or specific packages available.

I'm really suspicious about the performance concerns brought up in the article. Does the author think that long strings are really such a huge issue for the size of the JS bundle or processing time in the browser?

From my experience it's much easier to refactor the styling of a page using tailwind than modifying CSS. Needing to name a bunch of classes in HTML to reference in CSS adds a lot of obfuscation and it can be difficult to come up with those names. When the structure of the HTML changes the CSS inevitably breaks. I find that it's easier to keep the styling working when using tailwind.

I think that the value of keeping styling DRY is overblown. The author gives an example of some tabs that all use `font-medium` and how bad it is to need to modify all the uses at once. This seems like a non-issue to me. If you see the web page you would immediately see the issue if you forgot to change anything. Alternatively, you can still use `@apply` and classes if you don't want to repeat yourself. Even further you probably want to create reusable components anyways.

Tailwind is very easy to debug. I've never had an issue understanding why styling wasn't working when using it. In CSS I found that getting the styling right was a constant struggle.

The author mentions the issue of setting the text to red and blue in the same class attribute. He compared it to using `!important` in CSS, which is so far from the truth. You can immediately see the issue if the color isn't what you want. Inspecting the element in the browser would immediately show you that you set the text to multiple colors.

Tailwind solves a bunch of problems for me. Components are more self-contained. The class names are much easier to remember that the underlying CSS. The set of attributes you can use are focused to a small set of usable features. Animations are much easier. Responsive designs are easier to create. Flexbox (the most useful part of CSS) is easier to use. I work with a number of older developers (very smart folks that just haven't done web development) and I have a much much easier time getting them proficient with tailwind than CSS.

I strongly believe that tailwind is better for individuals, better for teams, better for beginners, easier to set up, and easier to maintain. If you're already a CSS expert or if you have an existing design system I can imagine that you wouldn't want to pick up tailwind. But for most websites and most teams I expect tailwind is a great option.

In contrast, I tried to learn CMake after. Despite my gripes about the CMake language itself, I found it relatively straightforward to do everything I wanted. Docs, backwards-compatibility, and LLMs made it all easy to set up. I have a hybrid C++/Rust project that compiles to desktop/WASM with debug/release builds.

When the build system for Zig stabilizes I'm sure things will be better, but the breaking changes are rough based on my recent experience.

I'm sorry to hear about your stress. The worst part about the recruitment process is that it doesn't put folks in a typical development situation. I hope you're about to find something!

Also, to the point of the post, do you consider whiteboard interviews to be good or bad for your situation? With covid it's harder for companies to find which applicants should be interviewed in the first place, and short questions are helpful for filtering out people who can't code at all.

[0]: https://developer.nvidia.com/embedded/jetson-nano-developer-...