Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



I'd add that for anything with more than one component that needs to communicate with other components, the Go channel abstraction will get you to a reasonably performant, reasonably correct solution reasonably quickly.

I used the same word three times because it may not hit any of those three bullet points 100%, if one wishes to build the fastest possible perfect emulator, but it's a decent starting toolset.


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


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?


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.


I wanted something relative to ANSI C, which has no closures, no concurrency, no garbage collection, and a standard library consisting of stone tools, without invoking the horrible term "Very High Level Language", which implies Visual Basic and copypasta. ;)

Perhaps I should have gone for the Monty Pythonesque "higher level than C but lower level than ASP.Net" term?


Perhaps the intention was to say "dynamic, interpreted" languages, rather than "high level"..




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: