Introducing the B3 JIT compiler

Re:Introducing the B3 JIT compiler by nickpsecurity on Monday February 15, 2016 @03:15PM (#11105615)

Can't critique this one: Go was an attempt to re-create the Oberon experience in modern setting with some additions from other languages. Rather than accidental re-discovery, getting Oberon (not Pascal) speed out of the compiler was an explicit design goal. One of few examples of modern IT really learning from the past.

Unfortunately, they didn't learn about the stuff between Oberon and 2007 that would've been nice to have in a modern, app language. ;)

[ Parent | on HN ]

Re:Introducing the B3 JIT compiler by pjmlp on Monday February 15, 2016 @03:38PM (#11105767)

It is not a critic, apparently it was understood as such.

The remark is tailored to those that think compiled languages can only be slow as C and C++ compilers, since they never used anything else, and then jump of joy when they use Go.

Yet if it wasn't for the VM detour of the last 20 years, that experience would probably be a current one, instead of being re-discovered.

[ Parent | on HN ]

Re:Introducing the B3 JIT compiler by nickpsecurity on Monday February 15, 2016 @04:04PM (#11105955)

"The remark is tailored to those..."

Ahh. Ok.

"Yet if it wasn't for the VM detour of the last 20 years"

You mean the C++ and VM detours? ;)

[ Parent | on HN ]

Re:Introducing the B3 JIT compiler by pjmlp on Monday February 15, 2016 @04:37PM (#11106214)

I mean having the JVM not adopt the tooling model of Eiffel, OCaml and others where you get to choose bytecode/JIT for developing and AOT compilation for release builds.

[ Parent | on HN ]

Re:Introducing the B3 JIT compiler by nickpsecurity on Monday February 15, 2016 @05:11PM (#11106438)

Oh i hear you. That makes sense. I wanted all of them to do incremental compilation or interactive development for build then AOT for deploy. We're on same page there.

[ Parent | on HN ]