Comments URL: https://news.ycombinator.com/item?id=48308739

Points: 2

# Comments: 0

Some of it is in pursuit of productization feedback. Some of it isn’t.

The general audience here is (or at least, used to be) tech enthusiasts, and you can usually assume that crowd will enjoy cool shit in tech.

Personally I’ve had to occasionally hand write x86 assembly for work on a handful of occasions to ensure certain runtime guarantees were met that the programming language i was using couldn’t provide directly. I’ve used it a ton in hobby projects because it’s just kinda cool, and i want to have a better understanding of that world.

I'd be doing the same kind of thing if I had more free time.

Some people call this "high-level," too.

I will say, though, that 2 million lines of code is much less code than it sounds like at first glance, especially for a company in a highly-regulated space like finance, plus a few years of progress.

Comments URL: https://news.ycombinator.com/item?id=47653299

Points: 4

# Comments: 0

Blending into rush hour foot traffic is easy, and I never feel like I stand out enough to attract attention... though in the back of my head, I know that most commercial and government properties have some form of video surveillance, probably backed by some kind of (hopefully coarse) AI subject tagging.

It's also important to consider that while many places have some legal framework along the lines of "no reasonable expectation of privacy in public spaces," there's a social-psychological gap between that and the presumption of being constantly recorded, be it by other private individuals or governments.

Because of this, my view on this technology is that it's a net negative in society, and generally unhealthy.

With purl, the web gets just a little less punk. Which is nothing new, unfortunately. I miss the times when people would put in stupid amounts of effort to stick to their principles in hobby tech.

There are more syntax features, more and more complex semantics, and while rustc and clippy do a great job of explaining like 90% of errors, the remaining 10% suuuuuck.

There’s also some choices imposed by the build system (like cargo allowing multiple versions of the same dep in a workspace) and by the macro system (axum has some unintuitive extractor ordering needs that you won’t find unless you know to look for them), and those things and the hurdles they present become intuitive after a time but just while getting started? Oof

    > but only spotty adoption

The amount of times I've had to translate an AMP link that I found online before sending it onwards to friends in the hopes of reducing the tracking impact has been huge over the years. Now there are extensions that'll do it, but that hasn't always been the case, and these aren't foolproof either.

I do hope this MCP push fizzles, but I worry that Google could just double down and just expose users to less of the web (indirectly) by still only showing results from MCP-enabled pages. It'd be like burning the Library of Alexandria, but at this point I wouldn't put the tech giants above that.

- Wanna subtract a string from a number? That's not a type error, that's a `NaN` -- which is just a perfectly-valid IEEE 754 float, after all, and we all float down here.

  - Hell -- arithmetic between arbitrary data types? Chances are you get `[object Object]` (either as a string literal or an *actual* object), which you can still operate on.

Frankly, while I haven't had a frontend focus in about 15 years, I struggle to think of any situation where calling a stdlib function or standard language feature would result in an actual exception rather than just an off behaviour that'll accumulate over time the more of them you stack on eachother. I guess calling an undefined variable is a ReferenceError, but beyond that...

(This comment shouldn't be taken as an endorsement of this school of language design)

While I'm not a cryptographer... I never really understood the appeal of these things outside of one very well-defined threat model: namely, they're excellent if you're specifically trying to prevent someone from physically taking your hard drive, and only your hard drive, and walking out of a data centre, office, or home with it.

It also provides measured boot, and I won't downplay it, it's useful in many situations to have boot-time integrity attestation.

The technology's interesting, but as best as I can tell, it's limited through the problem of establishing a useful root-of-trust/root-of-crypt. In general:

- If you have resident code on a machine with a TPM, you can access TPM secrets with very few protections. This is typically the case for FDE keys assuming you've set your machine up for unattended boot-time disk decryption.

- You can protect the sealed data exported from a TPM, typically using a password (plus the PCR banks of a specific TPM), though the way that password is transmitted to the TPM is susceptible to bus sniffing for TPM variants which live outside the CPU. There's also the issue of securing that password, now, though. If you're in enterprise, maybe you have an HSM available to help you with that, in which case the root-of-crypt scheme you have is much more reasonable.

- The TPM does provide some niceties like a hardware RNG. I can't speak to the quality of the randomness, but as I understand it, it must pass NIST's benchmarks to be compliant with the ISO TPM spec.

What I really don't get is why this is useful for the average consumer. It doesn't meaningfully provide FDE in particular in a world where the TPM and storage may be soldered onto the same board (and thus impractical to steal as a standalone unit rather than with the TPM alongside it).

I certainly don't understand what meaningful protections it can provide to game anti-cheats (which I bring up since apparently Battlefield 6 requires a TPM regardless of the underlying Windows version). That's just silly.

Ultimately, I might be misunderstanding something about the TPM at a fundamental level. I'm not a layperson when it comes to computer security, but I'm certainly not a specialist when it comes to designing or working with TPMs, so maybe there's some glaring a-ha thing I've missed, but my takeaway is that it's a fine piece of hardware that does its job well, but its job seems too niche to be useful in many cases; its API isn't very clear (suffering, if anything, from over-documentation and over-specification), and it's less a silver bullet and more a footgun.

Compiler development is (for better or worse) a niche that favours people who've got real-world experience doing this. The traditional ways to get in have either been through high-quality, high-profile open-source contribs, or because your existing non-compiler-dev job let you inch closer to compiler development up until the point you could make the jump.

As the author noted, a lot of modern-day compiler work involves late-life maintenance of huge, nigh-enterprise-type code bases with thousands of files, millions of LOC, and no one person who has a full, detailed view of the entire project. This just isn't experience you get right out of school, or even a year or two on.

Honestly, I'd say that as a 2023 grad with no mentors in the compiler dev space, she's incredibly lucky to have gotten this job at all (and to be clear, I hope she makes the most of it, compiler dev can be a lot of fun).