Yes and if you're hitting or exceeding your sales goals, your boss won't care how much you are in the office. For at least some sales work, a substantial portion of it may take place outside of the office anyway.
What companies today give software engineers offices? Microsoft's used to be fantastic in 00s and early 10s but they also were moving to open spaces when I left so not sure the state today.
Honestly, trying to fix the problems of: 1) expensive office space and 2) people not coming into the office with 3) more _expensive_ office space is just the kind of McKinsey-level thinking we should expect.
If HOAs increase property values, maybe we can convince our overlords that an Office Workers' Association for planning these renovations will help save them from Numbers Go Down in the commercial real estate market.
> 1) mean fewer offices (per unit space, since they are bigger)
I think this is rather optimistic. If you give more square feet per employee and expect most/all to come in, the idea that it will mean fewer offices doesn't really add up.
Sure, that was the point of my comment. Making the offices bigger and nicer incentivizes people to come in, and reduces the building capacity, the goal should be to find the point where those two trends meet.
Of course, this is under the assumption the company wants people to come in willingly. They could just try and force their employees to come in, but people are really into work from home and good employees have more options.
Not to mention they've taken to straight up lying on their job descriptions saying they're based in Chicago while having "required to relocate to Madison" in fine print at the end of the ad.
One of the only reasons why we know people were playing golf on The Old Course at St. Andrews 600 years ago is because the king of England at the time thought his archers were spending too much time golfing versus practicing archery, and put out a decree to ban the sport among the soldiers. I don’t think anyone truly knows how old the sport is or when it first started being played at St Andrews.
It's fascinating that it shows a number of behaviours that are typical on a 21th century ice skate rink too. Including the show off doing a Besti squat[1].
I've never seen a worse-described project than WASI.
"Component model interfaces always support link-time interposition."
Like WTF does this mean? The repo tells me nothing and I've still yet to see a clear write-up about what WASI is. I click on "docs" folder and there's one file. https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.... WTF is wit? This should be in a CONTRIBUTORS.md not in the docs folder. I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs. Wikipedia tells me WASI is a POSIX-like interface but with POSIX I know exactly where to look up the functions. Where's a single well-written WASI spec?
I'll be honest - this whole project feels like candy for architecture astronauts and goes against the spirit of WebAssembly. Looks at how well-written WebAssembly's goals are: https://webassembly.org/docs/high-level-goals/. Their spec is easy to find and easy to read. This is what I want from WASM. Whatever WASI is doing, I don't like it. And neither does AssemblyScript team apparently: https://www.assemblyscript.org/standards-objections.html.
I also agree with the AssemblyScript people. WASI is driven by people saying "I want to be able to compile existing Linux software to WASM and run it on a server!" and to do that they have pretty much just copied POSIX.
Great for running old software, but it seems very short sighted to me to tie WebAssembly to 70s UNIX design.
It'll probably be popular because people apparently love never fixing things...
They mean that an environment can always provide a fake version of a function to a webassembly program. They’re defining an API but there’s no requirement to implement it.
It seems like a rather weak specification where nothing is required to work? But at least it defines an interface. You might compare it to Go or Java interface types.
You're referring to yet another part of WASI, which is indeed about defining domain-specific sets of APIs.
No specific set is required to be implemented. So an application can work somewhere, and not load elsewhere.
But the idea is that similar environments will hopefully implement similar APIs, and there's a mechanism to encourage that ("worlds").
Not only interfaces are defined. As an illustration, the WASI Crypto proposal includes a lot of details on how individual functions must behave, because in this context, it's critical to avoid inconsistencies between implementations.
Good to hear. I was basing what I wrote on the previous sentence:
> This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it.
It sounds like someone (who?) can use middleware to override an API to do whatever they like, even though there are specifications elsewhere about what they must do.
In the context of virtualization, would this allow things like running one virtual machine inside another? Sandboxes all the way down?
> "Component model interfaces always support link-time interposition."
>
> Like WTF does this mean? The repo tells me nothing
Directly above the sentence you quoted:
"Interposition in the context of WASI interfaces is the ability for a Webassembly instance to implement a given WASI interface, and for a consumer WebAssembly instance to be able to use this implementation transparently. This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it."
> and I've still yet to see a clear write-up about what WASI is.
In the same document: [0]
> WTF is wit?
The first link in that document ("Starting in Preview2, WASI APIs are defined using the Wit IDL.") is [1].
> I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs.
The README for the legacy directory [2] clearly explains what they are.
> Where's a single well-written WASI spec?
"Development of each API happens in its own repo, which you can access from the proposals list." [3]
> Whatever WASI is doing, I don't like it.
Clearly not - you've gone out of your way to ignore all of the documentation that answer your questions.
> And neither does AssemblyScript team apparently
The AssemblyScript team have a bone to pick with WASI based on their misunderstanding of what WASI is for (it is not intended for use on the web) and WASI's disinterest in supporting UTF-16 strings. You can see for yourself in [4].
None of this is excusable. Tell me what your project does in clear English.
"WASI is a standard for 50 functions you can call to do systems-level things from your WASM code. Here they are."
Done.
I don't care about wit/witx. I don't care the repo being in transition. I don't want to read about interposition or components or capabilities. I don't want to see your copy-pasta goals from WASM (which aren't clear for WASI). You're an API. Show me the API.
The WASI section documents WASI as it is implemented today.
But since then, WASI pivoted and has become an umbrella for multiple projects. This is not just an API any more, and at the moment, the documentation on the WASI site and repositories is for WASI developers, not for developers using WASI. So if you didn't follow the whole thing, it is indeed be very hard to understand. The stack is complicated. But the ultimate goal of the project is to actually make it easier for developers to use wasm, without having to worry about all these details.
It's essentially about adding dynamic linking to wasm. The dynamic libraries embed the function prototypes, so that calling functions with the wrong type will cause a link error. That requires the definitions of every type of function, and WIT, WAI and WITX are domain-specific languages to do that.
Right now, WebAssembly is limited to static linking. It works very well, even across languages, but types aren't automatically checked. Actually, they are, but only using the primitive types available in WebAssembly. Here, the goal is to support something very close to the Rust type system.
The proposal also allows restricting every library to their own memory region. So, a buggy or malicious library can only mess with its own data, not with the rest of the application.
> Tell me what your project does in clear English.
Okay.
"Define a set of portable, modular, runtime-independent, and WebAssembly-native APIs which can be used by WebAssembly code to interact with the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design."
That's the first goal.
> I don't care about wit/witx. I don't care the repo being in transition. I don't want to read about interposition or components or capabilities.
Everything you've just mentioned is relevant to people implementing the spec, given its wide scope and nature. It is not reducible complexity.
It is not a drop-in replacement for POSIX (i.e. it is not "a standard for 50 functions"); it goes beyond that, and aims to provide a secure and modular way to interact with the system where capabilities can be delegated or reduced.
I implemented my first real-world project in WASM for OSS Summit, and everything you said about WASI echoes my real-world experience. It's not a set of functions to call. It's a terrific bundle of constraints (enabling constraints) on how to interact with the world outside of WASM, that embracing will force you to make your problem smaller until it's well-defined and testable, unit-ized even.
You're not building the old monolith the same old way in WASM, at least not if WASI is the main tool in the toolbox. And you're also probably not building the whole thing in WASM, (whatever it is that you had as original goal to build as an enterprise.) I think we'll have legacy code that needs to integrate with WASM for a time, and the time might be forever.
As a Rubyist, from this perspective I have been studying WASM and I have to admit I was really disappointed when I first began to understand the limitations we have in the current crop of tools – I now firmly believe the next generation of WASM tools will do it better.
Sweeping enhancements that are going to change it all again. Dynamic loading will hopefully bring us the capability for Ruby gems with C extensions to join the vfs assembly. (But now, as an end user and not a deep systems implementor, this is the part of the conversation where I begin to lose the plot, and going out of my depth...)
I was reading Weaving the Web, the story of Tim Berners Lee and the creation of the web, there's a section on misunderstanding about links. In 1999. Wish this were still not a misunderstanding today.
Myth Two: "Making a link to an external document makes the first document more valuable, and therefore is something that should be paid for." It is true that a document is made more valuable by links to other relevant, high-quality documents, but this doesn't mean anything is owed to the people who created those documents. If anything, they should be glad that more people are being referred to them. If someone at a meeting recommends me as a good contact, does that person expect me to pay him for making reference to me? Hardly.
This was the most well-written technical piece I've read in a long time. Kudos Andi. The conversational tone, imagery, well-sourced history - it was perfect.
It was interesting to read that Rust has a WebGPU implementation [0] outside of the browser. I wonder if this will become a more general standard.
Anyone know how WebGPU compares to CUDA in terms of performance and functionality?
It’s not WASMs fault. Rust produces large binaries for whatever reason and people like to write their WASM in Rust. I’ve ported Rust to equivalent C and it was 25% of the size and similarly for loading times.
it is rather simple, JS tooling cares A LOT about the size of their dependency tree. Statically compiled languages do not (except if they focus on embedded programming). Having a binary be 2mb vs 30mb is not a big deal for a desktop application
Just for reference I was testing this the other day and compiled some simple C++ to WASM and adding:
std::cout << "some text";
to the code increased the binary size by like 5mb. Turns out std:cout pulls ALL currency-formating, date-formating and i18n code in the c++ standard library into your binary
ansi C printf does not meaningfully increase your WASM binary size
If you want your code to be able to be loaded on-the-fly and fast you need bundling tools, just like JS does. Bundling is a really hard problem, game devs struggle a lot with it as well (although their problem is usually bundling assets, not code itself)
Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).
Rust doesn't have to output more code than a C compiler. But it tends to because most rust programs are stuffed full of bounds checks. And bounds checks aren't small. As well as the conditional itself, every bounds check also includes:
- A custom panic message (so you know which line of code crashed)
- Some monomorphized formatting code to output that message
- The infrastructure to generate a stack trace after a panic
- Logic to free all the allocated objects all the way up the stack
And predictably, the result is this gem - identical to what the C compiler outputs:
example::read_arr_unchecked:
mov rax, qword ptr [rdi + 8*rdx]
ret
But nobody writes rust code like that (for good reason). You can get a lot of the way there by leaning heavily using rust's iterator types and such. But its really difficult to learn what patterns will make the rust compiler lose its mind. There's no feedback on this at compile time, at all.
I'd appreciate any more tips or resources you might have about reducing Rust code bloat. I want my library [1] to be acceptable to the most strident anti-bloat curmudgeons, so they'll make their UIs accessible.
I don’t know many good resources to learn this stuff unfortunately.
The things I reach for in practice are godbolt and cargo asm[1] - which can show me the actual generated assembler for functions in my codebase. And twiggy[2], which can tell you which functions are the biggest in your compiled binary and point out where monomorphization is expensive.
When I’m developing, I regularly run a script which compiles my code to wasm and tells me how the wasm file size has changed since the last time I compiled it.
Some tips:
Try to avoid array lookups with an index when you can. When looping, use slice iterators and when making custom iterators, wrap the slice iterator rather than storing a usize index yourself.
Be careful of monomorphization. If you’re optimising for size, it can be better to take a dyn Trait rather than making a function generic.
And play around with your wasm API surface area. It takes a lot more code to pass complex objects & strings back and forth to javascript than other types.
Great project - this is important! Love your clear motivation statement at the top. I do wish there were some code/data examples within the README, but clearly that's not holding people back from using it.
Rust can be the same size if you put the same code into the binary, sometimes even smaller.
The problem is that it's real easy to just add a bunch of crates to an application, similar to the nodejs/Python approach.
Most people slso don't seem to turn off many parts of the standard library they don't, even for platforms like WASM. Maybe it's useful to have a stack unrolling panic handler during debug but in release you can just abort and save up to megabytes of space.
There's also a lot to be gained by tweaking the compiler optimisers. By default the optimizer is multithreaded, which makes compiles quite a lot faster, but reduce that to a single thread and suddenly a lot of optimizations can happen that wouldn't happen by default.
I wouldn't write code like described here in C, but I imagine Go and C# are better choices here. Maybe even that Java library the name of which I can never remember, or that Kotlin project that compiles Kotlin to Javascript with super easy interaction between frontend and backend.
I love Rust but if you're going to pick a systems programming language for your frontend, just make desktop supplications. Web is a nice fallback but if it's your primary target, there are so many better options out there.
The UI redesign called Cheetah was also forced internally and a lot of OGs left during that period including the long time VP of Eng Tim Sehn. Lots of internal politicking, late hours, and then layoffs the next year, for a project many of us weren't sold on. Not fun. And when the rollout data showed what many of us suspected, it took too long to pivot. The thing is up until then I think Snap's top-down design-driven culture was a strength and supported its innovation. Sometimes you have to do the unpopular thing. It works until it doesn't. I hear things have softened since.
Thanks for sharing this. Yea, I was a heavy user of snapchat until that update. Only ever have used it since as my default camera app. All the people I knew that used it for the social network aspects stopped using it around the same time as well.
I wish Nostr were invented 30 years ago because it seems like a elegant protocol with room for extensions that could have served as the backend language for Twitter, IRC, FB, and more. But network effects are just so powerful and people post to be seen. Twitter isn't going to willingly open the door to competitors, and so I hope Nostr can find a few unique use cases and communities to let it blossom.
I.. agree, but I don’t think recreating existing platforms is a good idea either in FOSS or commercial projects. As you say, it’s already there.
> Network effects are just so powerful and people post to be seen.
Yeah, but those people aren’t moving the needle anyway, so they can be safely ignored, for now. They’ll come when it gets popular or trendy (see the recent mastodon influx).
Current gen social media is clearly not the end-all be-all. It’s riddled with problems, both because of the business model which incentivizes short-termism like clickbait, but also inherent problems in the social graph, feeds, etc. We’ve had at least a decade of experience to learn from the mistakes of the giants. Maybe this sounds elitist, but whenever I see a Twitter clone (say current gen Mastodon or Substack Notes) all I see is a lack of creativity and courage to face novel opportunities.
"Data brokers would have to undergo an independent third-party audit every three years to ensure compliance with the DELETE Act provisions and submit audit reports to the California Privacy Protection Agency."
Well, I can see how that means well, but this doesn't scale to dozens of other jurisdictions doing the same thing. The audits would have to either be cheap and toothless or impossibly expensive, or, given the dozens of jurisdictions eventually doing these, probably both and other combinations besides. One can only imagine the nightmare of this jurisdiction deciding this bit of data is private, some other jurisdiction deciding it's mandatory to keep (e.g., "you must record this user's legal identity in order to ensure that future data you may receive is also deleted"), and yet a third jurisdiction deciding that it must be deleted but if and only if the user explicitly asks for it in the request. It won't take much for (real) compliance to exceed what even the big tech companies could afford.
At least something like the EU legislating this covers a significant fraction of the world economy in one go.
You've obviously never dealt with the EU privacy machinery. There is a separate privacy directorate in every single EU country. There is also a privacy group at the EU level. These groups _fight_with_each_other_...the EU level authority recently forced Ireland's DPA to fine Facebook despite the Irish authorities initially finding no enforceable infringement.
I get that everyone dislikes Facebook, but this is not a stable regulatory regime to do business in, nor is it covering all EU member countries "in one go".
Fair enough. It is true that I was being a bit idealistic for sure.
The sad reality is probably that there is no solution to this. If one imagines that the regulatory apparatus for some operation requires some percentage of the complexity and velocity of the underlying thing being regulated, well, government can manage the requisite complexity probably (though getting the correct complexity is another matter), but the velocity is just never going to happen, and the attempts are just going to look like this. By the time this is pushed through California, the actual regulations written to comply with the law as passed by the legislature, and enforcement actions begin, it will already not know what to do with things like AIs using personal information or complicated cross-company AI-based data washing schemes ("we use AIs to transfer summary data about the individuals in a complicated manner that makes it look like all the data is anonymized but in practice the data is so rich in its own complicated manner that the receiving company is de facto operating on private information but good luck proving that in a court of law, have fun with this one regulators!", etc.).
