2 ms·

> The vast majority of the time it doesn't matter. I keep hearing this all the time and keep seeing all the time that it isn't true. Do you know of a single com

by patrec 7y ago

> The vast majority of the time it doesn't matter. I keep hearing this all the time and keep seeing all the time that it isn't true. Do you know of a single comparable Go web app that's not 10-100x less wasteful than goddamn gitlab? Most of the pathological sources of CO2 cloud emissions are a combination of terrible architecture and slow as molasses scripting languages like python or ruby. But these are not orthogonal. In theory gitlab could probably be 100x less wasteful even when written in Ruby. In practice many bad architectural decisions are far more likely to occur with Ruby and Python than a statically typed language (although Java may serve an interesting counter-example). > Using bytecode verification rather than an opaque binary, you can pack thousands of different web applications into a single process Can you expand on what problem this solves? Anyway, the problem isn't the bytecode, it's the shitty interpreter. There are plenty of bytecode based languages that are within < 10x of C.

jashmatthews 7y ago
Yeah, absolutely. I've worked on some incredibly poorly performing Go services. The idea that a team struggling to deliver on a roadmap and keep up application performance while using a high level language like Ruby will magically be able to do it while using a lower level language is just a complete fallacy. It never happens! People get bogged down. They don't write low allocation code. Nobody has any time to turn on the compiler warnings for escape analysis. Your benchmarks end up a year out of date and don't even run anymore. Architecture becomes an afterthought. Function/method calls end up becoming even slower gRPC calls as the team struggles to box up complexity and extracts more services. WRT bytecode verification it's better just to read this: https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime https://www.fastly.com/blog/announcing-lucet-fastly-native-w... There's nothing shitty about the CRuby bytecode VM. It's all a question of resourcing. You're doing a huge disservice to all the people who worked very hard to make CRuby 2.7 5-15x faster than 1.8 and it detracts from a valid discussion about reducing the CO2 footprint of datacenters around the world.

by patrec 7y ago

jashmatthews 7y ago

Yeah, absolutely. I've worked on some incredibly poorly performing Go services. The idea that a team struggling to deliver on a roadmap and keep up application performance while using a high level language like Ruby will magically be able to do it while using a lower level language is just a complete fallacy. It never happens! People get bogged down. They don't write low allocation code. Nobody has any time to turn on the compiler warnings for escape analysis. Your benchmarks end up a year out of date and don't even run anymore. Architecture becomes an afterthought. Function/method calls end up becoming even slower gRPC calls as the team struggles to box up complexity and extracts more services. WRT bytecode verification it's better just to read this: https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime https://www.fastly.com/blog/announcing-lucet-fastly-native-w... There's nothing shitty about the CRuby bytecode VM. It's all a question of resourcing. You're doing a huge disservice to all the people who worked very hard to make CRuby 2.7 5-15x faster than 1.8 and it detracts from a valid discussion about reducing the CO2 footprint of datacenters around the world.