bvisness (u/bvisness)

bvisness commented on I made a real-time C/C++/Rust build visualizer danielchasehooper.com/pos... · Posted by u/dhooper

dhooper · 20 days ago

(OP here) Thanks!

My call with the Mozilla engineer was cut short, so we didn't have time to go into detail about what he found, I want to look into it myself.

bvisness · 20 days ago

Hello, I am the engineer in question. I am not actually super familiar with the details of the build system, but from when I saw, the main issues were:

- Lots of constant-time slowness at the beginning and end of the build

- Dubious parallelism, especially with unified builds

- Cargo being Cargo

Overall it mostly looks like a soup of `make` calls with no particular rhyme or reason. It's a far cry from the ninja example the OP showed in his post.

bvisness commented on Is WebAssembly Memory64 worth using? spidermonkey.dev/blog/202... · Posted by u/bvisness

yuri91 · 8 months ago

Looking forward to progress on the memory control proposal(s). Another reason to want more than 4GB of memory is to have more address space, assuming that you have the ability to map it. With that capability Wasm64 could be useful also for apps that don't plan to use a huge amount for real.

bvisness · 8 months ago

Yes, this is my primary personal motivator as co-champion of the proposal. But, going “fully virtual” is hard because of the very wide array of use cases for wasm.

For example, there are embedded users of wasm whose devices don’t even have MMUs. And even when running on a device with an MMU, the host may not want to allow arbitrary mappings, e.g. if using wasm as a plugin system in a database or something.

It’s likely imo that any “fully virtual” features will be part of the wasm web API and not the core spec, if they happen at all.

bvisness commented on Clay – UI Layout Library nicbarker.com/clay... · Posted by u/ivmoreau

bvisness · 8 months ago

This is a delightful take on a style of UI I really love. Separating the UI logic from drawing with a set of draw commands is an excellent and very versatile idea - I first saw it in microui, and the separation allowed me to easily use the library in the browser using WASM and Canvas2D. (https://rxi.github.io/microui_v2_an_implementation_overview....)

Also, doing layout in WASM and rendering to HTML is a great idea that I can't believe I never thought of before.

bvisness commented on Micro-libraries should never be used bvisness.me/microlibrarie... · Posted by u/nalgeon

crabmusket · a year ago

While I mainly agree with the author's substantive point, though I find some of the ways it's presented in this post not entirely convincing or fair, I am interested that someone else has identified this:

> I have talked a lot about the costs of libraries, and I do hope people are more cautious about them. But there’s one factor I left out from my previous discussion. I think there’s one more reason why people use libraries: fear.

> Programmers are afraid of causing bugs. Afraid of making mistakes. Afraid of missing edge cases. Afraid that they won’t be able to understand how things work. In their fear they fall back on libraries. “Thank goodness someone else has solved the problem; surely I never would have been able to.”

I think this is true, but why does the JS ecosystem seem to have "more fear" than for example the Python ecosystem?

I wrote about this a while ago. I think that actually JS does (or did) cause more fear in its developers than other programming languages. I described it as paranoia, a more insidious uncertainty.

Quoting myself[1]:

> There are probably many contributing factors that have shaped NPM into what it is today. However, I assert that the underlying reason for the bizarre profusion of tiny, absurd-seeming one-liner packages on NPM is paranoia, caused by a unique combination of factors.

> Three factors have caused a widespread cultural paranoia among JavaScript developers. This has been inculcated over years. These factors are: JavaScript's weak dynamic type system; the diversity of runtimes JavaScript targets; and the physics of deploying software on the web.

...

> Over the years there has been rapid evolution in both frontend frameworks and backend JavaScript, high turnover in bundlers and best-practises. This has metastasized into a culture of uncertainty, an air of paranoia, and an extreme profusion of small packages. Reinventing the wheel can sometimes be good - but would you really bother doing it if you had to learn all the arcane bullshit of browser evolution, IE8 compatibility, implementation bugs, etc. ad infinitum?

> And it's not just that you don't understand how things work now, or how they used to work - but that they'll change in the future!

[1] https://listed.to/@crabmusket/14061/javascript-s-ecosystem-i...

bvisness · a year ago

I think the culture of JS has been reinforced over time, and the result is a novel form of paranoia. npm makes package-sharing easy, developers share trivial packages, people use trivial packages, people rationalize trivial packages, people teach beginners never to write code, beginners think they can never write code, beginners grow up and here we are.

Certainly the language is quirky, but it really doesn't change that much. Frameworks have come and gone but JavaScript itself is still the same. is-number would have looked much the same 15 years ago, if anyone was crazy enough to actually distribute it.

bvisness commented on Micro-libraries should never be used bvisness.me/microlibrarie... · Posted by u/nalgeon

DonHopkins · a year ago

>Micro-libraries should never be used

Passive voice. WHO should never use micro-libraries?

bvisness · a year ago

You, specifically.

bvisness commented on Micro-libraries should never be used bvisness.me/microlibrarie... · Posted by u/nalgeon

gerdesj · a year ago

"The library may be a bad fit for your problem."

How is this the fault of the library? You chose the wrong one!

"This often cancels out the primary benefit of libraries. No, you don’t have to write the code, but you do have to adapt your problem to fit the library"

You evaluated the library, found is unsuitable and yet, it is somehow their fault.

Why on earth would you project your own failures on to someone else's code? You do you!

bvisness · a year ago

If we had perfect knowledge, we could choose perfect libraries. But we don't. Maybe someday.

bvisness commented on Computers are amazing. So why is software so terrible? handmade.network/manifest... · Posted by u/Bluestein

nopassrecover · a year ago

As much as I’m agreeable to your general observation, I feel WordArt is a really poor example to illustrate your point: few software features have had such an aesthetic, meaningful, and human impact in the course of the Internet Age.

Oh how I yearn for a world of Geocities and FrontPage over Admiral anti-ad-blocker and GDPR cookie popups.

bvisness · a year ago

Yeah it's a baffling example to me. WordArt was really popular! People liked using it! The fact that it has aesthetically gone out of favor, years later, has nothing to do with software quality.

bvisness commented on Computers are amazing. So why is software so terrible? handmade.network/manifest... · Posted by u/Bluestein

1vuio0pswjnm7 · a year ago

Would like to see a blog post like this aimed at end users, not programmers.

It might be impossible to get programmers to stop writing garbage software and trying to get other people to use it. It might be possible to get end users to reject it.

bvisness · a year ago

That doesn't make sense to me. Unless users are presented with alternatives, they will have no choice but to use the garbage they are given - nor will they be able to recognize how much better software can be.

Better software has to start with the programmers. We're the only ones who ACTUALLY know what the hardware is capable of, and the only ones capable of setting those new expectations. This is why we aimed the manifesto at programmers. It is not the user's fault.

bvisness commented on Computers are amazing. So why is software so terrible? handmade.network/manifest... · Posted by u/Bluestein

TheAceOfHearts · a year ago

I'd agree that the current educational models for programming aren't the most effective, but I don't think any superior alternatives have been proposed or been made available. If someone developed a superior alternative then they would probably be able to quickly out-compete a bunch of companies, and eventually that new model would become widespread.

Personally I think that current platforms have too many layers of cruft that has never been cleaned up, so people have been forced to continue building bad abstractions on top of everything. We need base layers that integrate the lessons from the last couple of decades.

For all of the faults with the Web and tools like Electron, they've helped enable a massive amount of people to ship real useful software. Ideally there would be superior alternatives to something like Electron while still remaining accessible. One interesting example is ImGUI; I tried it out a while back and was amazed by the level of performance, but still had to deal with a lot of useless details related to build tools and cross-platform idiosyncrasies.

bvisness · a year ago

> Ideally there would be superior alternatives to something like Electron while still remaining accessible.

That's exactly why we in the Handmade Network community are building Orca (https://orca-app.dev/). It will take a while, but that's the goal.