evmar

The "use ASLR for random seed" trick in there is pretty cute, but I noticed it will just silently not work in non-ASLR settings, and in particular under Wasm.

I had typed out my comment already but it's basically identical advice to this one, so I'm going to move it here as a way of just emphasizing the above advice!

---

If you're on HN it's plausible you're advanced relative to your peers, either in your education or in your career. Don't use that to rush your way into adulthood! You have the rest of your life to do adult things, but you only get ~730 more days of being a teenager in your whole life.

Concretely: if you're ahead in your education, don't skip college, but instead use your aheadness to make time to learn more things. If you're ahead in your employability, don't jump into maximizing your $$$ but instead look for interesting personal growth opportunities.

The article is great, sorry for the quibble!

The maybe too subtle point I was trying to make is that, even though the TypeChecker object literally provides an EmitResolver (I think? something like that?), in terms of the conceptual layout of the compiler, if you have a box labelled "Type Checker" it's natural for the reader to think it's where type checking happens.

In other words, the graph is something like

    TypeChecker object -> EmitResolver -> js files
      |
      v
     type checking

This is a bit misleading in where the "Type Checker" box is pictured, but I think it's due to an understandable confusion about how the compiler is structured.

Importantly, types do not affect TypeScript emit[1]: you can take a TS program, replace every type with Banana and the compiler will have the same output.

(I am not sure, but I think the TypeScript emitter does use a "type checker" object for type-adjacent things like resolving scopes. But it does not use such an object for checking types during emit. Another way of saying this is that type checking can be done during emit but conceptually it's a an optional segue on the side, not the box immediately leading to .js files.)

[1]: http://neugierig.org/software/blog/2016/04/typescript-types....

I read about stack graphs before, it sounds interesting!

I think they help, but ultimately I expect you need a compiler solve the absolute madness of the totality of C++. For example I think getting argument-dependent lookup right in the presence of 'auto' requires type information? And there are other categories of things (like header search paths) where I think you are forced to involve the build system too.

I contributed to a similar system used within Google (partially open source at kythe.io), that took the very different approach of integrating with the language-native toolchain for each language.

As this article describes, doing this requires per-language integrations and also effectively being able to "run the build" for any given code (because e.g. the C++ header search path can vary on a per-source-file basis), which is untenable for a codebase as large and varied as GitHub's. However, if you can make it work, you get the benefit of having the compiler's understanding of the semantics of the code, which is especially finicky in complex languages like C++ or, say, Rust.

For example, if you look at this[1] method call it refers to a symbol generated by a chain of macros, but the browser is still able to point you at the definition of it.

It's an interesting tradeoff to make: the GitHub approach likely doesn't handle corner cases like the above but it makes up for it in broad applicability and performance. I recall an IDE developer once telling me they made a similar tradeoff in code completion, in that it's better DX to pop up completions quickly even if they're "only" 99% correct.

(To be clear, I absolutely think the approach taken in the article was the right one for the domain they're working in, I was just contrasting it against my experience in a similar problem where we took a very different approach.)

[1] https://source.chromium.org/chromium/chromium/src/+/main:v8/...

(n2 author here) ETA is pretty hard in the presence of parallelization unless you make big assumptions like "all pending build tasks will be able to run in parallel". If you had any good ideas here I'd love to hear them.

(n2 author here) This is really cool! I am sorry if weird ninja decisions (like not being lexer-friendly or phony being underspecified) caused you grief, the whole thing was really built as a quick hack before I understood the problem space.

In Ninja, which needs to spawn a lot of subprocesses but it otherwise not especially large in memory and which doesn't use threads, we moved from fork to posix_spawn (which is the "I want fork+exec immediately, please do the smartest thing you can" wrapper) because it performed better on OS X and Solaris:

https://github.com/ninja-build/ninja/commit/89587196705f54af...

I love Factorio!

If you've completed enough of the base game, I can recommend Seablock (which includes AngelBob) and Space Exploration as two mods that make the game dramatically larger. I played some of Pyanodon (which is also sometimes mentioned as a big mod) but I found it kind of gratuitously complex.

I don't know the history, but I think Figma predates much public knowledge about Skia.

Further, I have the impression that Figma has pretty specific and complex graphics needs. For one example of the sort of thing I mean, we decode image data in JS and put it into GL textures without the Wasm side ever seeing the pixel data, so that the browser can (potentially) decode on a background thread and uncompressed pixel data doesn't contribute to Wasm heap memory usage. However, I don't know Skia well, so it's possible Skia has some mechanism to composite GL textures it's not responsible for too.

Yes, sorry! I should've written GL, not GPU, but it's too late to edit it to fix. ...though there are some shaders involved.

> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine

This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library.

Source: I work on this code.

How does this compare to http://www.plask.org/ ?

Missing the most recent developments but still mostly accurate: http://neugierig.org/software/blog/2011/11/graphics-stack.ht...

At least as of >10 years ago when I worked on the code, the equivalent feature in Linux Chrome uses a unix socket in your Chrome profile directory. It was a little subtle to implement in that you need to also handle the case where a crashed browser leaves a socket behind.

My recollection is that you need a license to PDF patents from Adobe to implement those things, and Apple is somehow grandfathered themselves into those licenses via NeXT.

(But upon writing that I'm not sure where I got that impression from, and I can't find a citation for it right now, so treat the claim with skepticism.)

As a person who enjoys doing this kind of cleanups, it is disappointing. But when I think of the larger business perspective, these kinds of cleanups are difficult to justify, in that the value of them is hard to quantify.

Overall the net effect is a kind of death by a million cuts, but each of these cuts individually is a decent amount of work to clean up and fix that doesn't itself move any needles.

My latest perspective on this is that the only renewing force is the also the one found in nature, which is that you occasionally need to burn the whole forest down or have the organism die, so that you can start again afresh. In a business setting this means using a new stack in a new app.

> seems to compare the Firefox version number with 65 ... I’ve no idea what the purpose of this is

I previously worked on JS infra at Google. Google uses a lot of shared JS libraries that date back over a decade, and those libraries have accumulated lots of workarounds for browsers that nobody cares about anymore. (One especially crazy seeming one from today's perspective is that there's a separate implementation of event propagation, I believe because because it dates back to browsers that only implemented one half of event bubbling/capture!)

It's very difficult to remove an old workaround because

1. it's hard to be completely sure nobody actually depends on the workaround (especially given the wide variety of apps and environments Google supports -- Firefox aside, Google JS runs on a lot of abandonware TVs), and

2. it's hard to prioritize doing such work, because it's low value (a few less bytes of JS) and nonzero risk (see point 1) without meaningfully moving any metrics you care about.

In all, how to eliminate accumulated cruft like is a fascinating problem to me in that I can't see how it ever gets done. And it's not a Google thing. Even the newer cooler startup I now work at has similar "work around old Safari bug, not sure if it's safe to remove" codepaths that I can imagine will stick around forever, for similar reasons.

In a separate context I discovered the slow performance of addr2line and wrote my own faster one as a learning experiment:

http://neugierig.org/software/blog/2012/03/heap-profiling.ht...

I worked 17 years at Google on lots of different things and with one exception* never let work stuff interrupt my life when I wasn't at work. I certainly kept odd hours at times and would do things like stay late some days if I had broken something that I thought I could fix before leaving, but once I was done with work I was done.

* The one exception was when I was on a team where we had a rotating pager duty for our stuff in production, and I would periodically be on duty. As I recall we got paid extra for those time blocks.

If you're in the Bay Area and interested in an up close encounter with a giraffe, I recommend https://www.safariwest.com/ .

(Disclaimer: no affiliation, I just enjoyed my visits there. I also have done no research into whether the animals are mistreated or anything.)

If the order matters, it's only as hard as using a (different) data structure that preserves order.

To prevent these kinds of bugs, the iteration order in a Go map is randomized across each execution.

You are right, sorry for missing the third bug.

Chrome originally integrated RSS feeds in the new tab page, to show you when there were new posts on sites you frequently visited. We cut the feature just before launch, because it wasn't fully baked, and never resurrected it. (I know this because I worked on this code.)

With more perspective on the problem, I think the way we implemented it at the time was wrong, with the XML processing done in unsandboxed C++. At the time, Chrome didn't use any HTML for its UI like the new tab page, so only web content was sandboxed, but with today's perspective it's obvious to me you want to process XML content with the same sandboxing indirection you use for other untrusted data formats. So in retrospect I'm glad the feature didn't launch as it was, because it would've been a security disaster.

Also my recollection is that the code wasn't great. (I feel allowed to say that because I authored it -- I'm not slagging on my coworkers.)

As a former Debian enthusiast (I even helped staff a Debian booth at a conference once!) who also tends to be conservative with new technology and who is consequently also skeptical of all these random Linux distros, I eventually tried out Arch and found it ... super awesome, I really love it!

I highly recommend it to anyone else like me, who is generally cranky about new things. They did a really great job with Arch. This policy you mention is a great example of what I like about it.

I noticed that the two bugs they linked [1] [2] are both due to the distros introducing bugs by applying patches -- one for hurd support (!) -- that were not shipped by the upstream projects that the distros were repackaging. As we have discussed earlier [3] I think the way distros inject themselves into this software development process produces these bad outcomes due to getting the incentives wrong.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1679430

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1633467

[3] https://news.ycombinator.com/item?id=26216917

I have been collecting new shell ideas here:

http://evmar.github.io/smash/related.html

I'm not sure how you got from "Rust gives you more confidence but not absolute confidence and you still need the normal stable of runtime detection tooling" to "useless".