4 ms·
There are no fair benchmarks between programming languages. > When a measure becomes a target, it ceases to be a good measure. If you're deciding what languag
by nindalf 4y ago
There are no fair benchmarks between programming languages.
> When a measure becomes a target, it ceases to be a good measure.
If you're deciding what language to use for your next project, there are better ways. Ask yourself these questions.
- Can developers be hired/trained to use it?
- Will they be happy using it?
- What will our development velocity be on this language? What will be the operational burden of keeping it running in production?
- Do we need to rely on third party code? Does that code already exist and what is it's quality?
Importantly, how will the answers to these questions change over time? Will this language be just as easy to hire for in 5 years time?
Comparing languages by benchmarks is a waste of time.
- galangalalgol 4y agoWere those prioritized? I would have put velocity first,then will devs like it. Those are coupled. If they like it, it is less important if you can hire people who know it already, and likewise, if your velocity is high, maintainability becomes less important. All those are subject to physical constraints though. Much of the worlds code is embedded, and thus severely constrained in both compute and power. That limits your choices, but within those choices your criteria are still absolutely the correct ones.
- nindalf 4y agoMy list was not prioritised and not exhaustive either. As you correctly point out, physical constraints matter. If there are other requirements like real-time, low latency or high throughput, we have to take those into account as well.
- jackmott42 4y agoIgnoring performance has gotten many companies in a terrible bind down the road. Not all people's projects are performance irrelevant.