undefined | Better HN

0 pointsceldon252y ago0 comments

> As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all.

This is a bit of an oversimplification. If you are sloppy with "memory management" (unnecessary object lifetimes, unnecessary duplication, etc) even in a GC language, it is possible to have noticeable performance impacts. I'm not saying these languages aren't the right tool for the job, but it is not a free pass to ignore hardware limitations.

0 comments

3 comments · 1 top-level

netbioserror2y ago· 2 in thread

Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications.

My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the worst case. Why did it need to be in C or Rust? It was never necessary, and I've been able to load it with features they never had but always wanted, in astoundingly short order.

Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams; meanwhile, entire classes of problems melt away.

celdon25OP2y ago

> Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams

I hate hearing this argument, because it glosses over the hard realities of building products, even if it sounds good on paper. Companies don't often have the resources to hire people that can do this early on, or the time to do this early on even if they do have the talent. And it might not be correct to do so when you have uncertain future requirements.

If that talent is you, you might not even be trusted to make those kinds of decisions until a year or two of tenure. And you might have junior (or even 'senior') devs on the side making changes that make this harder to do, without anyone realizing it.

So the reality is that you can't expect systems to be "architected properly" and you get what you get. It's an incremental process.

netbioserror2y ago

I have a personal experience that is literally the polar opposite of everything you just described. Atypical, yes, but on the other hand, testimonials about life in most other software teams describe an unnecessary mess of middle-management and bureaucratic cruft. I'm sure at many companies there are many roadblocks in the way between their developers and a better product, but my company doesn't have them. Not a startup, either. A 50-year-old engineering company that learned hard lessons after 20 years of stagnation.

I'm not going to be very sympathetic to counter-arguments about what "proper" practices we "should" follow, because quite frankly we're delivering features and value for our clients and catapulting back to the leadership position in our industry. Programming as a studied profession is barely half a century old, and the current zeitgeist of "best practice" is younger than some peoples' stints at the company they still work at. I'm very inclined to believe none of it is correct. No structural or architectural approach is one-size-fits-all and everything will be contingent on who you have and what you're trying to deliver.

1 more reply

j / k navigate · click thread line to collapse