upvote

points

by Pooge3 days ago |
comments
upvoteby lionkor3 days ago|
next
[-]
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.
reply
upvoteby onion2k3 days ago|
parent|
next
[-]
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.

reply
upvoteby lowbloodsugar3 days ago|
parent|
prev|
next
[-]
And Java? Language matters.
reply
upvoteby Pooge3 days ago|
parent|
[-]
I don't have any metrics in mimd but with GraalVM it's probably a much closer race. It's made by Oracle though...
reply
upvoteby rixed3 days ago|
parent|
prev|
[-]
Except that most of the time a workload is made memory-hungry by terrible technical decisions ("self-describing" text data encodings come to mind).
reply
upvoteby retired3 days ago|
prev|
next
[-]
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.
reply
upvoteby Byamarro3 days ago|
parent|
[-]
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
reply
upvoteby retired3 days ago|
parent|
[-]
Understandable. I worked mainly for 100+ people companies and the tech stack impacts team interoperability, hiring, licenses, life cycle management etcetera.
reply
upvoteby laughing_man3 days ago|
prev|
next
[-]
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.
reply
upvoteby Pooge3 days ago|
parent|
[-]
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.
reply
upvoteby wojciii3 days ago|
prev|
next
[-]
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.
reply
upvoteby armada6513 days ago|
prev|
[-]
Who determines the specs?
reply
upvoteby Pooge3 days ago|
parent|
[-]
Specs are business requirements. Choosing a programming language is not a business requirement; it's a technical one.
reply
upvoteby shakna3 days ago|
parent|
next
[-]
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.

reply
upvoteby swiftcoder3 days ago|
parent|
prev|
next
[-]
> 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.

reply
upvoteby Someone3 days ago|
parent|
prev|
next
[-]
> 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

reply
upvoteby jpollock3 days ago|
parent|
prev|
[-]
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.

reply
upvoteby Pooge3 days ago|
parent|
[-]
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.

reply
upvoteby jpollock3 days ago|
parent|
[-]
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.

reply