Live data from Hacker News

Debugging WebAssembly outside of the browser

hacks.mozilla.org

61–66 of 66 posts

Re: Debugging WebAssembly outside of the browser

#61
post #56

Earlier quoted context omitted.

Contrary to popular belief, performance is always a factor. Every cycle your app wastes is a cycle another app can't use. It's a fraction of a watt that adds up over time, draining batteries faster, drawing electricity from the power grid and burning carbon fuels. Each individual cycle may be cheap, but when we have a culture of development that doesn't respect performance, the waste adds up and has a real impact on…

I don’t think a serious study of the issue can be done. Code review is the most difficult part of the development process (and a major advantage of open source), and businesses want to code the MVP as fast as possible without the competition copying them. The ideal language isn’t the most efficient language but one that is fast to develop, and leaves a possibility to optimize later. I would think languages like Nim a…

I agree on your comment about "most efficient language". And I agree that the business-interest is micro-focused on monthly-cost versus yearly- or even multi-yearly-cost.

I think those two things are at odds with each other. I think a lot of technical decisions are being made on a short-sighted business level. And I think a lot of people on the technology side have inculcated too much of the business message.

I'm not arguing against ever using languages like Python or Ruby or PHP or whatever. But I think a lot of people make assumptions that their language choice doesn't matter. In a lot of the same ways that building an entire economy on carbon fuels was "easy", it only worked because of externalities. As a profession, we need to be taking a longer view of our craft.

I don't think that it is true that it's impossible to make C++ secure. I don't think that it's true that--say--Java and C# are less productive than--say--Python or Ruby. On a surface level, certain things are easier, but once you start digging into real problems, there isn't much difference. And experienced developers in any language will be far beyond that surface syntax.

I just think that, as a profession, we have our priorities way out of whack.

Re: Debugging WebAssembly outside of the browser

#62
post #56

Earlier quoted context omitted.

I don’t think a serious study of the issue can be done. Code review is the most difficult part of the development process (and a major advantage of open source), and businesses want to code the MVP as fast as possible without the competition copying them. The ideal language isn’t the most efficient language but one that is fast to develop, and leaves a possibility to optimize later. I would think languages like Nim a…

I agree on your comment about "most efficient language". And I agree that the business-interest is micro-focused on monthly-cost versus yearly- or even multi-yearly-cost. I think those two things are at odds with each other. I think a lot of technical decisions are being made on a short-sighted business level. And I think a lot of people on the technology side have inculcated too much of the business message. I'm not…

Maybe your comment is based on thinking about a recent conversation instead of replying to my comment.

You make a few good points, but keep in mind that software development is both a centralization and planning problem. And exercising planning requires having accurate feedbacks.

Re: Debugging WebAssembly outside of the browser

#63
post #52

Earlier quoted context omitted.

> If you want to sandbox binary code, there are many much more efficient options, eg. Linux containers (especially with tools like gvisor) or VMs. WebAssembly is a VM, with an accompanying instruction format.[1] > Vendors that only allow use of WebAssembly are leaving performance and compatibility on the table. It'd be interesting to know what you're thinking of when you say that. For example, is Cloudflare leaving p…

And what if the windows users? Webassembly is a perfectly good container and would by default have crossplatform capability.

Just like when I deploy Jars compiled on Windows across Linux servers, amazing!

Re: Debugging WebAssembly outside of the browser

#64
post #55

Earlier quoted context omitted.

Netscape even had a JS debugger in '97 [0]. [0] http://www.rdwarf.com/lerickson/jscript/jsd.pdf

Wow, I wish I had known that back then. How did I miss that?

Don't worry, you didn't miss much. It was as stable as most software of that era.

Re: Debugging WebAssembly outside of the browser

#65
post #64

Earlier quoted context omitted.

Wow, I wish I had known that back then. How did I miss that?

Don't worry, you didn't miss much. It was as stable as most software of that era.

Though, surely it wasn't better than the IE js debugger. "Error on line 0"

Re: Debugging WebAssembly outside of the browser

#66

Earlier quoted context omitted.

Think of plugins for applications like Autodesk Maya. Currently these are either cross-platform, but very slow Python plugins, or fast native DLLs which need to be compiled for each app-version/OS/CPU combination. If Maya had an embedded WASM runtime it could support plugins which are fast (at least much closer to native speed than Python scripts), and you only need to distribute a single WASM blob.

Why not just use Lua?

Sometimes you need to embed libraries which are only available as C or C++, or other programming languages. If this code needs to be included into the Lua plugin as CPU/OS specific DLLs you're back at the current mess.
Post reply on HN