5 ms·

This is a toy example to demonstrate a framework to build with. But I don't think it's not a cleanly solved engineering problem. Instead of reinventing xer Rust

• morelisp 4y ago
  > Minimal effort from the engineer has been expended Is the definition of "how do I get promoted in a company where I don't care if it survives the next five years", not "a cleanly solved engineering problem".
  • zaarn 4y ago
    I don't really see the maintenance issue. The rust code seems maintainable and the go code seems to be fairly lightweight overall.
    • gw98 4y ago
      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.
      • zaarn 4y ago
        Depends on how the rest of your stack looks. I wouldn't presume.
        • gw98 4y ago
          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!
          • xena 4y ago
            Author here. My article is not supposed to talk about a good idea. It's meant to bring a bad idea to the table and explain why it works. I designed the function in question with the understanding that it would fire once or twice per 10 minutes. This means that paying a cost like 3.1 megabytes per invocation is okay. If this was intended to run _constantly_ (such as if it was a core part of a run loop), that's different.
            • dekhn 4y ago
              I recommend putting this point up at the top and quite clearly explain that.
            • masklinn 4y ago
              One thing I'm wondering about: what's the call overhead of wazero? Especially for function calls (rather than as a `system()` alternative)? I understand that cgo has significant per-call overhead, aside from all the other curses it implies, does wasm/wazero have the same issue or not?
              • xena 4y ago
                With the version of wazero I'm using right now, it's about 0.3 milliseconds to do a single call from Go to Rust and back in the best case on my hardware. I am told that a recent patch to wazero will increase this by a lot, so I'm going to try upgrading to that patch and see what differences it makes. I still think that it will be a bit slower than cgo, BUT the platform-independence and strict sandboxing makes up for it in my book.
            • morelisp 4y ago
              I think the article is absolutely clear about it but also I think people will (are! in this very thread) ignore that part and make enormous messes that will hurt real users and someone else will have to clean up. I’m not sure how to fix this but I’m also tired of pretending it’s not a chronic problem.
              • 4y ago
      • ilyt 4y ago
        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 4y ago
          > 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 4y ago
        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 4y ago
          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.
• nuc1e0n 4y ago
  I don't care for the eccentricities of the Rust community, but this is a good article that demonstrates an effective approach to invoke code from one language to another. The problem is a toy one that's not the focus here. The focus is a better means of doing interop