<div dir="ltr">On Tue, May 10, 2016 at 2:42 AM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>> I hope that the packaging technologies are considered as part of the TC evaluation of a new language. While many alternative approaches are available, a language which could not be packaged into RPM or DEB would be an additional burden for distro builders and deployers.<br>><br><br>I mentioned in earlier replies but I may as well mention it again: a package manager gives you no advantage in a language toolchain like Go (or Rust). In fact, when you code is written in Go, you will be spared from dependency hell.<br><br>And, while not the official way to install Go, the Go toolchain can be packaged and in fact it is in Ubuntu 16.04 LTS:<br><br><a href="https://launchpad.net/ubuntu/xenial/+source/golang-1.6">https://launchpad.net/ubuntu/xenial/+source/golang-1.6</a><br><br><br>IMO, the best use case of not using a package manager is when deploying into containers -- would you prefer to just drop a static binary of your Go code, or you would rather install "apt-get" into a container image, and then install the language runtime via apt-get, and finally your application?? I don't know about you, but many startup companies like Go as it would give them much faster time to react.<br><br>Lastly, I would encourage anyone who has never even used Go to at least download the Go toolchain and install it in your home directory (or if you are committed enough, system wide), and then compile a few hello world programs and see what Go gives you. Go won't give you everything, but I am a "pick the right tool for the right job" guy and I am pretty happy about Go.<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>> Does Go present any additional work compared to Python in this area ?<br>><br>> Tim<br>><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><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><br>></div>