
Go, the language for emulators - geetarista
http://dave.cheney.net/2013/01/09/go-the-language-for-emulators
======
shardling
So, I don't see that the article mentions _why_ the language is good for
emulators.

~~~
swdunlop
Off the top of my head, I can think of a few why Go is better than Python or
other high level languages for writing an emulator:

\- Go makes it easy to write a process for your emulator, instead of a state
machine.

\- Go's slice types makes passing blocks of memory around a zero copy
operation.

\- Pass by value lets you reduce the number of objects GC must trace.

\- Go is explicit about integer size and sign, makes conversion errors more
visible.

It's not better than C, but it's certainly easier to work with. I'm routinely
surprised at how C-friendly Go's produced code is -- take a spin through
profiling some of the image library primitives and compare them against your
favorite C library.

~~~
shardling
Comparing it to high level languages seems to be a bit of a red herring...

~~~
jlgreco
Holy moly "high level language" is a moving target. A language with closures,
built in high level concurrency, garbage collection, no pointer arithmetic,
and a 'batteries included' standard library _isn't_ high level these days?

~~~
shardling
What? I wasn't saying anything about Go. (swdunlop is the one who injected the
term "high level" into the discussion.)

But if you claim that language X is good at Y, implicitly you're comparing it
with _all_ languages, not a subset. AFAIK most emulators are written in C or
assembly or the like -- so it's especially odd to compare Go to everything
_but_ them in this context.

------
cwzwarich
If you're writing a good emulator, you're going to want it to generate machine
code. Doesn't that interact poorly with Go?

~~~
ajross
Not necessarily. Computers are so fast these days that real time simulation of
a lot of these older systems in interpreted environments (a naive C
instruction interpreter, or even Javascript, etc...) is perfectly feasible.
The Apple ][ had a 1MHz clock, a CPU that took 2-10 cycles per instruction,
and an 8kb framebuffer that refreshed at 60Hz. That's not a lot of work to
emulate.

~~~
mithaler
That depends on what your standard of accuracy is.
[http://arstechnica.com/gaming/2011/08/accuracy-takes-
power-o...](http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-
mans-3ghz-quest-to-build-a-perfect-snes-emulator/)

~~~
ajross
That's a fair argument, but "accuracy" isn't really the right word. Because
then you'd have to deal with the fact that the color gamut from a 1982 NTSC TV
is different from your LCD. Similarly I've never seen a good simulation of
interlace flicker (not an issue on the NES though -- it didn't interlace) on a
LCD either. The impedance mismatch between a NES controller and a modern
keyboard alone is much higher than that beteween a "naive" simulation and the
one in that article.

And if you want to go down the "elaborate" road, there are even niftier
projects out there like the Javascript transistor-level simulation of a 6502.

There's always room to spend cycles. But simulating a 1980's computer to the
level of precision required by "correct user experience" is a straightforward
engineering task these days that doesn't require anything more than "just
plain code."

------
frozenport
The systems emulated look quite primitive and, hence, give off the opposite
impression: it feels like Go is not able to make a serious emulator. I suspect
there are more complex emulators in javascript.

~~~
btrask
I'm not going to enter a language flame war, but I was quite impressed by
n64js. <http://n64js.blogspot.co.uk/>

------
vor_
"It turns out that Go is a great language for writing retro-computing
emulators."

Why?

