yazaddaruvala

I feel you may not be reading or following this conversation.

My point is: Taiwan cannot make "decent chips" without the cooperation of the US and EU. China may possibly be able to without the US and EU, but roughly no other country could even try to build "decent chips" (i.e. EUV) without the help of the US and EU.

I was responding to:

> Many countries could have the capability to produce decent chips.

China might be able to, lets see. "Many countries" definitely not.

Sadly, Mumbai already works this way.

The “toll” to be on the bridge is the cost of ownership of motorized transport. Wealth segregation by neighborhood is also a thing. This segregation is executed similarly to how it is in North America or Europe.

FWIW, in Mumbai they differentiate a bridge to be road over water and a flyover to be road over other road or residence.

Taiwan relies on Europe to supply it with EUV.

Building the entire supply chain for semiconductors is daunting at best.

Have you ever been to Mumbai? Have you been inside their newer luxury buildings?

It has many issues, but the modern tall buildings in Mumbai are amazing and are the solution to many of their issues.

If the US would start to build new buildings like Mumbai or Singapore more Americans would realize just what luxury and space a condo could have!

Mumbai needs more walkability (through super blocks and such), better trash etiquette (more trash cans - especially for the middle classes new fascination with dogs), and it needs 1000x more livable square feet.

> How easy is it to add Rust to a C++ code base? If the answer is 'not at all',

Its not clear that you even read the linked post on GitHub before commenting.

The first post in that GitHub thread says: "This should be thought of as a "port" instead of a "rewrite" because we would not start from scratch; instead we would translate C++ to Rust, incrementally, module by module"

> then the transition is unlikely to happen anytime soon (it hasn't happened in the decade that Rust has been around)

As of a year ago, 10% of FireFox had been ported over (https://news.ycombinator.com/item?id=30744057). This is the overall effort started in 2014 https://wiki.mozilla.org/Oxidation

> This is a completely false take. AWS was built from the ground up as separate infrastructure.

Your comment above doesn’t seem to reflect that history, so I just wanted to make sure it was stated.

AWS is also entirely built on Amazons builder tools like Apollo and Pipelines. So it’s really unfair to say “AWS was built from the ground up”

AWS was re-built from the ground up. Based on systems Amazon knew it already had and how to do better.

S3 was built from the old image hosting designs, but better.

StepFunctions and SWF before it are re-designed based on the 5 internal workflow engines that existed (and still do exist).

SQS is a re-do of AMP.

DynamoDB is a re-do of Sable.

Redshift is a re-do of their internal partitioning and querying of Oracle databases but on non-Oracle databases. Their new iteration of Redshift is designed to replicate Andes + Dryad/Cradle.

It is not secret. There is an internal spreadsheet that documents all the prices.

Everyone has access! Everyone I worked with at Amazon knew the prices they were spending for the different services they were using or thinking of using.

I don't mean to diminish any of your achievements. Shipping amazing products is orthogonal to creating a robust codebase/system.

I also don't mean to be negative towards you or your experience. Instead, I'll pose the question to you: What would you call a team/system that describes itself as "at risk of being crippled by a single line change like adding a metric"?

At the end of the day, the product is the only thing that matters and you can be and should be proud of the products you've launched. That said, are you proud of the way you and your team built them? Have you or anyone on your team proclaimed it was a joy to build/improve that product?

idk... after all I'm just some guy on the internet. Best of wishes to you! I truly hope you did not, do not, and never do work on a dysfunctional team/system.

If adding a few counters to your code base cause any of these issues, your current team is already dysfunctional and will get more productive my improving the system.

eg “Metrics server goes down” metrics should be sent pre-aggregated, and in batches, even possibly polled for. Having 10 metrics that fire 10^N times a second shouldn’t impact the metrics server, ever! Metrics servers are impacted by cardinality, so yes don’t create 10^N unique metrics.

eg “something that fires 1000times a millisecond” if the rest of the team doesn’t know where their hot-loops are and has them commented or caught in a code review, it’s very likely someone will add some logic to it that will hurt. The metric is just one such change, and might as well find out sooner than later. If it will cripple your service, that is why CI/CD encourages canary deployments / other automated performance testing.

eg “metric causes a deadlock” - umm, this is just too contrived. I’ve never used or heard of any metric library that was built this way. This type of metrics client would cripple even a very experienced developer on that team.

Summary, if adding a metric can cripple your service or team, reconsider priorities. It will speed you up even in the medium term.

If you have the time to create a “curated onboarding experience that results in progressively more expertise”, yes I agree please do that instead.

I’ve never onboarded to a team that had such an experience, I’ve never heard of a team with something like it consistently, every time I’ve seen it proposed and tried it takes time away from an experienced person (who could have done those same tasks faster) and goes out of date as soon as one new teammate completed the curated set of tasks.

If you can make it durable, my utmost respect!

In the meanwhile, deleting obviously dead code has never failed me as a strategy for myself or a new hire (typically steered by a simple oncall-type task to start the investigation off).

And best part, there is always more to clean up for the next new hire lol.

> And no one pushes code to production to validate assumptions.

I always have, with the rare issue occurring and by and large rewarded for it.

> Documentation is not just for noting things down pedantically but also a thinking tool and a temporary thought buffer.

Sure, but why not treat your codebase as a temporary thought buffer? I do, and it’s consistently worked and improved every system I’ve worked with. No teammate has ever complained about this strategy. If anything it’s typically adopted by teammates.

eg “oh this list is never modified” rather than taking a 2 line note, I’ll push a code change to use an ImmutableList.

The knowledge is now documented, enforced by the compiler/code reviews if the type changes people talk about it, and allows me to keep improving that part of the code base months later without code conflicts or needing to re-make my changes from a notes file.

1-2 line reactors - exclusively better than 1-2 line notes. This scales to any number of lines where the size of the note is equivalent to the size of the possible code change.

Meanwhile, please do take notes and document when it’s at least 10x shorter to grok than the current code or possible code change.

Most of this makes sense, but ends up not being followed for non-technical reasons like the person's confidence, etc.

I'd say, just know two things:

1. (From the post) "Let your instincts guide you if you think something feels much more difficult than you’d expect", and talk to your team about it, and change it for them.

2. There is a LOT of dead (unreachable / redundant) code in any enterprise codebase. Especially recently launched flag that haven't been "cleaned up yet". Just start cleaning this stuff up. Even the very obvious stuff gets you very well introduced to the codebase.

Where I disagree with the post:

> Taking notes is non-negotiable for me, not strictly as a memory aid, but as a means to communicate findings and verify them later.

If you need to take a 2 line note, you're better off having written a 2 line code review. Even something simple like "metric.add("DOES_THIS_HAPPEN?", 1);" can be done with 0 confidence / testing or with minimal-confidence / minimal-testing you could instead write "Preconditions.checkState(..., "Will this be caught by our integration tests?");". The best notes are the ones that get pushed to production to validate assumptions.

Create High-density Land Use taxes that roughly force people to sell parking lots and gas stations and other small buildings for tall housing developments?

Enforce super blocks that are equally residential as they are comercial? ie if X job spaces exist in a super block there should be slightly more than X bedrooms available in the same super block.

Target 100x more sqft by 2030? Instead of targeting 1%^7 more sqft by 2030

Fabrication (or the loss of access to it at an affordable price) is an existential risk for every IAAS provider!

Lets forget about WW3, but even the risk of a TSMC monopoly (or rather a TSMC+Apple monopoly) and price gouging is existential enough that Amazon has plenty of risk sitting on the sidelines regarding fabrication.

It would be very inline with AWS to start fabrication as a service to avoid this existential risk. They can always start with easier node sizes for SSDs / DDRs / networking / automotive chips / etc. Even if only to self-source, Amazon alone needs a roughly-infinite supply of these speciality chips. Even totally new innovation that "only Amazon-types" need, like a Silicon interconnect the size of a Datacenter Cabinet (if the yield is reasonable) would be interesting to see.

They could even make a play at SiC chips[0]. If they can make it cheap and at small enough node sizes, I'd love to see what innovation SiC could bring to datacenter design. eg more efficient power supplies of each server/rack/cabinet.

[0] https://www.investors.com/news/technology/silicon-carbide-ch...

Probably just another data center.

But instead I’ll take a leap and predict:

This is Amazon moving into not just designing Graviton but also vertically integrating silicon fabrication (for CPU, memory, and/or storage) into their portfolio.

You really need to be practicing more of these breathing techniques :)

You're right that adding dependencies is easy, but you're significantly downplaying the discoverability of quality crates for specific usecases.

When people say "we need a rich standard lib" they are more interested in a "blessed set of crates" than a "it should be pre-downloaded with the compiler".

You really shouldn't be getting downvoted.

The super majority of us eat meat! We are all complicit to (even encouraging of) the mass execution of these animals. It has to happen somehow - none of which would be pleasant to read about.

Thank you for describing your experience. Yes its a shitty thing to have had to normalize, but you're right it does sound like a decent enough method of mass execution.

Anyone that wants to instinctively downvote the parent comment, please reconsider. Its hard enough to need to be a part of this normalization, let alone get negative reinforcement for something the super majority of us positively reinforce at the grocery store.

I think the philosophical questions here are very interesting:

1. What should be the end result of capitalism’s goal to convert human effort into durable societal infrastructure? Should it be to create heaven on earth? ie. an elimination of scarcity and a control over entropy?

2. Does heaven require an omniscient, omnipresent god? If it does exist, should we aim to destroy it to “improve heaven”? If it doesn’t exist, should we aim to create it to “improve heaven”?

The problem may be disk speed, but I agree it may not. The problem I see is the dropping of state.

Specifically, to produce a .o file the compiler has already read through and created indexes of module::function/struct names, their layouts, dependencies, etc.

My understanding is that the .o files need to be re-parsed by the linker to create these indexes, layouts, and dependencies. Especially with LTOs I'd imagine there would be additional inlining work (stuff the compiler is already good at).

This is all just wasted time, including the IO bottlenecks - even if those are marginal.

> A lot of people don't own/live in a house in Europe,

Ok fair enough, I shouldn't have said "on your house".

The point of my comment was the decentralization of energy production and storage. i.e. "Cost of charging an EV is bounded by the ability to add solar panels to [someone's] house [, relatively nearby]". e.g. please look into https://www.energy.gov/eere/solar/community-solar-basics

For as many people in the city that cannot add solar panels, there is land owned by someone who is very happy to install solar (with your money - as an "investor"), generate an excess, and sell it to the grid. It seems very unlikely that "the invisible hand of the free market" will result in higher cost of electricity for individuals.

Additionally, from 2019: "Under the 25-year contract with developer 8minute Solar Energy, the Los Angeles Department of Water and Power would pay less than 2 cents per kilowatt-hour — a number city officials and independent experts say would be the lowest price ever paid for solar power in the United States, and cheaper than the cost of electricity from a typical natural gas-fired power plant."

https://www.latimes.com/environment/story/2019-08-27/los-ang...

“unlikely” based on what?

Your narrative is counter to the industry’s expectations of itself. Your narrative is counter to the research and science already showcased in labs.

So I just want to understand your perspective better. What sources are you using to justify “unlikely”, or are you using intuition?

Keep in mind exponential curves are very hard for humans to grasp and even harder for humans to believe, but the super majority of the time those curves hold for many decades.

That is my preferred outlook yes :)

But it is backed by the data. Check out my other responses.

If you’re either “realistic” or pessimistic, what about the data and trends we already have doesn’t convince you of a giant cost reduction over the decade to produce batteries?

The technology is just too distributed already for any of that to happen.

Cost of charging an EV is bounded by the ability to add solar panels to your house (currently solar installations “pay for themselves” in 7 years in Seattle - not so sunny - high cost of labor location). The grid and “free market” have to be able to compete with that for cost.

Batteries like solar panels are very cheap to transport. They are flat, they can easily stack, there is no expiration period, and no temperature regulation needed to transport them. Batteries will be produced globally if the local markets start gouging.

Solar panels are already a great example of this cost reduction curve. So I’d say your outlook is very pessimistic and not backed by the data.

This is the trend, backed by all the data and the expectation of the industry. Why do you think otherwise?

https://ourworldindata.org/battery-price-decline

https://corporatefinanceinstitute.com/resources/management/e...

https://en.m.wikipedia.org/wiki/Experience_curve_effects

If you’re familiar with Moores Law, that is an example of an experience curve.

The best part about exponential curves:

By the time the battery needs to be replaced batteries will be 90% cheaper.

Thank you the distributed compile usecase is a fun one to think about. I can see why it would require some intermediate set of bytes to shuffle across the network.

> Being backed by disk locally mainly helps for incrementally building so that you can change one file and only recompile intermediate files for translation units that depend on this file.

For the local incremental usecase I’d love to see a more state-full compiler instead. One that could change the bytes of a binary instead. e.g. give all functions some additional “empty padding”. Then any modifications could directly fit into the binary as needed until some defragmentation process which creates the final output binary.

To reduce the latency of compile-link-test