HNHacker News
TopNewBestAskShowJobs

joatmon-snoo

2,385 karma · joined December 1, 2015

hackernews[at]sxlijin[dot]com
submissionscomments
joatmon-snoo··on A study of Google's code review tooling (Critique)
As someone who left in 2021:

- OWNERS is absolutely a necessary and important thing, and yes it sucked when it made finding an approver hard, but the point of OWNERS was to optimize for _local_ ownership. (For non-Google folks: think CODEOWNERS files, but hierarchical/recursive, so approvers in /OWNERS, a/OWNERS, a/b/OWNERS, and a/b/c/OWNERS can approve changes anywhere in a/b/c/...)

- I joined in 2017 and it never took 18 months to get readability. If it took you 18 months, it was because you spent 2 weeks writing code in one of those languages and then didn't keep it up. I worked through the stats on this too- by the time I left in 2021, there was virtually no delay to enter the readability process for Java and it was maybe a few weeks for Python.

> There was no way to update every call site of your library in an efficient way.

Does FB have something better here?

G had sufficiently many tools for this, IMO: csearch+grep+sed for the easy changes, Refaster/clang-tidy for more complex stuff (admittedly C++ AST matchers are black magic that few people on even the C++ teams understood). Although I do wish I had known about Comby before I'd left.

Rosie - the tool for executing large-scale changes, i.e. if you made a change to 1K+ files (often 10K+ or 100K+), you needed a way to break the change up into multiple PRs - was also an absolutely critical part of this. I never found the approval process Byzantine - undocumented, perhaps, but remarkably streamlined considering that LSCs meant making simultaneous changes to code in Ads, Android, Cloud, Geo, Search, Technical Infrastructure, YouTube, or however Google breaks down the engineering these days.

joatmon-snoo··on Just how constexpr is C++20’s std:string?
This explanation from isocpp is the one that has always guided me:

   Read the pointer declarations right-to-left.

       * const X* p means “p points to an X that is const”: the X object can’t be changed via p.

       * X* const p means “p is a const pointer to an X that is non-const”: you can’t change the pointer p itself, but you can change the X object via p.

       * const X* const p means “p is a const pointer to an X that is const”: you can’t change the pointer p itself, nor can you change the X object via p.

    And, oh yea, did I mention to read your pointer declarations right-to-left?
https://isocpp.org/wiki/faq/const-correctness#const-ptr-vs-p...
joatmon-snoo··on Jared Diamond: A Reply to His Critics
This blog post seems more of a strawman to me than anything else; GGS has a poor reputation in historian circles because it doesn't approach historical analysis with a level of rigor appropriate for academia.

This quote[0] sums up things well for me:

> Look through any r/history thread mentioning Diamond and you will see dozens of people who find our critiques pedantic, and that, in a general sense, Diamond’s thesis makes sense. This is a very difficult attitude to address, because it’s rooted in a fundamental misunderstanding of how social sciences work. The attitude evaluates the ideas of popular authors from a utilitarian, practical approach: if the thesis is useful and helps makes sense of the world, it has value. We researchers take an inductive approach: if your methodology and facts are wrong, your thesis can't be right, no matter how much it "makes sense."

> For this reason, I’m kind of sick of talking about Diamond’s theoretical bents and ideologies. The standards by which scholars and the public evaluate them are so different that we have to address an entire epistemological orientation.

The "Diamond is a racist" argument is not one that historians care about. What they take issue with is:

* not questioning primary source bias (e.g. he takes Pizarro, Cortez, etc. at face value),

* exaggerating the role that disease alone played, as opposed to how disease amplified vicious cycles[2][3]

* made-up facts[0]:

> In a world where conquistadors bested Aztecs with with guns and Spanish friars set up missions in communities devastated by plague, Diamond’s arguments would matter. But this is a world where Tlaxcalans bested Aztecs, and Spanish friars set up many failed missions before gaining a foothold and witnessing entirely disrupted populations fall to disease afterwards.

[0]: https://www.reddit.com/r/AskHistorians/comments/6meq1k/comme...

[1]: https://www.reddit.com/r/AskHistorians/comments/2mkcc3/

[2]: https://www.reddit.com/r/AskHistorians/comments/8nr7xd/

[3]: https://np.reddit.com/r/badhistory/comments/2cfhon/

(Disclaimer: I haven't read GGS, nor am I familiar with the underlying theses. I just find myself fascinated by the controversy around the book.)

joatmon-snoo··on Twitter launches new Pro tier for $5000/month
A whopping additional app ID for the low, low price of an additional $4900/mo!
joatmon-snoo··on The seven programming ur-languages (2021)
It's talking about different families of programming languages, much like how we classify the different languages that people today speak[1]. I definitely got thrown off by the choice of terminology, but it makes sense once you go through the list.

[1] https://www.theguardian.com/education/gallery/2015/jan/23/a-...

joatmon-snoo··on Ask HN: Who is hiring? (April 2023)
Been here for (nearly) two years now - happy to answer any questions anyone has.
joatmon-snoo··on Treat your to-read pile like a river, not a bucket
I made it through eight books of Wheel of Time before I finally stopped reading the series.

... I don't know how I made it to #8.

joatmon-snoo··on Ask HN: Who is hiring? (March 2023)
Oof. Thanks.
joatmon-snoo··on Ask HN: Who is hiring? (March 2023)
Trunk | https://trunk.io | Sr Full Stack / Sr C++ | Full-Time | Remote / Hybrid, SF

Trunk is an a16z funded dev tools startup, redefining software development at scale. We've built three products so far and have plans for more:

  * Trunk Check: a universal linter/formatter, available as a CLI, VSCode extension, and CI check;
  * Trunk Merge: a merge queue, to ensure that PRs are tested in order before they're merged; and
  * Trunk CI Analytics: timing & pass/fail stats for GH Actions (e.g. "how often does this workflow step actually succeed?")
In 2022, we raised a $25M Series A led by Initialized Capital (Garry Tan) and a16z (Peter Levine) [1].

Our tech stack:

  * Frontend: Typescript, React, Redux, Next.js
  * Backend: Typescript, Node, AWS, CDK, k8s, gRPC, Envoy+Istio
  * Observability: Prometheus, Grafana, Kiali, Jaeger
  * CLI: C++20, Bazel
  * VSCode Extension: Typescript
  * CI/CD: GitHub Actions
  * General: GitHub, Slack, Linear, Slite
Unlimited PTO (and we all actually take PTO), competitive salary and equity packages! Please apply here: https://trunk.io/jobs

[1] https://blog.trunk.io/trunk-raises-25m-to-build-a-unified-de...

joatmon-snoo··on Ongoing Incident in Google Cloud
Ex-GCP here.

This is a pretty reductionist summary, e.g. the 8-day Cloud Networking incident root cause:

> Description: Our engineering team continues to investigate this issue and is evaluating additional improvement opportunities to identify effective rerouting of traffic. They have narrowed down the issue to one regional telecom service provider and reported this to them for further investigation. The connectivity problems are still mostly resolved at this point although some customers may observe delayed round trip time or longer latency or sporadic packet loss until fully resolved.

Still a big problem product-wise, but you're looking at a global incident history view without any region/severity filters.

The corresponding AWS service health dashboard makes it much harder to view this level of detail, but is also actually useful for someone asking "is product $xyz which I depend on in region $abc currently down or not"

joatmon-snoo··on Bifurcate the Problem Space
It's the same, e.g. the git bisect command is just a binary search API for a commit history.
joatmon-snoo··on Ask HN: Who is hiring? (February 2023)
Uh oh. Can you email me (sam[at]trunk[dot]io) so that we can follow up with you about what's going on here?
joatmon-snoo··on Ask HN: Who is hiring? (February 2023)
Trunk | https://trunk.io | Sr Full Stack / Sr C++ | Full-Time | Remote / Hybrid, SF

Trunk is an a16z funded dev tools startup, redefining software development at scale. We've built three products so far and have plans for more:

  * Trunk Check: a universal linter/formatter, available as a CLI, VSCode extension, and CI check;
  * Trunk Merge: a merge queue, to ensure that PRs are tested in order before they're merged; and
  * Trunk CI Analytics: timing & pass/fail stats for GH Actions (e.g. "how often does this workflow step actually succeed?")
In 2022, we raised a $25M Series A led by Initialized Capital (Garry Tan) and a16z (Peter Levine) [1].

Our tech stack:

  * Frontend: Typescript, React, Redux, Next.js
  * Backend: Typescript, Node, AWS, CDK, k8s, gRPC
  * Observability: Prometheus, Grafana, Kiali, Jaeger
  * CLI: C++20, Bazel
  * VSCode Extension: Typescript
  * CI/CD: GitHub Actions
  * General: GitHub, Slack, Linear, Slite
Unlimited PTO (and we all actually take PTO), competitive salary and equity packages! Please apply here: https://trunk.io/jobs

[1] https://blog.trunk.io/trunk-raises-25m-to-build-a-unified-de...

joatmon-snoo··on Analytics Solution for GitHub Actions. No Need to Run CI in the Dark
Trunk employee here - we're super excited about this launch!

We've got a few companies using it, and had other users in our community tell us "It's a very helpful tool that I didn't even know I needed". Even we ourselves have made a number of surprising discoveries about how often some of our hourly/nightly workflows have been failing by dogfooding this.

Let us know what you think! :)

joatmon-snoo··on Trash Train: I put my trash cans on rails so they move automatically [video]
Ah, so both of us were in the dark about the others' expertise - I hadn't really thought about the fact that FPS is basically a start-stop frequency in analog film.

> Film seems soft and easy to damage, but somehow all that seems to work anyway.

I still think it likely that force transfer relies more on the filmstrip, but I'm also assuming that the filmstrip stays under tension (the shock absorber in the Wiki link appears to be that slash a belt tensioner for the filmstrip).

(Also, I wasn't aware that Geneva drives had actual real-world use cases. Thanks for the Wiki link!)

> He 3D-printed the pinion gear out of plastic, which achieves that.

Yeah- this part actually surprised me a bit. Plastic gears are great for low-torque applications, but my understanding is that with high-torque/high-force applications, you start running into shear stress material limitations. This is one of those "just try it out and see how it holds up" questions.

I'll also say that when I read your suggestion, I was really confused because the first sprocket that came to mind was a bike sprocket... :)

(FWIW, I'm not a MechE, just a software person who spent enough of their high school years in a shop.)

joatmon-snoo··on C++ at the End of 2022
Standard updates, not STL implementation.
joatmon-snoo··on Trash Train: I put my trash cans on rails so they move automatically [video]
What you're describing is still a rack and pinion system, but likely to wear much more aggressively. I would be happy to be proven wrong, but my gut instinct is that such a system would wear out very quickly, because due to the involved forces, the sprocket teeth would wear out the holes really quickly.

Film, I would assert, works because the teeth just need to align the film; force transfer just uses the filmstrip itself.

Gear teeth are a reasonably complex design - settled, for the most part, I think, but still non-trivial - and do their job very well. It's a lot of "meshing together heterogeneous surfaces to maximize force transfer" problem solving.

joatmon-snoo··on C++ at the End of 2022
Far more likely to me is that bringing libc++ up to C++20 standards isn't important for google3. Carbon is a O(10y) project, not a O(3y) project.

  * absl strings provides the same compile-time guarantees that <format> does
  * absl date/time libs have integrations with the proto time types
  * google3 has many threading & synchronization primitives that it prefers over the STL types (all of which already has integrations with fleet-wide performance monitoring and other toolchain customizations, e.g. deadlock detection), so there isn't much reason to move the threading libraries forward
joatmon-snoo··on Up to the 1990s, raw salmon sushi was not eaten in Japan
There are still old-school sushi chefs who refuse to eat salmon. And the parasite concern was absolutely a major problem.

https://www.npr.org/transcripts/729396914

joatmon-snoo··on Golang disables Nagle's Algorithm by default
Filed https://github.com/golang/go/issues/57530.
joatmon-snoo··on Reinventing backend subsetting at Google
Thanks for confirming!

Yeah, the brevity thing is always tricky- the classic problem with any academic paper is that you need to assume your reader has some level of background that enables them to follow your reasoning; otherwise you end up derailing your paper by explaining too much of the background material.

FYI your claim re coordination isn't true across the board. The second option is used for some services (Slicer has an opt-in integration on the L2s).

(xoogler here ;)

joatmon-snoo··on Reinventing backend subsetting at Google
> in table 3

Figure 3 is an (arbitrary) example of round-robin sunsetting with randomized sunset ordering. The point is to demonstrate how bad backend churn is with this algorithm, by inspecting a normal example of the decisions this algorithm makes.

> The "same frontend task" as what? [...] what does this mean?

It's not phrased great, but it's also tricky to communicate. My read is this: given backend shuffles [9, 1, 3, 0, 8, 6, 5, 7, 2, 4], [7, 2, 0, 8, 9, 1, 4, 5, 3, 6], if you combine these shuffles to choose a backend assignment, you end up with subsets {9, 1, 3, 0}, {8, 6, 5, 7}, {2, 4, 7, 2}, {0, 8, 9, 1}, {4, 5, 3, 6}. That third subset means the third frontend only has a subset of three backends, even though you want it to have four.

The rest is reductio ad absurdum- reasoning through the ways you might fix this, and explaining why they in turn don't work. (I believe there's also an implicit assumption about the requirement that the final algorithm require no dynamic/runtime coordination, only static before-the-fact coordination amongst the front ends, i.e. agreement on a hash seed for a given subset, and say which hashing strategy the front ends would use).

joatmon-snoo··on Golink: A private shortlink service for tailnets
This made me wonder what the oldest go-link (from inside Google) discoverable on the public internet is. The earliest I've found is from Nov 2009: https://github.com/google/closure-library/blame/11ed104958a2.... (The second closest I've found in another repo is in RE2 from Mar 2010, https://github.com/google/re2/blame/954656f47fe8fb505d4818da... - and yes, both of these existed prior to the listed date, but I'm going off associated timestamps.)

(Fun fact: go-links are so critical to Google ops, that they're expected to be accessible in a "everything is down" scenario.)

joatmon-snoo··on Mozilla moves to distrust the TrustCor CA
> The whole thing is guilt by association. Everyone agrees that no evidence of mal-issued certificates exists. But some other company that uses your CA product had a rougue dev and because they are financially related because of history all of a sudden the industry is in panic?

No. The problem is that the entity in question is a root CA, and there is an expectation that root CAs demonstrate behavior befitting the trust given to them.

> But all I saw was a person rightfully defending rather unsubstantiated attacks on the integrity of her business.

If all you do is skim the thread and avoid actually reading the walls of text, sure.

But if you look more closely at the TrustCor replies... wow.

This response to TrustCor sums it up pretty well: https://groups.google.com/a/mozilla.org/g/dev-security-polic...

> It has never been the case that compliance with a narrow set of rules creates trust in a human endeavor. The decision to trust a CA is an ongoing one, and the behavior of its representatives is evaluated in that light, as representative of the attitude taken by the organization to its responsibilities. Your aggressive bloviation and evasion contrasts quite negatively to the openness with which other CAs have addressed issues before, and is most certainly affecting the trust that I would consider reasonable to place in TrustCor.

Here are some choice highlights from TrustCor's responses:

1- starting their email response with an (unjustified) ad hominem attack on the researchers

> Interesting that this is the first time you or anyone else in your research group has reached out to us, except if you count the Washington Post journalist who claims in his article that we did not respond, which is one of the many false claims made in the article since we responded very quickly to his contact. And before I begin, you should probably clarify if your views are representing The University of Calgary’s views, The University of California at Berkeley’s views, or your commercial endeavor AppCensus’s views, or your views representing any customer, agency, etc…? If in fact these views are completely independent and personal, that is also helpful to note.

2- suggesting that TrustCor is a more reliable CA than Google is, based on Gmail being a "high volume spam sending system"

> In Response to Ryan’s (Google) Additional Observations [...] Unfortunately, [MsgSafe.io] and frankly all free or low-cost email service providers, are often used by ransomware developers because of how they lend to privacy and anonymity, and how easily they can be obtained. (examples of gmail being the most popular across ransomware attacks [1], [2]). [...] we took an extra step to check constantly for receive-rate abuses when spammers send mail through another high volume spam sending system such as Gmail,

3- going on a long rant about being singled out, when everyone is primarily repeating "please clarify your corporate structure and stakeholders to us, because you keep dodging the question"

> In reading related reporting and blogging off-list, I need to address an elephant in the room. Apparently it may also come as a surprise to some readers and the researchers themselves that other root program members are in fact international governments, and some are also defense companies, or companies who are wholly-owned by defense companies and/or state-owned enterprises, meaning "businesses" that are completely owned or controlled by governments. Further, some of those governments are not free/democratic and in fact some have tragic modern histories of basic human rights violations. We are none of those things and our company does not identify with those values. Given this point above, why of all potential targets are these researchers interested in TrustCor? They could go after countries with human rights violations that have placed a CA in the program. They could go after countries that suppress free speech that have placed a CA in the program. They could go after companies that are smaller CA/issuers than us, or much larger ones. They could go after CAs that are actually state-owned enterprises (owned by governments). But they aren’t. So why? Why choose to spend their time on this and on us in particular? We’ve been asking ourselves this since it began. We’ve only come up with 2 possible answers. (1) They saw that single domain name in an old registrar account and simply fell into recursive confirmation bias to assume everything stemmed from that... or (2) They make money in their for-profit enterprise if they can find any American nexus, so they can involve the American government and the FTC and create pressure with American journalists. Well, this mystery solves itself. They do get paid by FTC in their own web of companies. They do tip American journalists using their university affiliation and then plugging their company in the articles. And their American customers apparently don’t reward them to go after foreign companies. So this represented a great opportunity for them if they could prove the American companies they saw had anything to do with us — unfortunately for them, they don’t. We are not an American company or a company owned by Americans. If they’d known beforehand, they’d have probably paid no attention just like they’re not paying attention to other program members who literally are governments or state-owned/defense companies. I think this is all about self-aggrandizing: getting themselves and their company known, and about making money. These guys are in business, and they’re bullies. They wear the hat and shirt of university researchers from different multinational universities and yet they’re involved in the same startup company/business and other related businesses that benefit financially from the exposure and follow-on work, and they’re misusing this platform and betraying the purpose of this mailing list. It’s also worth noting: the researchers followed no semblance of responsible disclosure processes which are well established in the industry. They never attempted to work with our product team or management to express their concern, or suggest improvements, or discuss potential vulnerabilities. Instead they opted for maximum public impact and attempted to pressure this industry body with journalism following their sensational false narrative. They were even able to get an American journalist to publish a story without proper fact checking, and without speaking to any representative of our company even though two of us responded to the journalist immediately. Our CTO provided proof of this in writing in his letter with screenshots.

joatmon-snoo··on Ask HN: How do I write a Linux driver for my 15 year old photo printer?
There's a big difference between "I want to make <thing>" and "I want to do <thing> that experienced individuals who know this rabbit hole and enjoy similar things but are scared of <thing>".
joatmon-snoo··on Launch HN: Taro (YC S22): Private career growth community for software engineers
Interesting! This reminds me of /r/cscareerquestions: both the good and the bad.

Good: you're trying to create a space where a lot of people have similar professional goals and can riff off each other.

Better: the two of you have a lot of content backed by your own, verifiable, professional experiences.

Bad: why would someone qualified to give advice want to join the community? What prevents your forums from devolving into the blind leading the blind?

Case in point: your video on "why you should start your career at a big tech co" is very clearly driven by your own personal experiences. At one point you allude to optimizing for compensation, but you don't discuss fintech options (Jane Street, Citadel, etc.). Skimming through some of your comments on other threads, I also just don't see a lot of respect for the nuances of different folks' individual circumstances: understandable given that you two are a finite resource, but you also need to attract users who can give that advice, and I don't see a carrot there for me.

joatmon-snoo··on An ex-Googler's guide to dev tools (2020)
Bazel by itself is not nearly as useful as Blaze (the Google-internal version), in large part because of how standardized the internal ecosystem was around Blaze. A few reasons (non-exhasutive list):

- Blaze defaults to building everything remotely, on a massive farm of build servers. (This farm was sizeable enough to have its own capacity planning teams. Yes, plural.) There are a few startups trying to clone this SaaS for Bazel, but it is - predictably - not easy.

- Since all builds were remote, build _telemetry_ was also uploaded and available on the intranet. This meant that if you wanted to ask someone "hey, my build failed, can you help", you could literally send them a link "https://google-build-system/00000-11111-22222-the-rest-of-my..." with all the information about your build: the thing(s) you were trying to build, the options you were building with, all the foreign keys you needed to look up build timing data, etc. You could also query company-wide build telemetry data to see what people were building more frequently than others, if specific areas needed engineering investment, etc.

- Since builds were remote, they pretty much had to be hermetic and reproducible, which meant platform teams - e.g. C++ team, Java team, Python team, Go team, etc. - could make infra-level changes and test out the effects on various teams. This is a very Google-scale specific need: allow another team to do your infra maintenance for you, i.e. upgrade the Python runtime underneath you. (Yes, this comes with caveats. Google eng tends to live at head, so while there are "my team needs to control our rollout to the latest infra version" concerns, there is a consistent mandate for most teams that "upgrading to the latest infra that we run on" is a priority.)

The big place where problems came up was when source code needed to exist _outside_ of google3: open-source repos, for instance, very frequently have to do a delicate dance of figuring out (1) is their primary source of truth going to be inside google3, where the tools/infra are uniform and Better TM, or on github/etc, where they have to configure their own test stack, CI stack, etc., and (2) what are the downstream implications of decision (1).

joatmon-snoo··on Toyota’s Chief Says Electric Vehicles Are Overhyped (2020)
Distribution is also a big issue now: EV chargers have a much bigger ecosystem around them than hydrogen fuel stations.
joatmon-snoo··on Tell HN: I DDoSed myself using CloudFront and Lambda Edge and got a $4.5k bill
If there were hard limits, that would also mean that the billing system is on the critical path for all systems, and not just an after-the-fact ETL.
joatmon-snoo··on Google Cloud: Major packet loss between multiple regions – Europe and Asia
I think there's a /s on the comment you're responding to :)
← PreviousPage 3 of 18Next →