Author here, sorry about that, I just deployed a fix, should be readable now. If it's not, here's the first few points
- Once you get good at Rust all of these problems will go away
- Rust being great at big refactorings solves a largely self-inflicted issues with the borrow checker
- Indirection only solves some problems, and always at the cost of dev ergonomics
- ECS solves the wrong kind problem
- Generalized systems don't lead to fun gameplay
- Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
- Procedural macros are not even "we have reflection at home"
- ...
the list corresponds to the titles of sections in the article.
Awesome! I recently encountered the need of expanding a Spring Boot Admin instance to offer OpenAPI docs for custom Spring Boot Actuator endpoints which are in their own group, hidden from the main API. As SBA requires custom views to be Vue.js components, this will probably fit pretty nicely.
This is why I moved to jOOQ years ago. Nice lean abstraction over SQL, to the point where it's just a typesafe SQL builder and also does the mapping to domain objects if you want. Abstracts and polyfills SQL capabilities just enough for you to be able to port your queries between DBs if desired.
I'm a big fan of jOOQ. I've been able to implement the most complicated SQL expressions in jOOQ. Though there is one particular use case that it cannot do, but my memory fails me. There is an open issue in Github for it that's been open for years. Luke, the creator of jOOQ, is not able to figure out the solution to implement it. But no worries, it's still my favorite way to access my DB.
I've only had a brief stint in Java in my career, but I got to learn about and use jOOQ, and I think it's such a fantastic option in this space. I'm still a diehard SQLAlchemy fan, and I'd use it in Python-land. For Go, I think sqlc is a decent option, but it's no jOOQ. I'd love jOOQ for Go.
jOOQ is far and away the best library in this class for any ecosystem.
It's so good you would need to think long and hard not to choose the JVM for a SQL heavy application because it's just that damn good and most other library requirements are relatively interchangeable.
It's 2022. Why would I learn even more horrible CMake instead of just going full Meson? Looks like it's the same cognitive cost, but no gains by staying on CMake.
For my curiosity, does Meson emit "native" build files, such as Visual Studio, Makefiles, Ninja, or the like?
That's been my favorite part of CMake (even before CLion used it as their defacto project format): if you can get a run of cmake to complete (which, granted ...), then you can open the project in a sane IDE and have library and build targets available
Yes, I agree. That's why I pointed out that it was specifically US market share. I just found those quickly. The percentages are lower in other regions, but the total numbers are still huge.
The question is what is the percentage of potential market for a specific product. If you are optimizing GPU code, that is a very different market from “all computers” or “all phones”. If the market depends on high performance GPUs, then the Ultra has potential to be a noticeable percentage of that market.
Well up until the M1 Ultra, almost no one was doing GPU intensive stuff on mac, since they didn't have a line with a decent gpu. As such, Apple is creating an issue for developers that only manifests on the $6000 version of their machine that requires rewriting your whole algorithm to work around.
Exactly. On top of that, Apple is still in the minority and refuses to support the Vulkan API they helped design. So, from a development standpoint, rewriting your software to support ~15% of your potential market isn't a very lucrative idea. Especially when the vast majority of those users will be running relatively incapable hardware, at least on the GPU side of things.
Sure but what if the US Engineering population represents a large portion of your paid-user demographics. For a lot of HN's startups this is very much the case.
That's not very relevant for the purpose of this discussion though. For example, a common stat floating around is how iPhone has 20% market share around the world but provides 80% of in-app revenue, which is what businesses care about.
Keep in mind that the author is not neutral here: Since he's expressed his position against trans people, and by doing that parted ways with Danielle Foré before (who previously identified as Daniel Foré and participated in his youtube videos), and also you can see that it refuses to use the actual name for Danielle; it's not surprising that he wants to reach a conclusion against her.
What does the trans issue even have to do with a partnership dispute, on the shareholding structure of their arrangement? Why does everything have to be a gender issue?
