CC: Dan Horák, Jeffrey Scheel.
Hello All!
I'm going to speak at the next Moscow Golang User Group this November and will describe some of Fedora Golang SIG plans. Here are the slides (in Elglish and in Russian):
* http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup... * http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup...
I won't talk about Docker (my fellow golangers from Yandex will do), and won't tell anything about etcd (we still don't decide what to do with it). Instead I'll describe my effords to fix long-standing issue with systemd and multiple Erlang nodes running in parallel. I did few attempts to fix that issue with different success, and finally switched over to golang-powered solution which fixes it (and makes a room for further improvements).
This will have an interesting consequence for the secondary arches, such as s390/s390x and PowerPC. In the future all Erlang services in Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service written in golang (I wouldn't use word "*require*" here). Since golang is available only for x86/x86_64 and ARM, this could be an annoyance. Technically it will still be possible to run Erlang daemons on the secondary arches, but it will require some painful manual intervention, and lead to inevitable race conditions. Beware! Also I hope we'll see some progress on porting Golang on these achitectures.
On Fri, 8 Nov 2013 14:43:48 +0400 Peter Lemenkov lemenkov@gmail.com wrote:
CC: Dan Horák, Jeffrey Scheel.
Hello All!
I'm going to speak at the next Moscow Golang User Group this November and will describe some of Fedora Golang SIG plans. Here are the slides (in Elglish and in Russian):
http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup...
http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup...
I won't talk about Docker (my fellow golangers from Yandex will do), and won't tell anything about etcd (we still don't decide what to do with it). Instead I'll describe my effords to fix long-standing issue with systemd and multiple Erlang nodes running in parallel. I did few attempts to fix that issue with different success, and finally switched over to golang-powered solution which fixes it (and makes a room for further improvements).
This will have an interesting consequence for the secondary arches, such as s390/s390x and PowerPC. In the future all Erlang services in Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service written in golang (I wouldn't use word "*require*" here). Since golang is available only for x86/x86_64 and ARM, this could be an annoyance. Technically it will still be possible to run Erlang daemons on the secondary arches, but it will require some painful manual intervention, and lead to inevitable race conditions. Beware! Also I hope we'll see some progress on porting Golang on these achitectures.
Is there a strict dependency on golang or just on go? Because "GCC 4.8.2 provides a complete implementation of the Go 1.1.2 release." citing from gcc 4.8.2 release notes and we build gccgo on all our secondary arches.
Dan
2013/11/8 Dan Horák dan@danny.cz:
On Fri, 8 Nov 2013 14:43:48 +0400 Peter Lemenkov lemenkov@gmail.com wrote:
This will have an interesting consequence for the secondary arches, such as s390/s390x and PowerPC. In the future all Erlang services in Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service written in golang (I wouldn't use word "*require*" here). Since golang is available only for x86/x86_64 and ARM, this could be an annoyance. Technically it will still be possible to run Erlang daemons on the secondary arches, but it will require some painful manual intervention, and lead to inevitable race conditions. Beware! Also I hope we'll see some progress on porting Golang on these achitectures.
Is there a strict dependency on golang or just on go? Because "GCC 4.8.2 provides a complete implementation of the Go 1.1.2 release." citing from gcc 4.8.2 release notes and we build gccgo on all our secondary arches.
There won't be a *dependency*, just an additional highly desired systemd-service. If no such service was found it will continue working as it does right now. If this service is available then systemd starts it, so Erlang-based application will benefit from it (this will resolve some issues mysterious for the end users). Also I think of adding something like this into Erlang spec-file:
%ifarch %{ix86} x86_64 %{arm} Requires: eclus %endif
As for eclus dependency on golang that's another interesting story. Actually eclus doesn't require golang for building, and frankly speaking I think we shouldn't require golang anywhere else for that - instead we should come up with some kind of virtual provides for that. I've built eclus with gcc-go and it works quite fine. In fact I'm using exactly that build for a couple of weeks already w/o any issues. However gcc-go doesn't improve situation with secondary arches:
http://thread.gmane.org/gmane.linux.redhat.fedora.golang/23
On 08/11/13 12:01 +0100, Dan Hor?k wrote:
On Fri, 8 Nov 2013 14:43:48 +0400 Peter Lemenkov lemenkov@gmail.com wrote:
CC: Dan Horák, Jeffrey Scheel.
Hello All!
I'm going to speak at the next Moscow Golang User Group this November and will describe some of Fedora Golang SIG plans. Here are the slides (in Elglish and in Russian):
http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup...
http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup...
I won't talk about Docker (my fellow golangers from Yandex will do), and won't tell anything about etcd (we still don't decide what to do with it). Instead I'll describe my effords to fix long-standing issue with systemd and multiple Erlang nodes running in parallel. I did few attempts to fix that issue with different success, and finally switched over to golang-powered solution which fixes it (and makes a room for further improvements).
This will have an interesting consequence for the secondary arches, such as s390/s390x and PowerPC. In the future all Erlang services in Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service written in golang (I wouldn't use word "*require*" here). Since golang is available only for x86/x86_64 and ARM, this could be an annoyance. Technically it will still be possible to run Erlang daemons on the secondary arches, but it will require some painful manual intervention, and lead to inevitable race conditions. Beware! Also I hope we'll see some progress on porting Golang on these achitectures.
Is there a strict dependency on golang or just on go? Because "GCC 4.8.2 provides a complete implementation of the Go 1.1.2 release." citing from gcc 4.8.2 release notes and we build gccgo on all our secondary arches.
gccgo will compile on any arch it is available, while the golang compiler has a more limited scope. So far the golang libraries that are packaged are source only, so anyone wanting to build with gccgo, need only set up their compile flags to -I the directories of the libraries needed. This is left as somewhat of an exercise for those interested. Since some projects will have tuned their resulting executable/binary builds to using the golang compiler instead of the gccgo.
Take care, vb
2013/11/8 Vincent Batts vbatts@redhat.com:
On 08/11/13 12:01 +0100, Dan Hor?k wrote:
Is there a strict dependency on golang or just on go? Because "GCC 4.8.2 provides a complete implementation of the Go 1.1.2 release." citing from gcc 4.8.2 release notes and we build gccgo on all our secondary arches.
gccgo will compile on any arch it is available, while the golang compiler has a more limited scope. So far the golang libraries that are packaged are source only, so anyone wanting to build with gccgo, need only set up their compile flags to -I the directories of the libraries needed.
As I said there is an problem - gcc-go does compile just fine, but the resulting binary will refuse to run due to (maybe artificial) limitations in the golang source code. (Un)fortunately gcc-go shares a lot of code with golang itself so it doesn't add much to the hardware support.
Hey, Peter, thanks for keeping me in the loop on your presentation. One comment: if gcc-go has problems or is generating faulty binaries, you should create a defect in the gcc-go community. My colleague Bill and others are willing and eager to work these. -Jeff
Jeffrey J. Scheel
From: Peter Lemenkov lemenkov@gmail.com To: Vincent Batts vbatts@redhat.com, Cc: golang@lists.fedoraproject.org, erlang@lists.fedoraproject.org, Jeffrey Scheel/Rochester/IBM@IBMUS Date: 11/09/2013 02:19 AM Subject: Re: Slides from my future talk at Moscow Golang User Group meetup
2013/11/8 Vincent Batts vbatts@redhat.com:
On 08/11/13 12:01 +0100, Dan Hor?k wrote:
Is there a strict dependency on golang or just on go? Because "GCC 4.8.2 provides a complete implementation of the Go 1.1.2 release." citing from gcc 4.8.2 release notes and we build gccgo on all our secondary arches.
gccgo will compile on any arch it is available, while the golang compiler has a more limited scope. So far the golang libraries that are packaged are source only, so anyone wanting to build with gccgo, need only set up their compile flags to -I the directories of the libraries needed.
As I said there is an problem - gcc-go does compile just fine, but the resulting binary will refuse to run due to (maybe artificial) limitations in the golang source code. (Un)fortunately gcc-go shares a lot of code with golang itself so it doesn't add much to the hardware support.
erlang@lists.fedoraproject.org
-
Dan Horák -
Jeffrey Scheel -
Peter Lemenkov -
Vincent Batts