Comment by winter_blue | Hacker News Reader

Comment by winter_blue | Hacker News Reader

Parent Full thread

> Do dynamically-typed languages inherently damage the environment? Or is it the fossil fuels?

My opinion is that slow languages that use 10x the electricity, with no ROI for the 10x energy use is bad.

High energy use, even if it's clean energy, implies a higher environmental toll. If a country were solely using nuclear and solar, higher energy use results in (1) more nuclear reactors constructed, and (2) more solar panels built. The manufacture and construction of both has an environment cost. Of course, with fossil fuels, the damage to the environment is potentially a lot worse.

> Not that the appeal to the environment matters

I don't think higher energy use is inherently bad. If we can improve the quality of life for human beings, then IMO a higher energy use is justified. I don't really believe in degrading our quality of life to lower our energy use.

My problem with many popular slow languages is that they have a negative ROI for the higher electricity cost. In exchange for 10x the energy use, you have a language that results in less-readable code (a serious issue), that causes more bugs / less-reliable software, etc. We literally a get negative ROI in exchange for 10x the energy use. Which is absurd and illogical.

If Hindley–Milner type inference had been more prevalent in the 1990s, I have a feeling dynamically-typed languages would have never take off. We're moving back to static typing with mypy, TypeScript, etc., but I'm hoping we move away entirely soon from using slow languages for writing servers serving large numbers of users.

If we actually got something in exchange for it, it wouldn't bother me so much.

For the vast majority of projects this makes no difference. If you are at Facebook scale? Sure. But then, you do what they did, write a VM to speed things up.

Dynamic typing doesn't cost much more money on average and thankfully the cost of energy itself is a motivation for companies to do rewrites. If they are paying a lot in server costs and electricity then they do typically rewrite to reduce the amount of servers.

For companies they primarily need to worry about running at a profit and getting to market quickly which dynamic languages do extremely well, and the costs in electricity and carbon aren't very high when your scale is small.

> running at a profit and getting to market quickly which dynamic languages do extremely well

This (or similar variants of this) is an assertion that's commonly made about dynamically-typed languages, but I don't think they hold any water.

Less readable code (due to the lack of types) makes it a lot harder to add new features, and harder to debug code as well.

Several years ago, I briefly worked on a fairly large codebase at a startup that was written in a Ruby on the backend, and CoffeeScript on the front-end. There were only around 60,000 active users. Yet, the dynamic typing made adding new features, or fixing a bug a truly painful and fragile experience. Needlessly painful, and slow. It literally reduced developer velocity.

I think once you cross a few hundred lines, dynamic typing becomes a handicap rather than an advantage.

All of this doesn't even touch on the energy use. Which I'll admit is irrelevant to most companies. Server costs even for popular web/SaaS/etc tech companies are often a tiny tiny fraction of overall cost, with most of the company's annual operating cost being employee salaries. (As I had stated earlier, I don't mind a language being slower - if it actually provided any advantages–like improved developer productivity, in exchange for that slowness.)

The main argument here was about the energy costs. But it sounds as though you don't like dynamically typed languages. That's fine.

Facebook, twitter and plenty of of billion dollar businesses were built with dynamic languages and many would argue they may not have even existed if they were written in staticly typed languages due to the slower up front time expenditure.

I like staticly types languages for large projects but enjoy thr development speed of dynamic ones. If you don't like dynamic that's completely fine

> they may not have even existed if they were written in staticly typed languages

This is pure speculation. There's no way you can back this up with any sort of real data.

The inverse isn't true either. StackOverflow was written in C#, and it's been doing perfectly well.

I've addressed another commentor making a similar presumption as you, here: https://news.ycombinator.com/item?id=37312297

The only thing I'll concede is that using a statically-typed language without a good type inference system, might slow people down a tiny bit.

The serious downsides of dynamic typing means you might still win out (in terms of developer productivity, code readability, code reliability, and ease of debugging) even if you use a language like Java instead of PHP.

Stack overflow is miniscule compared to Twitter or Facebook. You can just book at Basecamp if you want to pick a smaller company. They are Ruby on Rails and they have been consistently doing well.

Ultimately billion dollar companies have been built on dynamic languages. There is nothing stopping you from succeeding with dynamic languages. There just isn't. There are tradeoffs and these companies made them.

I agree that there isn't much necessarily stopping a person succeeding due to the choice of language (unless it's some esoteric or otherwise unrealistic language).

Yahoo used C++ for instance (it would not be my choice, even though it's weakly statically-typed).

But, yea, like you said--there are tradeoffs.

I think dynamically-typed languages has the allure of letting you build quickly initially, but the downsides of dynamic typing start hitting pretty soon afterwrd.

I write a lot of small scripts in Python. It certainly is easier to throw something quickly together, especially when the data model is amorphous, with dynamic typing. But that doesn't mean I'd use Python for a large project.

Reply on news.ycombinator.com