Go is "native code" but anyway nice work!

As always, it's a range.

Go has a runtime which you cannot control which schedules your code when it feels like it and a garbage collector. Rust has neither.

Sure, Go isn't parsing and interpreting its files at runtime. But neither does Python, so I'm not sure that's a meaningful line to draw.

> Sure, Go isn't parsing and interpreting its files at runtime

afaik, referring to something as "native code" just indicates it isn't compiled to/executing as bytecode. not anything to do with gc, runtime, etc.

Depends on who you ask. As demonstrated by literally every commenter in this thread so far.

Besides, define bytecode. Once it has run through a JIT and diverged from the on-disk representation, is it now native? How is it distinguishable from a binary that detects your CPU architecture and executes different branches of code? What about other forms of self-modifying code?

There are cases where an easy argument can be made (e.g. Java, which has a separately-supplied VM to run your bytecode... but then where's the line with DLLs?), but there isn't an unambiguous line in the sand here. At any line you can produce a new system that straddles it (e.g. a JAR which ships with its own VM. the VM is native code, is the binary now native or not?), and often there are already widely-used examples.

Is serde best in rust world.

Serde is definitely the standard for rust. There's another project, pikkr, that takes a different approach that can work well for specific workloads:

https://github.com/pikkr/pikkr