I don't understand why this is so complex? Just make it a feature you put in Cargo.toml:
serde = { version = "1.0", features = ["serde_derive", "fast_compile"] }
Either opt-in or opt-out is fine. It's surely useful during development but it shouldn't be on for production builds. Any transitivity issues should be considered problems with the dependency.
Sure features are transitive. A crate’s features at build are the superset of what every package defines. If I define “fast_compile” (opt-in) or “no_binaries” (opt-out) it’ll get applied across the board, will it not?
If I had to guess, the fact that the US is increasingly a service/knowledge based economy. Their complexity metric only seems to look at physical products.
Modern designers would think it’s terrible because it gives you too much information, and suggest putting in way more white space, hiding things under menu bars. I wish I was being facetious but sadly it’s a sincere statement.
Completely agree though. Information-heavy pages for desktop consumption were wonderful. It truly feels like we’ve regressed. Just loading that gamespot link honestly filled me with an immense nostalgia for the web of 10-15 years ago
I didn't mean to sound condescending, I was genuinely curious. I was wondering if there's a correlation between age and aesthetics, but we're about the same age.
Async is a bit trendy right now and in my experience has a way of infecting a codebase. That said, I like the way it reads for server code. In a project I'm working on, we use both: explicit threads and channels the CPU-bound work and an async REST server on a single thread for handing requests and reading the database. It works nicely. But we do have a clear separation boundary between the two. Also, here's a related post that surprised me. Poster says spawning a thread per connection works fine for their server at 50K+ connections. Context switching and spawns not a problem? Maybe not always. https://stackoverflow.com/questions/17593699/tcp-ip-solving-...
I enjoyed the async part where the author built up Future and a runtime from first principles. If the topic interests you, these two videos are good follow-ups into Rust async [1] [2]. Rust's model is a little different and more powerful than other languages.
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...)
serde = { version = "1.0", features = ["serde_derive", "fast_compile"] }
Either opt-in or opt-out is fine. It's surely useful during development but it shouldn't be on for production builds. Any transitivity issues should be considered problems with the dependency.