Hacker Newsnew | past | comments | ask | show | jobs | submit | bducycy's commentslogin

You're making the same 64k should be enough for anyone argument.

Just because we don't need it now, doesn't mean we won't. Just because we might not, the mere fact it becomes available drives prices of existing drives down. That is something everyone needs. That is something that moves society forward.


No, I don't think it's the same "64K should be good enough" at all. Even then many people were rightly skeptical btw.

As a guy who did the very occasional data science job, my iMac Pro's SSD tops out at ~2.7 GB/s in sequential workloads. For 4.5 years of using it I've only seen 3 programs being able to use its SSD to the absolute maximum, and the tasks lasted 30-40 seconds. So it didn't matter much.

I get it, there are people who do specialized work and are doing it every day and they need absolutely everything that the hardware can give them but realistically your average JS / Python / Golang / Rust dev having a 5700x with 32GB RAM and a 1TB NVMe SSD (e.g. topping at 4 GB/s) is not just quite fine, they are likely over-served even.

As a guy who peeked under the hood of a lot of open-source software, I have found that software is 99% of the bottleneck, even today. Almost nothing has changed.


I don't think you are correct on this, with ML workloads becoming a thing, increasing speeds across the board is extremely important.


And? You're saying all of us will train models all day?


This is the same 64k argument again.

You don't know what is possible with more resources being made available.

Eventually, people will figure out how to use them.

The main issue we face is that we're not limited by the top end, we're limited by the bottom end.

Bottom end computers are still running sata and 8gb of ram. Once you see that stuff move to 32gb and 1tb nvme, you might see changes in strategy.

Games are a big one for example, those things now run multi hundred GB, SSD speeds make a huge difference in what is possible there.

Just wait til game Devs figure out how to use generative ai backed by huge models disk speed and ram will definitely play a role.


These are pure hypotheticals and as such are not interesting at all.

People back then knew very well what they'd do with beyond 64K. Unlike you who is simply hand-waving this away by saying "who knows what will we use it for".

You're also forgetting financials which is quite a glaring omission. Modern computer prices haven't dropped much in a while now, like 5 years or so, because the bleeding edge remains expensive. Most people are unwilling to pay bigger and bigger prices for what they perceive as the same processing power -- and their perception is largely correct because software remains the dominating bottleneck in computing power.

So nope, it's not the same 64K argument again. We have companies that desperately want us to believe that we want 512 GB/s RAM modules and we should pay thousands for the privilege of having hardware that is only 0.1% likely to be utilized properly.

People do get hyped up when they see these impressive numbers, yes. But when they see the prices, they suddenly get smarter.


Nowhere am I saying consumers won't eventually use more bandwidth, just not in the current generation of hardware.

Also I'm not sure it really prices existing drives down any as much as prices new classes of drives up. Similar to data center GPUs not making the nvidia 4000 series dirt cheap compared to previous years - nearly the opposite it detracts from focus on the budget standard consumer focused segments


https://en.m.wikipedia.org/wiki/Extreme_programming_practice...

Agile is just scrum with less steps.

That said, the idea above that you can do software in year long release cycles is pretty insane.

Release cycles and amount of stakeholder feedback that should be involved in the development process is unique per business and industry needs.


Nicely compatible, until it's not.

We banned all these forks at work.

The dev onboarding overhead is not worth the benefits.

Having all 1700 repos using the same build tooling is more important than slight increases in build performance.


Why do you have 1700 repos?


The wonders of JavaScript package dependencies, where basic CS stuff is a function exported as a package.


Probably an agency environment, or a enterprise environment that insists on having private mirrors of all 3rd party code.


Banned? Is that why you had to post this on a green text account? Because that sounds immature. If you really have so many repos it sounds annoying that there isn't room for team level experimentation.


Devil's advocate: Deno and Bun are not yet fully backwards compatible with Node. I myself have run into a _ton_ of pain trying to introduce Bun for my team.

This can become a big time sink on bigger teams. That time could be saved by just not allowing it until a full team initiative is agreed on.


It's not immature, it's pragmatic. You do have to weigh the benefits of being able to use non-standard tools vs the cost of having not being able to reuse the same tooling, linters, compilers, and what-not for all projects.

When you have a lot of projects to support, it's rare for the benefits to outweight the costs


> If you really have so many repos it sounds annoying that there isn't room for team level experimentation.

For what it's worth, I'll say that I can understand such top down governance: you'd have an easier time around moving across projects that you work on within the org, there'd be less risk of a low bus factor, BOM and documentation/onboarding might become easier.

Same as how there are Java or .NET shops out there, that might also focus on a particular runtime (e.g. JDK vendor) or tooling (an IDE, or a particular CI solution, even if it's Jenkins).

On the other hand, if the whole org would use MySQL but you'd have a use case for which PostgreSQL might be a better fit, or vice versa, it'd kind of suck to be in that particular situation.

It's probably the same story for Node/Deno/Bun, React/Vue/Angular or anything else out there.

No reason why that mandated option couldn't eventually be Bun, though, for better or worse.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: