[jpollock]

Programmers will write more efficient algorithms if their employers tell them to trade time-to-market for hardware cost. Previously, it was trade hardware cost for time-to-market.

"Programmers" don't make this decision, the product owner does.

[nananana9]

The classic excuse for industry-wide incompetence. The average programmer today can't write good code even if told it's an explicit priority.

The manager wants the Submit button to submit the form, they rarely care how the programmer does it. It's the programmer that chose to install the 11,000 node_modules, to use React with 3 layers of state management on top with hybrid SSR/CSR and to do Kubernetes because that's what was on Hacker News that day or whatever. And guess what, somehow the Submit button does still not submit the form 10% of the time.

Get rid of the junk and the program will be more efficient AND you'll ship quicker.

[mike_hearn]

How much "junk" do you want to get rid of?

I suspect you're imagining something like, just write some vanilla JS and maybe some tasteful but not bloated CSS.

You could do that. Then I'll come along with my old man Win32 skills and write a form with a submit button that sends the data by doing a memcpy into a UDP packet. It will take 300 kilobytes of RAM and start in 0.1 seconds. That'll make it approx 100x more RAM efficient than the baseline you can manage with Chrome, where an empty renderer process takes 23 MB of RAM to achieve nothing and starts so slowly the browser has to cache them in the background.

On the other hand, delivering features your users expect might be a bit harder. Shipping and updating that app will be painful for me, unless I use [plug] https://hydraulic.dev/ to make it easy [/plug], and the styling options are limited to setting solid color backgrounds on things. Things the product manager views as basic, like adding a dark mode, will take a surprising amount of effort. The app is likely to be more crash prone than the web app due to all the manual memory management required. Text zoom won't work. I'll have to write in C or maybe C++ if I'm feeling extravagent.

So there's got to be a balance somewhere. Features do matter.

[mwcampbell]

Rust with wxWidgets via wxDragon has recently become a viable option for some kinds of apps. It even has dark mode now. wxWidgets comes with a disappointing amount of bloat though.

[znpy]

> The average programmer today can't write good code even if told it's an explicit priority.

But what even is good code?

As an infrastructure guy i see my fellow software engineers endlessly debating and bikeshedding on anything but speed and memory consumption.

I see them arguing about functional vs object oriented, immutable data structures, test driven development, agentic bs, this or that interpreted language… never about reducing memory consumption .

[lpapez]

What is "good code"?

If you ask your boss, it will most likely be whatever spaghetti code which ensures the contract gets signed on time.

The boss doesn't care if the developer needs 10000 libraries for the submit button.

[fsloth]

"The boss" is not who says what is good enough. Ultimately it's the customer. In many industries it seems good enough is not very good.

Then there are industries where the customer complains if code is slow. They will actually hire expensive consultants to analyze and benchmark the code. And while the consultants likely are not more talented than inhouse staff, now you have both sides very interested at looking at the problem from engineering perspective.

In this case "good" includes performance.

[Pooge]

I disagree. Engineers choose the technical stack based on the specs.

With LLMs, it's faster to ship even in a more verbose language like Go or Rust.

[lionkor]

The language doesn't matter much if you have memory-hungry workloads. Whether it's Rust or C or C#, you can write quite memory efficient code in either.

[onion2k]

Most apps don't need much at run time though. There may be a big database somewhere, but the majority of SaaS apps are just some form of CRUD with a clever twist that might change the data occasionally, but doesn't use most of it when you render a page. The user data required for any given page is dwarfed by the memory required to run the language that converts the data to an HTML view.

For example, if you're rendering a user account page that has 100 data fields (name, address, etc), that's a few kilobytes at most. If your code is using Node of PHP you're probably using tens or hundreds of megabytes, possibly gigabytes, to turn that into a stream of HTML to send to the user.

I suspect using Claude to turn all the Node and PHP apps in the world to Rust or Go would massively reduce the necessity for huge datacentres using terabytes of memory.

[lowbloodsugar]

And Java? Language matters.

[Pooge]

I don't have any metrics in mimd but with GraalVM it's probably a much closer race. It's made by Oracle though...

[rixed]

Except that most of the time a workload is made memory-hungry by terrible technical decisions ("self-describing" text data encodings come to mind).

[retired]

I have never worked for a company where the engineers choose the technical stack. It’s always the architect, the CTO or the mother company that decides what technology to choose. Could be a German/Dutch cultural thing though.

[Byamarro]

Depends on a type of company, I work at a mid-sized startup and through lifecycle of this company there were times when we've had architects and there were times when we haven't. Rn we don't have and a lot of decisions is made within teams and we just try to keep communication about what's needed for business tight

[retired]

Understandable. I worked mainly for 100+ people companies and the tech stack impacts team interoperability, hiring, licenses, life cycle management etcetera.

[laughing_man]

The spec is the important part, though. If memory limitations are part of the spec, you're not going to choose a stack that will be too wasteful.

[Pooge]

Yes, but that doesn't determine the technical stack. It only narrows it down. You could just as well use C, C++, Rust or even Go depending on the device the program needs to run on. The device may have constraints as well but those are technical limitations and still not the responsibility of the product owner.

[wojciii]

I have a feeling that the bloated frontend is one of the mayor problems. We should get rid of html, CSS and JavaScript and implement something that could mix all of the above in a single spec and could be implemented using a VM with limited memory/instructions and still render a page one can interact with and use for control of for instance appliances.

[armada651]

Who determines the specs?

[Pooge]

Specs are business requirements. Choosing a programming language is not a business requirement; it's a technical one.

[shakna]

Platforms are often part of the business requirements.

If you're working on SAP or Salesforce, the language decisions are already made for you. If you're integrating with an existing Electron runtime, then you'll be using something in the JS family, like it or not.

[swiftcoder]

> Choosing a programming language is not a business requirement; it's a technical one.

Technical decisions like this have to take into account a lot of factors outside of just the language itself.

Is the language you want to use easy to hire for? Will we have to pay a premium for engineers with a specialised background in the language? Do all our 3rd party dependencies maintain SDKs for the language? Do libraries that meet various certifications we might need (i.e. FIPS) exist for the language?

Something like Typescript or Java is going to win out over Rust/Erlang/FP-of-your-choice on a number of these criteria.

[Someone]

> Choosing a programming language is not a business requirement; it's a technical one.

Not solely. The business will have reasons to stay on a mainstream language, for example because

- it offers better guarantees for hiring maintainers in the future

- it has a higher likelihood that security issues will be fixed rapidly for free

- LLMs are better at maintaining code written in it

[jpollock]

The programming language can have definite business impacts. It can impact hiring, salary costs (if the skill is rare), ramp-up costs (if it needs to be taught), etc.

Even bus-factor comes into it.

[Pooge]

Software engineering is an important skill to recruit for. Too many times I see "Java Developer"... Like, do they only know Java and are absolutely incompetent when it comes to something else?

I don't even want to recruit or be recruited with such a title.

[jpollock]

Yes, but even then there are people who will ramp up faster.

If the company is using Common Lisp, do you have the 6-12 months to wait for them to ramp up, or do you hire someone who has done Lisp before? That is downstream from the technical decision to use Common Lisp, but it is a huge business impact.

[exabrial]

> trade time-to-market for hardware cost

Enh. I think this only exists for some programmers, who can't write good code fast.

[dchftcs]

Whatever you're already able to do, you can do it better with more time.

[NewsaHackO]

source?

[d5lt5]

Ehm. I would assume your definition of writing good code fast is not what the majority of enterprise developers agrees with.

[Hendrikto]

Fast, correct, maintainable. Pick two.