Hacker News Reader

Comment by rowanG077 | Hacker News Reader

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.

This sounds as insane to me as a carpenter who works with power tools saying. "Having safety measures which limits you and controls how you you have to do certain things does not sound appealing to those who need a house build, fast."

View on HN

I mean, while my understanding of the construction market is rudimentary at best - isn't it actually the case that construction often _does_ end up rushed, or compromised at design level, exactly because of that?

It's not good, and when a bridge falls over the results are a bit more... dramatic and undeniable - but it's not really my impression that other branches of engineering are particularly immune from corner-cutting and deliberate under-estimation.

Edit: though I'll say, just having someone "at random" say they expect better in their industry is an anecdotal evidence that it is at least a bit better. Also, you get to work outside. Truly, grass is greener on the other side of the road.

Or use a GC language with a great typesystem and have both safety and fast efficient development cycles.

That is an option, or if you don't want to deal with a GC because it's eating 70% of your clock cycles under load you can use rust get performance gains and still be writing safe code...

if your GC eats 70% is your clock cycles, your language has a broken GC. in modern Java/C#, GC time is rarely more than 10%

To get to a low GC overhead in Java (and perhaps other languages too) you have to pay with an increase in memory consumption. Sometimes as much as 100% additional RAM to avoid frequent full GC scans.

That's true, but malloc/free based systems also have a relatively high memory overhead due to fragmentation and programmers being worse at inserting frees than the GC. It's not at all clear that the C/C++ model of memory management has lower than 100% overhead for long running programs.

> but malloc/free based systems also have a relatively high memory overhead due to fragmentation

In case you haven't seen it, there's been some interesting progress on that front:

https://www.youtube.com/watch?v=c1UBJbfR-H0

Reply on news.ycombinator.com