If you want to increase the liklyhood of your contribution being merged, do:

* Provide unit-tests

* Good types

* No breaking changes

And if you want breaking changes or grand new features to be merged, you have to show activity in the issue tracker or fix open bugs first, to show the maintainer that you are willing to deal with the fallout or support requests that follow after a PR gets merged. This is not to be rude. This is seeing a PR through the eyes of a maintainer.

I used an apple watch since the first one, updated twice, but stopped using it a few months ago. Siri got slower an more unreliable. Automatic sport detection became annoying. And still having to charge it every single day became pretty old. I miss being able to pay with my watch without having to unlock my phone. But thats about it. Anything else about that product just became annoying.

I'm 100% certain that if 3rd party watches could integrate like apple watch could, that apple watch could be way better. But the lack of alternatives conceals how mediocre of a product it became. I wish apple wasn't such a control freak.

Those packages exist already though. Pretty sure the bun maintainers (or Ciro Spaciari in this case) asked the question "how fast could it be if written in zig?".

Isn't it possible to write it in Zig as a separate extension? Every mature language I'm aware of supports this AFAICT

Tree shaking means it won't bother you if you don't use it

I didn't confuse it since I use the mnemonic "formatting text to “justify” is horizontal in my language".

Sure you can change that. But that covers the flex default behavior.

But when the `flex-direction` is `column`, `justify-content` becomes synonymous for "vertical alignment" - that's what creates the confusion here.

I guess it makesmsense if flex-direction vertical is like switching to a vertical language.

When I manage a project and have the freedom to choose my configuration structure, then I always use typescript. I never understood the desire to have configuration be in ini/json/jsonnet/yaml. A strongly typed configuration with code completion seems so much more robust. Except of course your usecase is to load or change the config via an API.

I like what apple is doing with https://pkl-lang.org/ though.

You can apply typescript-based strong typing and code completion to JSON and similar. And then you can avoid making arbitrary code execution part of your config format.

Pretty sure netflix does exactly that with their other studios. I guess the big names mentioned in the article (Joseph Staten, Rafael Grassetti) wouldn't go to netflix for a 10 mio. games project, if what they already achieved is 20 times bigger. Heck, the compensation of these two probably consumes a 20 mio. budget.

We have the rule that commenting on syntax is disallowed. All syntax must be enforced by tooling (prettier, linter). This speeds up code review, because you review what actually matters (patterns used, regressions, bugs) and reduces friction between team members. Also a common syntax is learned way faster, as you get the feedback right in your IDE (or you don't even have to waste brain energy on it, in case of prettier).

If a syntax is not enforceable via linter because the rule does not exist, then you either write your own rule, or have to let go of the idea and have to surrender that there is a bit of wiggle room in expression.

This is a huge deal, I've tried to implement this anywhere I've had any clout and it always saves a ton of time on reviews. Automated lint, formatting and coverage requirements (just not 100%!) cut so much wasted time out of reviews.

Of course, the flip side is organizations that want to go crazy with Sonar/Snyk/etc, where every PR ends up being dragged down by over-opinionated tools.

Right now AI is like a chissel. It's a very useful tool, but not useful for everything. Banging your head against the wall of capabilities will give you an intuition when you will pull this tool. Just like you learned how to use a search engine effectively over the last 20 years.

When you are familiar with LLMs, then a question from someone who doesn't use AI is very obvious. It's the same feeling you have when you roll your eyes and say "you could have googled that in 10 seconds".

It's either explaining code where you don't even know the lingo for or what the question could be. Or touching code with a framework you never used. Or tedious tasks like convert parts of text into code or json. Or sometimes your mind is stuck or drifts off. Ask AI for an idea to get the ball rolling again.

Yes, discovering what works and what doesn't is tedious and slower then "just doing it yourself". Like switching IDEs. But if you found a handful of usecases that solve your problems, it is very refreshing.

When ignoring for a sec. the questionable 30% cut and duopoly: In the age of subscriptions, being able to see all your recurring payments on a single page and cancellable with two tabs without questions asked, is a feature worth paying for.

> In the age of subscriptions, being able to see all your recurring payments on a single page and cancellable with two tabs without questions asked, is a feature worth paying for.

This is a service the banking system should clearly provide natively though - there's no good reason Apple is the only one capable of this, nor any good reason why they're best placed for this (there's plenty of non-Apple subscriptions where this would be useful).

Your card provider is well aware of what recurring payments are currently authorized, and should be perfectly capable of providing tools to cancel those authorizations (and inform the merchant of this when doing so).

That that doesn't work is a failure on the part of financial firms (who could provide it) and regulators (who imo should oblige card providers to offer this, and oblige companies to treat cancellation notification like this as equivalent to written notice). Recurring payments are an increasingly fundamental part of consumer banking, but banks provide effectively zero tools for consumers to manage them.

The argument against is that some of these payments might have ongoing obligations you can't just cancel without consequence, and you'd be effectively just be refusing to pay your bills - but you could equally well have no balance available or something so the payment fails in existing cases anyway, so this seems like an entirely solveable issue (if a business that you _must_ pay receives a notification that you've cancelled the card billing authorization, they're going to need to get in touch with you about it just as if your monthly charge failed).

Yeah they should get together and create a standard protocol for managing, transferring, and paying subscriptions.

Imagine if you could manage subs through your bank, but also transfer the sub to a different bank as needed.

Could even have protocols for payees to verify payer sub status. Maybe there could be two "ends" to a sub; payer and payee end. Like a money wormhole.

Would be cool if that was the customer's choice and not forced down your throat from a monopoly.

I guess thank you apple for finally allowing someone else to use the 3n process. Everyone applauding apple for their incredible silicon, but IMO it's 70% just thanks to tsmc.

These are 4nm.

And 30% soldering RAM on-package.