From: Rayson Ho <raysonlo...@gmail.com<mailto:raysonlo...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday 10 May 2016 at 01:43 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [tc] supporting Go
Go is a production language used by Google, Dropbox, many many web startups, and in fact Fortune 500 companies. 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: https://www.rust-lang.org/downloads.html > I have nothing against golang in particular but I strongly believe that > mixing 2 languages within a project is always the wrong decision 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++.) Rayson 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. Does Go present any additional work compared to Python in this area ? Tim ================================================== Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html > > 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. > > -Ben Swartzlander > > >> Also worth noting, is that go is not a "language runtime" but a compiler >> (that happens to statically link in a runtime to the binaries it >> produces...). >> >> The point here though, is that the versions of Python that OpenStack >> has traditionally supported have been directly tied to what the Linux >> distributions carry in their repositories (case in point, Python 2.6 >> was dropped from most things as soon as RHEL7 was available with Python >> 2.7). With Go, there might need to be similar restrictions. >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
