I'm sure this is an unpopular opinion here, but I hate this website's UX. Replying to a comment loads a new page, losing the entire context of the thread. There is no UI to indicate if there's a reply to an earlier comment made. The typograph is ugly as sin, and hard to read (too small on desktop, looks bad on mobile, poor contrast). With new pages needed for basic reply/editing capabilities, the site doesn't even accurately track the navigation stack. Sure it loads quickly, but we can load a hello world in a p tag pretty quickly too. HN as a site is a perfect example of how bad a SSR experience can be.
So there was a measurable problem (large bundle size) that they sought out to fix (in addition to upfront loading time). The first thing to do would have been to _not_ engage in SSR, or Angular 2, or any other big architectural change without first checking if actually properly slimming the bundle would have helped first. Next, how do you proceed till almost ship without actually solving one of the core initial problems you set out to fix? Before porting the universe, it seems like you should at least remove that risk or convince yourself you know how to do it. I'm going to go on a limb and also completely disagree with the conclusion that a React rewrite was the right thing to do. My experience is that engineer morale isn't maintained by staying in framework and rework hell - instead, morale increases when engineers have opportunities to deliver high-value experiences to users. Not shipping is a common and understandable reason for engineers to leave, and if your employees are hankering to leave because the tech they use isn't the current flavor-of-the-month, you may need to reassess your cultural values screened during the hiring process.
The answer is already there. If you extend the sequence given in the article longer, the ratio of the number of digits in the rational representation to the decimal representation gets worse, not better, so you know you reached the inflection point early.
Eh, I use them and am quite productive with them. Some of the downsides I don't really buy, for example, the argument regarding allocations. In a typical task engine, you're allocating state per task anyways. Sure you could have custom arenas and such, but you can do that with C++ coroutines also by overriding operator new/delete on the promise object. The lifetime concerns are par for the course when it comes to async stuff (assuming that's how you're using C++ coroutines).
You buried the lede - the important context is that your site hosted malicious content at one point, regardless of intent. Whether the policy is correct or not, withholding that information in the title isn't doing you any favors.
Yea, honestly these types of numbers really aren't surprising, but usually when you profile a build and dig into why the build perf was so bad to begin with, you generally find stuff like template abuse, bad header organization, and countless other untold sins that were better off fixed anyways.
I wrote a comment in the linked thread as to why I really dislike Unity builds. Some folks make it work for them, and they have some attractive/tempting properties, but I think the siren's call of unity builds should be utterly rejected whenever possible.
This is such a HN phenomenon it infuriates me. Read article. Then read comment that misconstrues article to be something completely different, accompanied with loud critique. Read replies all in violent agreement to obviously self-evident strawman.
USD isn't usable as a last-mile format, so many game engines still use internal formats that facilitate fast edit-time to last-mile format conversion and compression, mainly as a point of pragmatism. There is some slow adoption of USD, but given that the main drivers of the format are from VFX, it's understandable that it will take some time for game devs to embrace USD fully.
While writing a quick JSON5 parser, I encountered this old thread of incendiary takes from the HN community on the initial JSON5 proposal. Make of it what you will.
This isn't a hit piece. As someone that formerly owned a Tesla, all of this rings true and I was so glad to finally ditch the vehicle back to the second hand market.
The primary metric I believe is important in evaluating the viability is TA is the number of people that "believe TA works." To the extent that other investors trade based on mystical figures on a chart, the price behavior may start to match investor movement and become somewhat of a self-fulfilling prophecy, at least until more meaningful fundamentals start to stabilize the behavior.
I use git primarily, but if you work on a project that needs to version control data (images, textures, meshes, sky boxes, terrain, etc.), git, even with LFS, is such a terrible experience compared to Perforce.
Ligatures, IMO, make for a bad coding editor experience. No, I do not want >> parsed as a right shift when it's actually used as two adjacent template delimiters. And no, I'm not okay with the inconsistency that results from the usage of different operators from one programming language to another. It's a cute idea, but I found it more annoying to use in practice.
Yes and then if you read paragraphs 3, 4, 5, etc. there's no substance on what is actually sent. We all know what Wireshark is, and what it can do, but how it was utilized here is up in the air.
Thanks for the response and all that makes sense. These days, a lot of the LaTeX and TikZ I write is honestly embedded in web and asciidoc content (via custom extensions and a lot of shoestring interprocess scripting) so that seems perfectly fine. Ironically, I use SolidJS when I happen to do web stuff also, so I'll be sure to check that out.
I'm a long time TikZ user and have been following penrose since the initial video introduction. Really great progress! At this point, what do you think an avid TikZ/dot/pgf user might miss the most when trying Penrose?
Sigh. This is entirely expected behavior, and in fact, is _necessary_ behavior. If changing signatures in that way continued to allow code to "compile" with reckless abandon, so many things would break. I think before complaining, you need to understand how general symbol resolution, name mangling, and argument dependent lookup work. And if you're too impatient to learn, you're not actually in a position to criticize.