4 ms·
I wouldn't want my pacemaker running a garbage-collected language and yet most web apps are written with GC. Google uses GC languages. GC can be done correctly
by silentOpen 17y ago
I wouldn't want my pacemaker running a garbage-collected language and yet most web apps are written with GC. Google uses GC languages. GC can be done correctly and efficiently.
TCO is not very hard to implement in a compiler/interpreter if considered from the beginning. Unless your compiler/interpreter was designed very poorly, it probably isn't very hard to implement later, either.
Given this, it doesn't really make sense to not trust TCO because it's somehow black magic. There may be other arguments against wanting TCO in your language of choice ("I really need backtraces all the time and I can't sacrifice simple, provable interpreter optimizations!") but reliability can't be it.
- DarkShikari 17y agoGiven this, it doesn't really make sense to not trust TCO because it's somehow black magic. I wouldn't say it's black magic at all--it's just that from my experience you can rarely even trust compilers with the most basic of things, let alone black magic.
- silentOpen 17y agoIf you're doubting your compiler for the most basic things, you may want to get a new compiler.
- mcav 17y ago> I wouldn't want my pacemaker running a garbage-collected language and yet most web apps are written with GC. I'd prefer GC over memory leaks...
- silentOpen 17y agoYou don't need either in a pacemaker, though. If you're dynamically allocating memory in a pacemaker, something's wrong.