It boggles my mind that some people are more concerned how much fun driving a car is supposed to be vs 60 people dying in the EU in car accidents every day.
If 60 people died because an airplane falls of the sky every day we wouldn't shrugg that off either, wouldn't we?
And a voice that tells you to keep your eyes on the road when going 200 on the autobahn is one of the least offensive intervention I can think of.
Yes, projectors with 3LCD tech is what you are looking for. They produce all 3 colors at once via 3 distinct lcds inside the chassis and mix them ahead of time. There are a few to choose from, but they all cost above 3000.
The reason why projectors don't use a single rgb lcd (like monitors) to produce the color is the same why all sub 5000$ projectors use pixel shift to fake 4k resolution: Too much light is blocked by the lcd itself if the individual pixels become too small.
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?".
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.
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.
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.
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.
Yes, kinda annoying. But on the other hand, given that apple releases a new chip every 12 months, we can grant them some slack here. Given that from AMD, Intel or nvidia we see usually a 2 year cadence.
Saying typescript is slow because zod is slow is like saying c++ is slow, because javascript is slow. Not to say that typescript is quick in any way (how could it be, as something written in javascript). But letting typescript execute code to infer types in a large scale application seems like a self inflicted issue.
They sponser https://github.com/kdy1 (see the vercel in his profile), who spearheads swc, which is very similar in goals and scope to esbuild. swc may ring a bell, as it's the parser/compiler that is used by deno and bun.
Vite and webpack (and thus turbopack, which is advertised as a webpack successor) are two different beasts.
While vite is perfect for most users, there are just some usecases that are not doable with meaningful performance. Without boring you with details why, let me assure you that having a performant webpack replacement for those 10% who need it, helps vite staying lean, as they are not bothered with feature creep.
If you want a small detail why: Vite is built on esbuild. Esbuild is carried by a single developer (https://github.com/evanw/esbuild/graphs/contributors) thus every nut and bolt that vite does for you on top is built in javascript, so you are in slow-land again.
webpack and turbopacks promise (and complexity) is that it treats these extras (plugins and loaders) as first class citizens and thus tries to make them as fast as possible by applying tons of caching. E.g. if you'd throw a webpack workflow at vite, you might end up with a slower build then webpack. And this is where turbopack tries to improve.
IMHO the base framework can and must be simple and unnuanced and easy to remember:
* eat as little and never drink: sugar, alcohol
* seek: stuff that feeds you and your gut biome and doesn't cause diarrhea (aka avoid ultra-processed food)
* bonus: at least once a week: fish, salad, nuts, fruits
Sure, thats not nuanced. But the message is simple: If you eat/drink sugar, alcohol or processed foods, then your body will degrade faster and your biological organism will run on pain, inflammation and fatigue.