kettlecorn

The problem with your argument is why would people buy cars if they were so terrible? While the infrastructure was obviously worse than today clearly they afforded tremendous advantages which motivated their adoption!

In the early days that advantage was the ability to rapidly traverse relatively developed areas with more convenience. Over time infrastructure and adoption chased each other, but now the most populated parts of the US are developed to the point that there's little way to ease congestion with more road infrastructure. The only way to grow is to sprawl into new cities.

For a long time in population centers the pattern was new car infra. -> more driving convenience -> more cars -> repeat. In cities that's running into bottlenecks.

Today people primarily buy cars out of necessity, but in areas where most people live congestion and a more sprawling environment has diminished much of the time saving advantage.

I have a very loose mental framework for thinking about cars that I think is helpful:

If you look at space taken up length-wise in a lane the length of the average car in the US is 14.7 ft. For a person standing on a sidewalk the average person's foot size is ~10 inches. Let's hand wave the math and say cars are 10x longer.

Very loosely our built environment scales 10x to match that new scale. Roads need to be 10x bigger, parking lots take up even more space.

The ultimate result is not that there are far more unique destinations available to the average person, but that they are further away, bigger, and costs are far higher.

Before car usage approached 100% it would have been a tremendous gain to be one of the early car owners. The environment would have been built for a smaller scale and you would have been able to traverse it rapidly. For day to day life in well-populated areas that advantage has substantially eroded.

It's a clear example of the tragedy of the commons.

> One of the interesting tradeoffs in programming languages is compile speed vs everything else.

In the case of Rust it's more of a cultural choice. Early people involved in the language pragmatically put everything else (correctness, ability to ship, maintainability, etc.) before compilation speed. Eventually the people attracted to contribute to the language weren't the sort that prioritized compilation speed. Many of the early library authors reflected that mindset as well. That compounds and eventually it's very difficult to crawl out from under.

I suspect the same is true for other languages as well. It's not strictly a bad thing. It's a tradeoff but my point is that it's less of an inevitability than people think.

Fantastic!

Looks very cool! I can see myself using this for some Wasm experiments.

Please add a license so it's clear how people can / can't use the project!

Specifically I submitted this to draw attention to the latest comment in the thread: https://github.com/WebAssembly/threads/issues/177

It's a good deep dive into how a small, but well-intentioned, browser choice nearly a decade ago led to poor outcomes for the WebAssembly ecosystem.

Can Onyx's compiler be compiled to Wasm to itself run in the browser?

It's niche, but I've thought it'd be cool if there were a mini Wasm-based game building tool in the browser, but that requires a Wasm language with a compiler that can run in the browser.

Bad taste is irreparably laced through Microsoft's culture. It's why I've stopped using their products.

When I worked there the job of PMs, and many managers, seemed to be to figure out how to appear polite while attempting to distort common sense to get their metrics pumped up.

WebAssembly doesn't provide any new functionality much in the same way cars did not when compared to horse-drawn carriages. You can argue that everything you can do with Wasm can be done with JavaScript, but often it involves significantly greater effort.

Where Wasm is a massive improvement:

* Ability to use existing C++/C/Rust code without a rewrite.

* Performance consistency through languages with manual memory-management and more straightforward performance characteristics.

* Performance of working with multithreaded code by using languages that can pass pointers and avoid message-passing overhead.

* This last point is somewhat unproven as it's related to my own personal work, so take it with a grain of salt! Wasm has unique properties that allow it to be augmented to run complex, seemingly unnetworked, code perfectly synchronized between computers with very little latency in the UX. I'm convinced it can eliminate a whole class of complex networking / sync issues. I first demonstrated the concept earlier this year with tanglesync.com, but I'm currently working on a follow-up.

> Unfortuately the API for doing so on the web is extremely clunky, passing messages back and forth between a page context and a worker context.

This is one of the advantages to using WebAssembly: you can use a language like Rust that makes multithreaded code easier to write and faster to run.

Out of the box with JavaScript if you want to share an object with a worker you need to send a message (which internally serializes / deserializes the object) or manually manage serializing / deserializing bytes to a SharedArrayBuffer.

With Rust/Wasm + Web Workers you can use Rust's synchronization primitives and just pass a pointer to the worker. You pay no cost for serialization / deserialization.

> if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly.

As you pointed out the JavaScript VM is incredibly optimized but where Wasm shines is consistency. JavaScript requires some care to not produce garbage every frame, otherwise you may unpredictably trigger a lengthy garbage collection. With most Wasm languages you can easily avoid allocating any JavaScript garbage.

The lower-level Wasm languages also tend to be easier to reason about performance. When assessing Rust code performance you typically want to look for Big-O and excessive memory allocations. If you do find a performance bottleneck typically you know where to try to improve. With JavaScript you'll sometimes hit situations where you fall off the VM's golden path, or where one JavaScript VM performs fine and another does not.

By lean I mean the OpenUSD Wasm binary is over 10mb, last I checked.

This is the dark secret to USD: pretty much everyone is relying on the same massive C++ project!

Projects that want leaner dependencies, like everything on the web, don’t yet have a good way to work with USD.

The Wii sold ~101 million units (the Switch is currently at ~120 million) and its two mainline Zelda games sold 7.4 million and 3.67 million.

Contrast that with BOTW at 30 million and ToTK at 10 million in 3 days.

It frustrates me that nobody seems to think about the cascading effects of subsidizing roads and highways with taxes.

The heaviest users of highways are large shipping trucks and through our taxes we're all subsidizing business models that rely on that infrastructure.

Think about how local businesses, like local farms, are disappearing left and right because they can't compete on pricing and convenience. How much more competitive could they be if we weren't all charitably subsidizing infrastructure largely used by their competitors?

You're arguing against an imagined extreme. Nobody is saying "eliminate streets".

The closest thing to 'eliminating streets' you see people advocating for is streets in urban cores that are pedestrian / bicycle first and car second.

Deliveries can be still go down those streets at off hours and slowly. If necessary emergency vehicles can still access those streets and turn on their sirens to clear people out.

London and Europe have tons of streets like that and most US cities have none.

I did not say that the Zelda franchise has sold poorly, just less well than BOTW / TOTK.

I don't think attach rates offer the full picture. Early on the audience for BOTW was so eager for the game they were buying the Switch just for BOTW. For a period the attach-rate was greater than 100%! But the Switch has broad appeal and the attach-rate of BOTW has declined as more types of gamers buy-in to the Switch. The Gamecube and (to a lesser extent) the Nintendo64 had less success than the Switch outside of core Nintendo fans which naturally means franchises like Zelda would have higher attach rates.

Mario Mario 1 & 2 are both well-designed executions of a concept that appeals to a more limited audience (building and playing user-made Mario levels). BOTW / TOTK hit that sweet spot of widely appealing concept and excellent execution.

My point is that it's the strength of the design, not the loyalty to the franchise or other factors, that is the primary driver of sales.

The titles you cite (Link's Awakening, Ocarina of Time) also made sales records because they were so good they reached a wider audience. But if you look at historical sales a mainline Zelda entry usually sells 6m to 10m.

Breath of the Wild sold 30 million and Tears of the Kingdom looks to be on a similar trajectory. That's due to the strength of the game design that's broadened the appeal well beyond the typical Zelda gamer.

The previous mainline Zelda entries sold 7.58, 10, and 6.79 million respectively for Skyward Sword, Twilight Princess, and Wind Waker.

Breath of the Wild has sold 30.7 million total so far, Tears of the Kingdom sold 10 million in its first 3 days.

Source: https://en.wikipedia.org/wiki/The_Legend_of_Zelda

Tears of the Kingdom is selling crazy numbers even without the lockdown boost. Other factors make a difference but the core of what drives the sale of these two titles is that they're great games people strongly want to play.

That's not a counterpoint. More serious gamers have always loved Zelda and the series has always sold well amongst that audience.

But this game (and Breath of the Wild) is selling above and beyond previous entries because it's such a great game that its appeal reaches well beyond Zelda's traditional audience.

I'm often discouraged by comments on Hacker News that downplay the importance of great design in a design-heavy medium.

This game isn't succeeding primarily because of great marketing, franchise, or blind loyalty to Nintendo (though all of those help!).

It's succeeding primarily because it's the follow-up to a game that critics and players universally found enormously fun. Before Breath of the Wild previous Zelda entries did not sell this well.

On MacOS "pulling in complex UI framework" amounts to "#[link(name = "AppKit", kind = "framework")]" somewhere in my Rust codebase. On Windows it's similar.

With Gnome it seems unclear how to do something equally simple to get decorations that match the OS look and feel. The most popular Rust windowing library ended up implementing their own client-side decorations rendering that imitates GTK: https://github.com/rust-windowing/winit/pull/2263.

And if every framework / app is doing this in their own subtly different way then the result is an OS where many apps have slightly different UX, buttons, text rendering, shadows, etc. A horribly unpolished experience.

In the last year-ish I wrote a pure-Rust windowing and input library for Windows / MacOS.

I never even had to think about making the window controls appear, they were just there by default when I created a window.

If I eventually want to extend support to Wayland / Gnome I need to figure out how to pull in complex UI framework dependencies. Or I could write my own code to render window controls but it won't be a perfect match to the platform's aesthetic. Compared to Windows / MacOS it's a mess.

Why the next 2 months?

> We do have some plans around making WebSockets more efficient by allowing the application to shut down while keeping idle WebSockets open, and start back up on-demand when a message arrives.

Please make noise when that rolls out! I was literally wishing for that yesterday.

I want to use Cloudflare Workers to quickly connect p2p WebRTC clients, but when a new peer joins there needs to be open WebSockets to send connection-setup messages to each peer in the room. But with how that works / is billed today it really doesn’t make sense to have a bunch of idling WebSockets.

An alternative is having each client poll the worker continuously to check for new messages, but that introduces a bunch of latency during the WebRTC connection negotiation process.

WASM supports shared memory: https://docs.wasmtime.dev/api/wasmtime/struct.SharedMemory.h...

It works on web too.

I wrote a bunch of thoughts on that topic exactly: https://ianjk.com/webassembly-vs-javascript/

In short: I think Rust / Wasm is great for certain categories of web apps that can benefit from Wasm's portability and performance consistency. But for more traditional web apps and pages there's little advantage.

What makes the "Product Manager" role tricky is every person and every organization has a wildly different sense of what they do.

You argue that there's not enough room in a person's brain for Software Engineering and Product Management, but "Product Management" often includes planning, strategy, coordination, vision, culture, anything vaguely leadership, and general "adulting". To call all of that mushed together a "discipline" makes no sense.

Skills like coordination and vision are just as orthogonal from each-other as software engineering.

As a result the best PMs are often those who know what control to give up to make the role / team function better.

I've even been on teams where engineers seem hesitant to organize fun events because it may be perceived as stepping on a PM's turf, which is absurd!

I think teams and PMs would benefit from splitting up the role. I'd love to see the creation of roles like "Associate Producer" (as borrowed from the film industry) that have a primary task of keeping things running smoothly without a strong focus on creative or technical leadership.

An unfortunate blemish on her record is her handling of `wasm-pack`.

She worked to ensure it become a critical part of the Rust/Wasm ecosystem and then silently stopped maintaining it. For most of 2020 / 2021 `wasm-pack` was not updated with pull requests and security fixes because Ashley did not transfer publish rights.

Even though `wasm-pack` became unusable for many users it was still described as necessary in the official Rust / Wasm tutorials. Likely this set back the Rust/Wasm ecosystem by discouraging many new members.

It would have been far better if she just spoke up and asked for help.

It seems she wanted to ignore a problem she didn't want to deal with, which I can relate to, but that's not a good quality in an executive director.

Some relevant GitHub issues: https://github.com/rustwasm/wasm-pack/issues/914 https://github.com/rustwasm/wasm-pack/issues/928

It also comes up with vector addition, subtraction, and multiplication, all of which are used all over in gameplay code.

I like Zig overall, but lack of operator-overloading just seems like a pain to me.

Zig in many ways puts faith in the coder to not screw things up, but in this case it diverges from that philosophy. Would it be too much to trust the user not to overload operators in an unacceptable way? Social convention over technical constraint.

That said I'd be more persuaded by the argument that it's not worth the extra code and complexity for a language as concise as Zig.

I like this change. “main” is more easily understood.

Presumably GitHub will be around for a while so this change will forever make it a little bit more straightforward for people new to GitHub.

Additionally if anyone says that they’d benefit from the change then I think it’s best to take them at their word because the cost to change is not high.