3 ms·

The vast majority of the time it doesn't matter. Most of us don't write performance critical code. Even games use bytecode VMs for scripting. You'd be better of

The vast majority of the time it doesn't matter. Most of us don't write performance critical code. Even games use bytecode VMs for scripting. You'd be better off spending the money saved on planting trees. If you write a web app in Ruby using a similarly light weight frameworks as you would using Go, you'll be lucky to get 3x the throughput out of the Go app. There are also ways to more efficiently utilize hardware by using bytecode than distributing binaries. Using bytecode verification rather than an opaque binary, you can pack thousands of different web applications into a single process. This is an application of webassembly which IMHO is much more promising than in-browser use.

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.

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.