[gw98]

You missed the two entire toolchains and the third tool required to stick them together?

It's pretty difficult and expensive to build one stack, let alone three and onboard another tool.

[ilyt]

The alternative is rewriting the code of Go into Rust or vice versa.

And if rewrite is Rust->Go way, also continual effort of porting any bugfixes in upstream lib.

I dare to say more complex toolchain is the easier and less time consuming part.

I wouldn't do it in this particular case (converting with mastodon powered html is probably simple enough) but it wouldn't be a terrible solution in some cases.

What's more interesting is if you use same method for app plugins, now you can compile anything in WASM and as long as it have right hooks it can be used in your app as a plugin

[morelisp]

> The alternative is rewriting the code of Go into Rust or vice versa.

This is more work up front, but it’s better engineering.

> easier and less time consuming

Have some pride, jesus christ.

[dom96]

Depends on how well supported those stacks are. WASM is very well supported and likely to be getting tested/used/improved extensively as the years go.

I'd rather work on software that depends on three different tech stacks that are well understood and used by many, than software that depends on a single niche tech stack.

[morelisp]

I'm not a "stick to a single stack for everything" kind of person, but here we're comparing Go or Rust, to Go + Rust + WASM. The first option is strictly and substantially less risky in this dimension.

[zaarn]

Depends on how the rest of your stack looks. I wouldn't presume.

[gw98]

I've dealt with pretty much everything from steaming nightmare creeping Cthulhu desktop applications right into back end fintech stuff written in the dark ages over the last 30 years. At no point have I found this solution being applied where it solved a problem. I have seen it applied many times where it created problems!