Open Stack

On 05/09/2016 07:43 PM, Rayson Ho wrote:
> On Mon, May 9, 2016 at 2:35 PM, Ben Swartzlander <ben at swartzlander.org
> <mailto:ben at swartzlander.org>> wrote:
>  >>
>  >> Perhaps for mature languages. But go is still finding its way, and that
>  >> usually involves rapid changes that are needed faster than the
> multi-year
>  >> cycle Linux distributions offer.
>  >
>  >
>  > 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.
>
>
> 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 never tried to compare Go to Rust. Rust also strikes me as a rather 
immature language that we shouldn't use. My point though is not to 
fixate on the language and start a religious war. I have bad things to 
say about every programming language in existence. My point is that 
immature unstable languages are a poor choice to pair with a stable 
mature language like Python (25 years old!) This is primarily due to 
cultural fit.

Only a small fraction of the human beings on Earth can write code at 
all. Of those, some fraction knows Python well enough to write and 
maintain complex software written in Python. Some other fraction knows 
$COOL_LANGUAGE well enough to do the same in that language. The 
intersection of these 2 groups is inevitably vanishingly small.

>
>  > 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++.)

If you think Perl is "nice" or "easy" you better get you head checked.

Also, C is not really a programming language -- it's more like assembly 
code with a portability layer. C++ is not worth mentioning as a language 
to write anything in given the better alternatives.

My argument boils down to: don't force OpenStack to accept code written 
in $COOL_LANGUAGE because we don't all want to have to learn that 
language in addition to Python. Sure some people will, and some probably 
already have learned it, but in a functioning development team, EVERYONE 
needs to speak the same language or you get the I-can't-review-that-code 
or I-can't-fix-that-bug syndrome.

OpenStack succeeds spectacularly at being modular -- with literally 
dozens of small projects that work with eachother and with other 
components in the ecosystem. Go start another project. Go use whatever 
language you want. If you don't want to use Python then don't call it 
OpenStack.

-Ben Swartzlander


> Rayson
>
> ==================================================
> 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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>