
Porting Go to Linux on IBM Z Architecture - diakritikal
https://groups.google.com/forum/#!topic/golang-dev/y-mlM-XYysk
======
aus_
IBM has been recently promoting Docker on z. IBM argues the high I/O
capabilities of their platform are a good fit for the container model. (I
don't disagree with them. The many-application-on-big-hardware model is not a
new concept to IBM. Hell, they invented it.)

Anyways... Since Docker is written in Go, the only way Docker has been
available for s390x was by building with gccgo. My guess is that native Go
support is in the interest of Docker on z and would be a worthwhile investment
for IBM.

~~~
cbd1984
> Docker on z.

Docker on Linux on VM on LPARs on z.

Nobody say it...

~~~
rodgerd
More likely Docker on Linux on LPAR. At that point you'd struggle to see the
value of VM, other than making some of the device management/maintenance
easier.

------
nickpsecurity
Pascal once ran on IBM nainframes for an easy to learn, read, and compile
solution. Go is latest in Wirth philosophy of languages. Good it's going on
mainframe, too.

Even better is that it's often used for I/O intensive (eg networking)
applications. Mainframes' Channel I/O blows traditional server architecture
away in throughput. Should give a boost.

~~~
Cyph0n
Go is a Wirth language? Do you have a source for that?

~~~
nickpsecurity
I said "Wirth philosophy." It's his style of a language in action but invented
by others. Greisemer had enjoyed the simplicity and productivity of Wirth's
Oberon language at a point in the past. He wanted to re-create and expand on
that in their C++ replacement. Source is below:

[https://sourcegraph.com/blog/live/gophercon2015/123645585015](https://sourcegraph.com/blog/live/gophercon2015/123645585015)

~~~
Cyph0n
Yes, I got that. Thanks for the link!

------
bradhe
> IBM Linux on Z Open Source Ecosystem Center of Competency

Man, what a name for a group!

~~~
jgalt212
I enjoy SAP Center of Excellence

> Going live with SAP enterprise applications is only the end of the
> beginning. In order to thrive after go-live, you need the right organization
> to drive continuous business improvement.

[http://michaeldoane.com/SAP_Center_of_Excellence.html](http://michaeldoane.com/SAP_Center_of_Excellence.html)

------
copy
They also created a native OCaml backend for IBM Z very recently:
[https://github.com/ocaml/ocaml/pull/275](https://github.com/ocaml/ocaml/pull/275)

------
donatj
What is Z exactly if I may naively ask? I've heard it's name but I'm not
familiar.

~~~
skissane
CPU architecture of contemporary IBM mainframes. The 64-bit successor to the
24-bit/31-bit IBM System 360/370/390.

------
ju-st
IBM is really trying to make the mainframe "cool"

~~~
f2f
since when is the mainframe not cool?

~~~
ju-st
hip or trendy would have been better words (instead of cool) in my original
post I think

~~~
iheartmemcache
Won't happen and thank god too. The hip and trendy crowd have no idea how to
do long term support. JavaEE is the farthest from "hip and trendy" but you can
fire up a 15 year old WebSphere application on brand new hardware and it'll
work better than the day it was written, with full first-party support for
every component that was supported from day one. I've seen production code
REXX and JCL code from the 1970s which ran System/360 hardware with actual
decades of uptime since the IBM mainframe was 100% redundant (literally every
component from the DASD to the RAM and CPUs, which all supported hot-
swappability for upgrades and failover, all within a 42U). It boggles my mind
at how robustly these systems were designed. I.e., the original 360 code was
based on a weird-ass 31-bit architecture. Now z/10's can run in 64 bit mode,
32 bit, 31 bit[1], or 16 bits with full support for every single application
written from (theoretically 1964, but I've only seen code from the 70s still
running) all the way up to Clojure and Scala if you want it.

Take a look at all those hip Ruby frameworks and look at when Yehuda Katz last
made a commit to Merb and you'll figure out why CIOs still buy SAP and pay for
Oracle. IBM is lucky not to deal with the 'hip and trendy' demographic- it'd
just further damage their already faltering image in the corporate world.

The real market share they should be trying to pickup is not the frivolous Web
3.0ish junk. They instead should be pushing out a POWER8 + DB2 + fault-
tolerant (i.e., milliseconds failover, not seconds) for under 250k with an ERP
attached to it (partner with SAP Business One, 98% of the businesses doing
under 250MM in gross per annum don't need more htan that). AIX 7 already has
"Cluster-aware" software that does this, they just need to include it by
default for up to 4U. THEN, start price gouging. Market it under the name
"NEVER/down", partner with PureStorage or one of the new "EMC-killers", and
aggressively market it like they did during the Watson hype (tennis ad-buys,
advertising at LeMons, etc).

[1]
[https://en.wikipedia.org/wiki/IBM_ESA/390](https://en.wikipedia.org/wiki/IBM_ESA/390)

~~~
rodgerd
> you can fire up a 15 year old WebSphere application on brand new hardware
> and it'll work better than the day it was written, with full first-party
> support for every component that was supported from day one.

Spoken like someone who has never tried picking up code that worked fine on
WAS 6.1 and tried running it on 8.5.

~~~
iheartmemcache
Actually, I had to do that very recently. The difference between IBM and Ruby
was I called in with my client's license information and within 20 minutes my
IBM id had access to a WAS 6.x download. My client upgraded all their hardware
(this was from old iSeries AIX to a new POWER setup) and had zero-downtime
after completing the transition. The only difference was a significant
increase in speed. WAS 6 still is being actively supported and hot-patched for
security which is what my clients want.

You're right though - moving up major releases can break things sometimes. I
spent another couple of months forward-porting to Liberty so they could run
8.x but honestly most of the breaks I dealt with was dealing with third-party
functionality that the old off-shore team decided to throw in. Regardless,
during that period of time, my clients business was fully operational on that
new hardware with a secure, seamless transition.

I guess you sort of get the same 'future proofing' these days with VMware (the
analog is basically: having old hardware, then buying new hardware and
vMotioning your production instance to the new VMware ESX cluster), but you
certainly didn't have that option 15 years ago, when my client was choosing
what environment to run his oil/commodities firm. And that's just support on
the hardware stack, rather than the 10+ year support that most businesses want
as a guarantee.

