Hacker News Reader

Comment by geodel | Hacker News Reader

One benefit you miss is by using Go in GC all Go tools (fmt, profiler, vet, godoc lints etc) available to writers of GC also which was not possible with C.

I think it is similar to Oracle was trying to JVM in Java known as Maxine. Now JVM contributors or potential contributors would know C++ but from OpenJDK website one motivation was to leverage amazing Java tooling to write its own VM.

I just noticed Oracle seems to have removed references to Maxine VM from Oracle website and OpenJDK website. Seems that project is no longer active.

View on HN

Try searching for Graal instead.

https://github.com/graalvm/graal-core

Thanks.

From the link:

> Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM

I am not sure if this is Maxine VM which I thought something analogous to Hotspot JVM. Or may be Maxine was similar in scope as the link you have given and not an experimental or otherwise replacement of Hotspot JVM

It's the JIT compiler written in Java that was in Maxine, updated, integrated into Hotspot so you don't need to use an experimental VM to use it.

Maxine is still alive though - but I think the only people maintaining it are academics.

Ok, makes sense. Maxine might be now independent of Oracle as links from Oracle website goes nowhere.

It isn't Maxine. I believe Maxine lives on in the Oracle-only "Substrate" project. But there is also Jikes which is a similar jvm-in-java project.

equivalents to all those tools (and more) are available in the C ecosystem.... just saying....

BTW: C is a much more mature ecosystem than that of Go.

C has an eco-system? Really? Yeah, sure I can download source code and headers and somehow use 12 different antiquated tools that strung together with duck tape and bubble gum that are also not standard on Windows let's say, to actually hopefully compile that code, and then worry about 12 other different tools each with 6 different options to be able to do something simple like "link a library", and hope that works on FreeBSD and OS X and Windows, but it won't, it never does, without spending an insane amount of time tweaking headers and m4 macros, before giving up and learning CMake, but if that's what you consider a "mature eco-system", then you have very low standards.

No one doubts that there is a rich ecosystem available for C. The thing just is, when you are working in a Go environment, what benefit would adding C with its own toolchain bring?

No need for bootstrapping step, 90% of portability taken care off for free, ability to use lower level and faster primitives than Go offers, access to tons of great C libraries.

> 90% of portability taken care off for free

You sir, have clearly never attempted to write portable C or Go code. Writing portable C code takes a serious effort. It's not hard if you know what you have to pay attention to - but 90% portability taken care of for free? That's simply not true, unless you think being portable is "it runs on a POSIX system".

Writing portable Go code - in most cases - you don't need to do anything or make only slight changes to your code, and cross-compiling is the easiest I've ever encountered.

> ability to use lower level and faster primitives than Go offers

Like what? Go's unsafe code is free from doing almost anything (except things like array bound checks that are always enforced).

Not the build system, a pain to get the libraries in Windows for a Multiplatform project that I wanna compile.

Where in Go this is very easy

There have been similar Smalltalk-in-Smalltalk, Lisp-in-Lisp, and Java-in-Java, etc. projects.

I have yet to see one that lead to better garbage collection.

Reply on news.ycombinator.com