Hacker Newsnew | comments | show | ask | jobs | submit login

Try Go. No vm. Compiles super fast (one of the most annoying parts of static typing when used for big programs). Obvious and easy to use closures. Implicitly fulfilled interfaces for painless compile time duck typing, and type inference for less typing.



Of course it has a "VM" (aka runtime system), providing services like thread scheduling, garbage collection, IO management and so forth. It might just not be an easily accessible standalone VM like the JVM.

> Compiles super fast

Because it doesn't do anything. Seriously, it compiles fast because the type system is so trivial. No type inference (except the really restricted (:=) thing. And I can't even have polymorphic functions -- which we've known how to type check for around 40 years now.

This is a serious drawback if you are interested in type system support for code reuse.

-----


> Of course it has a "VM" (aka runtime system)

VM != runtime system. VM == virtual machine, bytecode.

-----


Virtual machines most certainly do not require bytecode.

GHC for example targets the "Spineless, tagless G machine" by compiling to native code that calls runtime services defined by the (abstract) STG machine ISA (the "primops").

Similarly, Go targets the Go runtime, by compiling to native code that calls "machine" services like collecting memory or scheduling threads. It might be a thin wrapper over the underlying processor architecture, but the compiler is clearly targeting the Go runtime as its target "machine".

-----


The Go runtime does nothing what a machine does. Compiled Go code consists of pure, native machine code instructions, no special opcodes. It's just that some additional functionality is statically linked in.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: