It seems like they know I have an iPhone with dark mode enabled, that I speak English, and that I'm in the USA (but wrong city wrong state). I am kinda unimpressed, I'm pretty sure they can get a lot more info than that.
In most real-world use of the term, a paradox isn't something that's impossible, it's just something that intuitively seems wrong when you first think about it.
"I got a Prius so now I am spending more money on gas" sounds ridiculous, but it would be an instance of this paradox.
There's plenty of non-critical code that I would trust non-technical people with good AI tooling to touch. As long as their access is segregated from the actual critical stuff. But let them write marketing pages or help and documentation pages. Let them write internal reporting code or build tools to use themselves.
I ran content and educational pages for Kraken a few years ago. This was just as AI was getting useful. I was told by the head of security, the guy who coded all the original software, not to use any outside AI tools to proofread or edit. Then, a few months in, the CEO, Jesse Powell, asked why we were so slow in producing content - we had to edit it all by hand, as you do. We explained the security issues and he said "Who cares, just use it."
So on one hand they are the most secure business on the Internet and on the other hand YOLO!
I mean, this is semantics. Production is not the same thing as "important", but to me production code means customer facing. Internal tooling isn't production.
Milchik's problem was that he worshipped--quite literally--the company. I do this for my own gain. I started getting much more of what I wanted out of work and other formal relationships (my kids' teachers, my doctors, etc) when I got honest with how I was communicating and how I was being perceived and changed my habits to suit.
I've been thinking of just using sandpaper stuck to a block of wood, though I imagine that might be slower.
Heck, a little part of me is tempted to try the smallest radius round-over router bit I have in a trim router, but the odds of that going horribly wrong are just way too high.
I have thought about filing/sanding my MacBook forever and getting a case to solve the problem never even occurred to me. I feel a little silly now because it does seem obvious, but also to me just filing it down sounds like less work than picking out a case.
I've been meaning to do this forever and think this game me the push I've needed to do it tonight when I get home. Probably not as rounded as OP, but it's reassuring to know I could go that rounded and it wouldn't fall apart.
If you actually read the README.md file, the first few lines say that there are hosted versions available that you can view directly in your browser. I also mentioned this in another comment. I don't know what else you want...
I just see a lot of open source projects fail on the basic "get the message out".
And, I actually would like to use a Rust / Wasm UI.
That's what was frustrating. I'm looking for this. And still, had to wade through site to find some slick demo showing the merits of the speed and responsiveness. You want some snappy demos to show zip. It says 'reactivity', so I was expecting some super fast demo.
Sure. Ok. Now, put those links on the main page with a big bold "Examples Here". Is it that hard. Why make potential users wade through 5 clicks to get to an example, and then see if they are interested enough to persue further.
If you want users, put in bold, splashy, easy to get to.
It isn't that hard.
Viewing on examples.sycamore.dev
All the examples are hosted under examples.sycamore.dev/<example_name> with <example_name> being the name of the example you want to view. For instance, the todomvc example is hosted on examples.sycamore.dev/todomvc.
Yeah if you're serializing and deserializing data across the JS-WASM boundary (or actually between web workers in general whether they're WASM or not) the data marshaling costs can add up. There is a way of sharing memory across the boundary though without any marshaling: TypedArrays and SharedArrayBuffers. TypedArrays let you transfer ownership of the underlying memory from one worker (or the main thread) to another without any copying. SharedArrayBuffers allow multiple workers to read and write to the same contiguous chunk of memory. The downside is that you lose all the niceties of any JavaScript types and you're basically stuck working with raw bytes.
You still do get some latency from the event loop, because postMessage gets queued as a MacroTask, which is probably on the order of 10μs. But this is the price you have to pay if you want to run some code in a non-blocking way.
Strongly agree from an Emscripten C++ wasm pov: it's key to minimise emscripten::val roundtrips. Caches must be designed for rectilinear data geometry, and SharedArrayBuffers are the way for bulk data. But only JS allows us to express asynchrony, so we need an on_completion callback design at the lang boundary.
Indeed a whole class of issues become moot if you just don't use javascript anywhere. In the browser world this is obviously difficult/impossible; I look forward to the day when WASM can run natively in a browser and doesn't need javascript at all, DOM, network, etc, etc. On the server side? Just steer clear of the javascript ecosystem altogether.
So the actual processing is faster in rust/c/c++ but the marshaling costs are so big so ts is faster in this case? No vlue how something like swc does this but there it's way faster then babel.
reply