[mediocregopher]

It's very clearly a toy example to demonstrate the idea, and it does so well.

> What we have here is a Rube Goldberg machine, not a cleanly solved engineering problem.

And what _we_ have here is unfounded indignation over a perfectly fine way to solve a problem. People have been using linked libraries to re-use code across languages since forever, it's fine. This solution isn't very different, it just makes shipping easier.

As a parting comment, "sound software architecture" is not a decided upon principle which can be empirically determined, and if it was we'd all be out of a job.

[gw98]

> And what _we_ have here is unfounded indignation over a perfectly fine way to solve a problem

Absolutely no way is this a fine way to solve the problem. That is crazy talk.

1. It introduces additional toolchains into the solution when it is unnecessary.

2. It now means you need multiple language specialists to maintain it and associated communications and context switching.

3. More interfaces and integration means more fragility when it comes to debugging, problem solving as well as increasing the problem surface.

4. It massively increases the dependency stack which means there are now multiple sets of supply chain issues and patching required.

This makes no problems easier at all! It's even a bad last resort if that's all you have left to try.

Sound software architecture is very very well defined and this is definitely not it. I have seen entire companies burn by taking this approach to problem solving.

I'm really getting tired of solutions before problems and this is a fundamental example of it. Give us a real use case not manufacture a problem for it.

[mk89]

> 2. It now means you need multiple language specialists to maintain it and associated communications and context switching.

Sometimes you have that and you need to accept it. In this case the function was really trivial. What if it was a mega secret algorithm that needs Rust speed which you want to really write in Rust because XYZ? Or C++ I don't care. But not Go, which you want to use exclusively for microservices, for example.

> 3. More interfaces and integration means more fragility when it comes to debugging, problem solving as well as increasing the problem surface.

This is inevitable when you want to go that low level. Some companies use C++ for everything, some mix low/high level: how do you do in that case?

This article is about Go, but I could imagine something similar for Python: use something superfast under the hood, python for the high level part. It's really a common solution, which requires a bit of bindings left and right but it's worth it.

> 4. It massively increases the dependency stack which means there are now multiple sets of supply chain issues and patching required.

This is how software is done today. Maybe 30 years ago you would write everything in C and be happy with it. Today companies use at least 3 programming languages - at least that's my experience.

[masklinn]

> This article is about Go, but I could imagine something similar for Python: use something superfast under the hood, python for the high level part. It's really a common solution, which requires a bit of bindings left and right but it's worth it.

That's not a bad idea really, the wasm/wasi option could be a nice intermediate step between "we can't optimize the python any further" and "write a native extension" (or god forbid use cffi or the cursed horror that is ctypes).

[dom96]

> Absolutely no way is this a fine way to solve the problem. That is crazy talk.

I disagree. I see this in a similar way I see Electron and actually you can make the same arguments against using Electron.

But guess what, Electron wins on practicality. It makes creating GUI apps much easier. That wins over any problems associated with the extra baggage of shipping a whole browser. It doesn't win it for everyone, but it does for the majority of people who just want to get shit done.

[morelisp]

> People have been using linked libraries to re-use code across languages since forever, it's a fine way to solve problems.

People have been doing it forever, but people have also hated it forever. Twenty years ago you saw SWIG in a build, you'd know you were probably in for a bad time in an exciting new way.

[mk89]

I think SWIG had a different purpose. The author here generates and embeds WebAssembly in Go, to avoid building the same lib for multiple platforms (+ the bindings to call the low level c code). Maybe the tool wasn't good enough? Right now this is just WebAssembly which is proven to work on multiple platforms.

If the API is clear and documented, I don't see why this would be an issue, except for the fact it might be a little bit clunky.

It's not the first solution I would come up with, but the question would be: why not? Just because we're used to older and more traditional patterns, why not just to embed webassembly for low level stuff in your code?