caspervonb

We use swc a lot but not for type-checking, that is still done by tsc loaded into a snapshot (precompiled v8 state).

There is a type-checker in the works tho https://stc.dudy.dev/docs/status/

> We quickly realized we might actually be more productive in Rust.

The compile times will catch up with you soon enough! enjoy them while iterating is fast! ;)

Uhm, so this submission was edited and renamed to Deno 1.1, but this is release version 1.10 as in version one dot ten.

Hi there.

Any examples from deno.land/x of what you'd expect from spies and mocks in std/testing?

Thank you! we'll look into it!

Wouldn't recommend it, takes quite a while to build from source.

Rustup is the way to install rust and cargo.

Had this clip sitting unlisted for a few months, think it's a neat little showcase of Vim's capabilities.

This probably will bomb on HN, not much marketable about a test suite for a vaugley defined specification.

But, an open call for all developers interested in WebAssembly, please help me out with this test suite, we don't have one.

WebAssembly implies a model with no syscalls. WASI provides a basic set of POSIX like syscalls which is used by the various standard libraries when the compilation target is wasm32-wasi.

So C, C++, Rust code using their respective standard libraries compiled to wasm32-wasi can run on Deno out of the box.

So this is somewhat of a followup to https://news.ycombinator.com/item?id=23548491 which was about deno-wasi, an implementation of the WebAssembly System Interface for Deno.

Well, I merged deno-wasi into deno about week or two ago, currently shipping in stable.

Please feel free to break it :)

> Just to clarify my understanding, none of this is free though, right? If I understand correctly, every WASI will have to be maintained to achieve and preserve feature parity as new features are added to the language or, in the worst case, a breaking change is introduced.

WASI is versioned by namespace, which is just a prefix for the modules; so v1 and v2 of WASI may in theory actually have nothing in common so the runtime needs to support that particular version of the interface.

e.g; a module compiled today with only the MVP WebAssembly features targeting wasi_snapshot_preview1 (the current version) today should continue to run just fine as long as the runtime doesn't drop support for that version of WASI.

Features in WebAssembly itself do not necessarily require a rewrite, at-least in the current specification but it depends what happens going forward.

> This may be a naive question, but this is also only for server-side code, right? Would you be making these kinds of syscalls in code you deploy to the client? Forgive me, I'm not entirely up to speed on webasm.

Browsers too; e.g a browser game or app can use standard library i/o which calls into WASI; altho my web-wasi implementation is not up to par at the moment as I'm waiting for the outcome of a proposal Emscripten's kripken put out on how to deal with async/await in browsers.

This is dumb, I love it.

> EXTREME performance

[Violation] 'requestAnimationFrame' handler took 1210ms

Tried a few of the demo's and they're very sluggish.

Many reasons; like it's a bit dull but primarily we are creating user hostile software and thats the norm.

Don't get involved with web development.

Graphics and Design:

* Photoshop, GIMP is great but still a bit rough.

* Illustrator, Inkscape is great, but rough.

* Maya, Cinema4D: Blender is technically pretty good, UX is improving but still clunky. Even something like Silo would be pretty sweet (a fairly simple, pure 3d modeling program)

* Video editing: Is there really anything good out there? Last I tried the programs just straight out crashed.