<div dir="ltr">On Mon, May 9, 2016 at 2:35 PM, Ben Swartzlander <<a href="mailto:ben@swartzlander.org">ben@swartzlander.org</a>> wrote:<br>>><br>>> Perhaps for mature languages. But go is still finding its way, and that<br>>> usually involves rapid changes that are needed faster than the multi-year<br>>> cycle Linux distributions offer.<br>><br>><br>> This statement right here would be the nail in the coffin of this idea if I were deciding. As a community we should not be building software based on unstable platforms and languages.<br><br><br>Go is a production language used by Google, Dropbox, many many web startups, and in fact Fortune 500 companies.<br><br>Using a package manager won't buy us anything, and like Clint raised, the Linux distros are way too slow in picking up new Go releases. In fact, the standard way of installing Rust also does not use a package manager:<br><br><a href="https://www.rust-lang.org/downloads.html">https://www.rust-lang.org/downloads.html</a><br><br><br>> I have nothing against golang in particular but I strongly believe that mixing 2 languages within a project is always the wrong decision<br><br>It would be nice if we only need to write code in one language. But in the real world the "nicer" & "easier" languages like Python & Perl are also the slower ones. I used to work for an investment bank, and our system was developed in Perl, with performance critical part rewritten in C/C++, so there really is nothing wrong with mixing languages. (But if you ask me, I would strongly prefer Go than C++.)<br><br>Rayson<br><br>==================================================<br>Open Grid Scheduler - The Official Open Source Grid Engine<br><a href="http://gridscheduler.sourceforge.net/">http://gridscheduler.sourceforge.net/</a><br><a href="http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html">http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html</a><br><br><br><br> <br>><br>> If you want to write code in a language that's not Python, go start another project. Don't call it OpenStack. If it ends up being a better implementation than the reference OpenStack Swift implementation, it will win anyways and perhaps Swift will start to look more like the rest of the projects in OpenStack with a standardized API and multiple plugable implementations.<br>><br>> -Ben Swartzlander<br>><br>><br>>> Also worth noting, is that go is not a "language runtime" but a compiler<br>>> (that happens to statically link in a runtime to the binaries it<br>>> produces...).<br>>><br>>> The point here though, is that the versions of Python that OpenStack<br>>> has traditionally supported have been directly tied to what the Linux<br>>> distributions carry in their repositories (case in point, Python 2.6<br>>> was dropped from most things as soon as RHEL7 was available with Python<br>>> 2.7). With Go, there might need to be similar restrictions.<br>>><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>>><br>><br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div>