Having been a customer to a half-dozen different banks in almost as many countries, I can assure you that this is very common. You'd be surprised how often the user interface stonewalls you with a "please call support" for even the most basic contact details update operation.
I'm in a similar situation, having left a startup a year ago to work at $BIGCORP, naively thinking it would benefit my résumé. This is all painfully accurate.
The other thing about working for $BIGCORP is that it molds your skills to be hyper-specific to this company. It's less about learning to use cool technology stacks, than it is about learning the internal tools, procedures, and unspoken etiquette of the company. Skills that are vital to navigate the everyday complexity of $BIGCORP, but that you can't really export to any other job.
On the other hand, working at $BIGCORP will probably give you very good domain knowledge (as $BIGCORP's software is likely complex and actively used by many many people who signed very expensive contracts, and besides that also the knowledge on how to navigate the internal complexities of a $BIGCORP) that will be useful for work in other companies?
Yeah that's also true, to a degree. Clearly, there are interesting challenges that I would have never been faced with had I stayed at a startup.
But I also found that once you reach a certain level of expertise at $BIGCORP there are few opportunities to try to push the boundaries of your domain knowledge, lest you are dead-set on taking initiatives and swim against the current of a rigid organisation. That may just be specific to my job and employer though.
And while the part about navigating internal complexity is true as well, it's harder to highlight on a CV than "I have worked with technologies X, Y and Z". At best you can say "I have worked with X at a big corp, and also Y, which you probably don't know because it's an internal tool." You just have to hope that the name of your employer alone carries enough weight on its own.
You often can’t see what problems they were built to solve. But go work for a company transitioning crossing the threshold at 100-200 employees and you’ll think “oh, that’s what that annoying process was trying to solve”. The problem is that many people try to use technology to solve people problems instead of recognizing them for what they are.
> It might interest you that newer versions of Wasmi (v0.45+) extended the resumable function call feature to make it possible to yield upon running out of fuel:
That is really interesting! I remember looking for something like that in the Wasmi docs at some point but it must have been before that feature was implemented. I would probably have chosen a different design for the WASM apps if I had it.
I am really sorry I have waited so long to extend Wasmi's resumable calls with this very useful feature. :S
Feel free to message me if you ever plan to adjust your design to make use of it.
Thank you! And thanks for making Wasmi, it's a really impressive project and it's the reason why I decided to go this whole WASM sandbox route (because I could embed it easily) :)
Yeah it's one of those projects were I'm so impressed that I'm saying nothing because there's nothing to say, it's just really impressive. I'm not sure what will come of this project, but it has a lot of potential to at least inspire other projects or spark important discussions around its innovations.
Wasmtime maintainer here - curious to hear what went wrong, I and several other users of wasmtime have production embeddings under no_std, so it should do everything you need, including building out WASI preview 2 support. You can find me on the bytecode alliance zulip if you need help.
I think I was a bit spooked by the examples (https://github.com/bytecodealliance/wasmtime/tree/main/examp...), and the need to implement platform dependencies in C code (which would have complicated the build process). Makes sense since it's a more complex and mature project, but Wasmi on the other hand was just a pure Rust dependency that only required a single line in the Cargo.toml. So in short I went the lazy route :)
All of the C primitives there implemented in (unsafe) Rust, but we built that example for an audience that already had some platform elements in C. We'll try to improve the example so that both integrating with C, and using pure Rust, are covered.
I'm not the OP, but I have a similar experience with Motor OS: wasmi compiles and works "out of the box", while wasmtime has a bunch of dependencies (e.g. target-lexicon) that won't compile on custom targets even if all features are turned off in wasmtime.
Not sure how to help with this much information but I've built and run wasmtime on some pretty squalid architectures (xtensa and riscv32 microcontrollers among others) but the right collection of features might not be obvious. We can help you find the right configuration on the Bytecode Alliance zulip or the wasmtime issue tracker if you need it.
I guess not much can be done at the moment: dependencies are often the primary obstacle in porting crates to new targets, and just comparing the list of dependencies of wasmtime vs wasmi gives a pretty good indication of which crate is a bit more careful in this regard:
Wasmtime has many capabilities that wasmi does not, and therefore has more optional dependencies, but the required set of dependencies has been portable to every platform I've targeted so far. If anything does present a concrete issue we are eager to address it. For example, you could file an issue on target-lexicon describing how to reproduce your issue.
> If anything does present a concrete issue we are eager to address it.
That's great to hear! I think it is a bit too early to spend extra effort on porting Wasmtime to Motor OS at the moment, as there are a couple of more pressing issues to sort out (e.g. FS performance is not yet where it should be), but in a couple of months I may reach out!
There’s now an interpreter in wasmtime called Pulley. It’s an optimizing interpreter based on Cranelift, which generates interpreter opcodes which are more efficient to traverse than directly interpreting the Wasm binary.
I have run wasmtime on the esp32 microcontrollers with plenty of ram to spare, but I don’t have a measurement handy.
Wasmtime, being an optimizing JIT, usually is ~10 times faster than Wasmi during execution.
However, execution is just one metric that might be of importance.
For example, Wasmi's lazy startup time is much better (~100-1000x) since it does not have to produce machine code. This can result in cases where Wasmi is done executing while Wasmtime is still generating machine code.
it's not a source at all, it's definitionally bullshit because the LLM has no concern for the truth. Never post LLM text. Anyone can get that for themselves. To do so is an insult to the comment section. I'm not here to read bot summaries. If you ask the bot something and then it leads you to a source and then you read that and then you put that in your own words, that's a comment worth reading.
what you did is like farting in a crowded space. STINKY AND RUDE
reply