initplus

http.ListenAndServe is implemented under the hood with a new goroutine per incoming connection. You don't have to explicitly use goroutines here, it's the default behaviour.

Will be an underlying safety issue in some system library, but they have only seen "in the wild" exploits targeting Intel. "Defence in depth" - better to push the bugfix to all than to scrutinize ARM security features to understand if an exploit is possible there as well.

Yeah you can see the cooling requirements by looking at their product images. https://cerebras.ai/wp-content/uploads/2021/04/Cerebras_Prod...

Thing is nearly all cooling. And look at the diameter on the water cooling pipes. Airflow guides on the fans are solid steel. Apparently the chip itself measures 21.5cm^2. Insane.

It's not just that there are few signals to prevent the wrong person being put in charge, but this kind of government bureaucratic actively selects for the wrong person. These kinds of government IT projects are often soul sucking to work on, and so they attract a specific kind of applicant.

I mean they aren't designed for rack mounting? It's a consumer product, likely <0.1% of units produced will end up in a rack.

The port on the bottom is really the least offensive element of the design. I know people find it fun to clown on, but if any of them had ever used one for 5 minutes they would realize it's a terrible mouse for a bunch of other more important reasons (weight, feet quality, tracking accuracy, polling rate etc.).

Regulatory challenge is that the FDA have to combine 3 related but seperate concepts:

1. Manufacturing quality/ingredients accuracy (is the product what is says on the tin) 2. Safety 3. Efficacy

Medicines must pass all three, supplements don't have to meet any.

Given that experience, think about what state the alternatives must be in!

You'll likely run into frustrating app availability issues. Releasing iPhone apps on iPad is not universally done. (looking at you WhatsApp)

Court isn't the place for scientific inquiry into these issues. It's just not setup for it. French courts have also found in favor of "electrosensitivity" issues.

Sounds like a really interesting problem space. I'm curious if you have any comments about how you approached dealing with inconsistencies between information sources? System A says X, system B says Y. I suppose best approach is again just to bail out to manual resolution?

One example is that instead of adding support for edge case mutations/changes late in a process, it's sometimes better to force those records to be thrown away and reset with a new record from the start of the process. You avoid chasing down flow on effects of late unexpected changes in different parts of the application.

To give a contrived/trivial example, imagine a TLS handshake. Rather than building support to allow hosts to retry with a different cert, it's better to fail the connection and let the client start from scratch. Same principle can be applied to more complex process automation tasks in business. Imagine a leave tracking system. It might be better to not support changing dates of an existing leave application, and instead supporting cancel & re-apply. Best part is that the user facing part of both versions can be exactly the same.

It's not "until sales shows up", it's until regulators start causing problems for Cloudflare because you are using Cloudflare infra to host a grey market online gambling website.

Harder to justify contributing back when the open source project is so tightly coupled to your biggest for profit competitor.

Even grosser is that they explicitly limited the iOS version of Google Photos to refuse to work with scoped access. So on iOS the app will refuse to work without being granted whole library access, a permission that Google no longer allows to any third party photo app on Android. Blatantly anticompetitive.

I'm also completely sick of fielding API migration emails from Google on mobile Android/Firebase. Feel like I get some "action required" every couple of weeks. This stuff saps our resources, both to fix it, and to diagnose if the issue even applies to us in the first place. If you are lucky Google includes details of the app using the API, but often this part is even left out.

What’s crazy is the range on the liability estimate. Maybe there is a good reason for it. But 1b-10b is an absolutely massive window?

It does seem weird that there is this separation though. I would have assumed that there is a lot of overlap between machine design and operation.

More engineers doesn't automatically mean better software. Sometimes the opposite.

This is a rod Samsung has made for their own back though. Fewer SKU's, and more shared parts between models would be better for consumers and for the planet.

It seems that way because it kind of is. The early days of functional research were equally focused on designing alternative computer architectures that were more suited to functional paradigms.

Now that hardware angle has not been very successful on the whole, and we are left with languages that end up feeling a bit out of place on the hardware we have today.

Another thing to note is that there is a lot of untapped potential in fb compilers. It’s suffering from underinvestment.

The benefits from virtual threads come from the simple API that it presents to the programmer. It's not a performance optimization.

Channels and async/await aren’t really equivalent features. Beyond the fact that they both deal with concurrency.

You can do channels (message passing) on top of async await.

And that’s the upgraded version. Previously it just… wasn’t possible at all?

At least it's somewhat possible to reliably test behavior of these against GNU coreutils. Pull down some archaic C++ project with a pile of janky shell scripts involved in the build (Chromium might be a good target) and compare final results.

The original history behind a lot of original UNIX directory structure is engineers running out of disk space on a PDP-11 50 years ago and shuffling things around to keep the system operating. Other reasoning has been piled on top over the years.

Maybe my phrasing is not clear - I meant that these languages are indeed not significantly more productive.

Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. But that it can teach you worthwhile lessens about designing software that apply equally to imperative languages.

Modelling the business domain, reasoning and managing side effects, avoiding common imperative bugs, these are all valuable skills to develop.

F# is a great language to learn, and very approachable. Worst part about it is interacting with antiquated .NET API's. (I can't believe the state that .NET support for common serialization formats is still in...)

Difference is that Apple invested heavily in backwards compatibility, even old x86 code performs well on their chips. Meanwhile cell requires a reworking of your entire program to take advantage of it.

It’s less a confusing one off decision to use a weird architecture, and more a failure to reconsider the status quo and stop using weird architectures.

Previous PlayStation hardware was just as odd. Ps2 reused old surplus Ps1 processors just for audio, and had coprocessors just like cell.