> My overarching sense is that this whole saga has been largely Mr. Alexander’s fault and it could have been easily avoided.
> Alexander has dropped the Mother Of All Bombs on this situation, displaying disrespect towards the reviewing industry, and regarding reviewers as trivial annoyances that can be easily brushed aside. The outcome of this saga and who will ultimately withstand the fallout remains to be seen, but Mr. Alexander almost certainly looks like an ass at this moment in time, and in my opinion, any negative assessment he receives is largely self-inflicted.
>There’s no doubt in my mind that Eric Alexander of Tekton Design is largely in the right, and in principle, challenging these reviewers was mostly justified.
The next sentence is revealing though:
>The problem, and the reason we’re here now dwelling on it, is how he went about it.
I'm not sure if I understand the first of the quotes, honestly, given the rest of the content. But that seems to be what GP was referencing.
They are starting to outcompete Hollywood on quality (see Godzilla minus one, Squid Game, Parasite, etc), they just don't have the hundred millions of dollars of marketing budget that Hollywood has to push and advertise their movies in foreign cinemas across the world, nor do Americans have a huge appetite of watching movies with subtitles, nor could they read even if they wanted to ("54% of adults have a literacy below sixth-grade level"[1]).
There isn't much need for many applications to know or care what IP protocol they are speaking, they are all just writing bytes to a TCP stream. I think the parent is saying that existing socket abstractions meant that these applications still had to be "upgraded" to support IPv6 whereas it could/should have been handled entirely by the OS with better socket APIs.
I love all this native tooling for JS making things faster.
I kinda wonder, though, if in 5 or 10 years how many of these tools will still be crazy fast. Hopefully all of them! But I also would not be surprised if this new performance headroom is eaten away over time until things become only just bearable again (which is how I would describe the current performance of typescript).
Even if they freeze typescript development after the native implementation, given that the current performance was apparently acceptable to the current users, type complexity will just grow to use up the headroom
Plus, using TS directly to do runtime validation of types will become a lot more viable without having to precompile anything. Not only serverside, we'll compile the whole thing to WASM and ship it to the client to do our runtime validation there.
> I'd also consider going a step further by only permitting server or resource access based on client certificate validation
This is where I'm the most curious on what Tailscale will do next. So far all their products seem to contrast at the IP level, but for enterprise use cases there's a real need for application level protections as well. Cloudflare Access is a great example of what I mean.
> Never check strong_count to see if you are "the last owner".
This made me think of the `im` library[0] which provides some immutable/copy on write collections. The docs make it seem like they do some optimizations when they determine there is only one owner:
> Most crucially, if you never clone the data structure, the data inside it is also never cloned, and in this case it acts just like a mutable data structure, with minimal performance differences (but still non-zero, as we still have to check for shared nodes).
I hope this isn't prone to a similar race condition!
The way to do this while avoiding race conditions seems to be `Arc::into_inner` or `Arc::get_mut`; for instance, the docs for `Arc::try_unwrap` mention a possible race condition, and recommend using `Arc::into_inner` to avoid it: https://doc.rust-lang.org/std/sync/struct.Arc.html#method.tr...
Standard practice in protobuf is to never assign semantic meaning to the default value. I think some linters enforce that enum 0 is named "unknown" which is actually more semantically correct than "other" or "unspecified".
> Just yesterday we were working on important projects, including improving access to weather data with NOAA, making it easier and faster to get a passport with the Department of State, supporting free tax filing with the IRS
I use words like those when justifying a timeline extension and CR (change request) to clients. I’m not saying it isn’t true but give me something more specific because I know this game.
If you don't cook, it is very easy to spend $1000+ on food in a month, especially if you live in a high cost of living area.
I'm single, live alone, work a lot, and earn a lot. Food delivery apps are hella expensive... but I still pay it quite frequently. Yes, I am ashamed, thanks for asking.
Interesting choice to support Rust over Go if you ask me. Don't have numbers but I don't really peg Rust as a popular language for serverless web apps, certainly not to the extent of Go
We ran our whole platform, written in Rust, in the Cloudflare Workers. It was not a great experience. You need to use their SDK, with really interesting bugs that never got fixed (we always forked a version). It was pretty hard to test anything locally, you just had to deploy your code to their platform, which took time and made the feedback loop to take so much time it blocked us from delivering features fast enough.
And yes, you can test your local Rust code. It works nicely on your machine, but breaks with a really nasty error on their platform.
The target is `wasm32-unknown-unknown`, which allows you to use `fetch` as your only source of IO. Ok, their workers has a hacky socket implementation nowadays. Non-standard of course. And most of the ecosystem won't work really without forking everything and fixing the bugs by yourself.
We pivoted to a native Rust project. We still have one worker running in Cloudflare. We isolated that code from the workspace so that renovate updates will not touch it. You know, a random version upgrade might break the service...
> My overarching sense is that this whole saga has been largely Mr. Alexander’s fault and it could have been easily avoided.
> Alexander has dropped the Mother Of All Bombs on this situation, displaying disrespect towards the reviewing industry, and regarding reviewers as trivial annoyances that can be easily brushed aside. The outcome of this saga and who will ultimately withstand the fallout remains to be seen, but Mr. Alexander almost certainly looks like an ass at this moment in time, and in my opinion, any negative assessment he receives is largely self-inflicted.