Why bytecode (or more accurately, why dynamic languages)?
- if you have a one-off script for Ansible-style configuration management, dynamic languages are fine
- if you have ad-hoc script for data processing etc, dynamic languages are fine (Example: Underscore, lodash for Map/reduce, Python or Julia for data analysis, etc)
- Go (with its lack of generics by design) is ill-suited for data processing where Underscore or Python shines
Why bytecode-then-machine code?
Firefox, Safari and Internet Explorer each use different bytecode, Google’s V8 compiles directly to machine code.
Why machine code?
- because it’s C, C++, Go, Rust, etc
- because it’s V8
- you are concerned about performance.
- Read Axel Rauschmayer’s post here
- you need not concern about implementation of bytecode and machine code unless you are an engine developer
- if you have one-off or ad-hoc script, dynamic languages are fine.
- if it is a script that is executed many times (like a Web app), you trade performance over expressiveness using dynamic language at a cost that is of relative value to you
- if the functionality is relatively static by structure or by design (like Docker, RDBMS, Linux kernel, etc), you are better off with a compiled language mainly (or should I say solely?) for performance purposes
- The point above is best summed up by Axel Rauschmayer (as far as WebAssembly is concerned)
- In short, use programming languages by virtue of its design.