Hacker News Reader

Comment by andymcsherry | Hacker News Reader

The purpose of using a VM is that the developer ships one version of their compiled software that can be run by anyone who has the VM on their system. Otherwise, the developer needs to anticipate every single architecture a user might want to run it on. They might not be able to anticipate all these cases which might not even exist yet.

View on HN

There is also the Go approach, which is your code is platform independent, but you need to compile it for each platform. You get native code that is portable, best of both worlds. (Some might argue "Good C" can do this, but that is often quite hard and C doesn't have the kind of stdlib that Go has..)

I'd call that the static compiling approach, not just the Go approach. It's possible to statically compile in a wide range of languages.

I was using Go as an example of this. The majority of statically compiled languages don't support compiling the same source code to a multitude of platforms.

The same Go code and be compiled for x86, amd64, ARM and runs on Linux,OSX,Windows,FreeBSD,OpenBSD,NetBSD,Dragonfly,NaCL,Solaris and Plan 9. Not many statically compiled languages pull that off.

You can only pull that off in Go as long as you only use the runtime library, which is no different than other language.

As soon as you bring a third party dependency, game over.

>>As soon as you bring a third party dependency, game over.

There are tons of 3 party libraries written in pure platform portable Go that will cause you no issues. In fact the vast majority of 3rd party Go libraries are just as portable as the stdlib.

So they provide implementations on all targets supported by Go compilers for the features required outside stdlib?

The point is they don't have to- while Go compiled binaries are platform specific, pure Go code is platform independent. That means any platform that runs "go build" can run your Go program.

You are avoiding to answer the question.

There isn't pure Go code if it requires to touch the file system, talk to OS using APIs not available in the stdlib.

The moment you depend on libraries outside stdlib, you are opening yourself to dependencies to cgo and/or OS syscalls outside your control.

Even some stdlib packages are UNIX specific, e.g. os.user and log.syslog.

>You are avoiding to answer the question.

I'm really not, I am missing your point.

The majority of 3rd party Go code simply uses the Go stdlib just like our hypothetical program.

Go is no less platform independent then Java, for example, yes there are some 3rd party Java libraries that use JNI, just like some Go libraries use cgo.

The fact that these native bindings to (often) platform dependent code exist does not make pure Go/Java programs non-platform independent.

Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar.

> Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar.

The thing is, there aren't first and second class 3rd party libraries, all are 3rd party.

Back in the day all languages allowed this.

Go design leaves a lot to be desired, but at least it is a way to show the younger generations that didn't learned the above listed languages, how memory safe languages can be compiled to native code without a VM in the middle.

You don't need a VM for that, just as portable assembly kind of.

OS/400 binaries use portable bytecodes which are compiled into native code at installation time.

Alphas had binary translation between binary formats.

From your description that sounds very similar to NGEN-ing your .NET apps during install time, which is a bit fiddly but one .NET deployment option.

Yes, however ngen has the caveat that the required .NET version has to be present on the system.

A fat binary with both common native architectures and also vm code would seemingly take care of this edge case, no?

Also, what's wrong with emulation?

It's slow, complex, and unnecessary?

What about when it's a machine for which hardware doesn't actually exist... like a virtual one? How is that less unnecessary?

I wouldn't call a JIT compiler an emulator.

However, it's certainly unnecessary (why not just generate the machine code already?), and it generates slower code because JIT compiling is a more difficult task due to the fact that the time limits on the optimizer itself are pretty harsh.

Reply on news.ycombinator.com