[OT] Python like lanugages [was Re: After C++, what with Python?]

[Tim Harig]

On 2011-01-17, geremy condra <debatem1 at gmail.com> wrote:
> On Mon, Jan 17, 2011 at 1:07 PM, Tim Harig <usernet at ilthio.net> wrote:
>> On 2011-01-17, geremy condra <debatem1 at gmail.com> wrote:
>>> On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig <usernet at ilthio.net> wrote:
>>>> On 2011-01-16, geremy condra <debatem1 at gmail.com> wrote:
>> Go is every bit of a general purpose programming language.  It is useful
>> for the same basic applications that you would otherwise write in Java.  It
>> can do pretty much anything that you can do in C, with the probable
>> exception of writing operating systems.  I have been using C/C++ for most
>> of my programming career; but, everything that I have done can be done with
>> Go.  I am not really sure where you are seeing such narrowing limitations.
>
> Some people get very attached to one language and use it for
> everything. I'd rather use the right tool for the job.

I much agree.  You don't see me dropping python, shell, awk, etc.  I do
expect Go will enter some of the programming that I am doing in Python and
it will almost certainly replace much of the programming that I am doing in
C/C++.

> Go is not an ideal language for high-performance code. Despite the
> occasional claims of others, Go is consistently outperformed by C,
> C++, and Java on a wide variety of benchmarks. Some claim that Ada and
> Haskell do as well, and my benchmarks (CPU bound, focused on speed of

I much agree that Go doesn't beat C or C++.  I really doubt that it could
with the runtime necessary to do garbage collction.  Nevertheless, I find
that Go can be optimized to perform within tolerable limits of C given the
boost it gives in development.

I really question that you get Java anywhere even close to C performance.
Google reports they get within the same order of magnitude as C for
their long-lived server processes where the JIT has had time to optimize
its results.  For shorter term processes such as desktop applications,
Java performance stinks -- even after you discount the JVM starup time.

Ada is capable of C++ like performance *if* you compile it to remove *all*
of runtime checking.  Depending what checks you enable, it can run much
slower.

> cryptographic primitives) *seem* to confirm that for Haskell. I say
> 'seem' because I'm clearly much more familiar with Haskell than with
> Go, and would be inclined to question my conclusions if they weren't

I have not worked with Haskell, so I don't really have any idea's about its
performance.  I understand that leveraging lazy evaluation and result
caching can provide some *huge* opportunities for optimizations.

> in line with the work of others. You can argue that it's good enough-
> it is, for most cases- but taking a 20% performance hit rules it out
> of a lot of systems work, and the C-Go gap in many cases is much
> larger than that.

I don't work anything that involves and absolute need for performance.
I could probably accept penalty several times that of C for higher
level functionality; but, sometimes the penalty for Python is just
too much.  Many of my programs are very quick lived such that even
loading an interpeter or VM can eclipse the actual runtime.  Given less
developmental effort required, I also find that I have more time to look
for ways to optimize Go.  There are many things (such as using alternate
data structures rather then the build in slices and immutable strings)
that can be used to accelerate Go when time permits and I suspect many
more will be found as the language matures.

> Go is also not an ideal language for enterprise development. It
> provides no compatibility or support guarantees; in fact, the website
> describes it as 'an experiment' and recommends it for 'adventurous

There is no doubt that it is a young project and there are a number of
things that will need to be improved to be effective for some branches
of programming; but, that isn't a language restriction.  Frankly, I am
rather impressed by the sheer number of third party packages that have
already become available.  No go isn't going to replace some of the other
top mainstream langauges today; but, I can easily see it starting to see
some market penetration 5 years from now.

> users'. There are no independent experts in case something goes wrong,
> and if it goes belly up a year from now you will have a one year old
> piece of legacy infrastructure on your hands. Maybe you don't think
> that this will be the case; in any event, I would not want to try
> convincing a CFO of that.

If I was trying to convince a CFO, I would ask if he really thought Google
was likely to simply drop the time and effort that Google has already
placed into the infrastructure.  Furthermore, few dying languages already
have not one, but two, open source compilers available for use.  

> As you point out, Go is also not a good language for operating systems
> work. The lack of a widely accepted GUI toolkit weakens your argument
> about application development. The lack of third party tools and
> dependence on foreign language bindings weakens your single-language
> argument. Etc, etc, etc.

I don't really do GUI programming so you are probably right about the
need for GUI toolkits.  I do know that there is a GTK binding available as
well as direct X11 support.

Database bindings are another weak link outside of the more common
open source databases.  In both cases, Go readily capable of C library
functions as a stop-gap until a native wrapper is available.  Yes it will
be nice once community has filled in the gaps; but, I am rather impressed
at what is already available in less then a years time.  There are a few
libraries you may have missed here:

http://go-lang.cat-v.org/pure-go-libs
http://go-lang.cat-v.org/library-bindings

Every language I know of has some binds that are simply wrappers to
C libraries.  There isn't much gain in reinventing the wheel to create
a 100% non-C implementation for every library available and there are
strong disadvantages such as trail time from the C release until it is
reimplented natively.  What are the advantages of recreating the termcap
parser just to be able to position a few characters on the screen?

I will point out that Go's libraries are miles ahead of the standard C
library and other minimalistic standard libraries.  Many things are
possible with even the most basic functionalities.  I don't use Python
bindings when using GNUplot simply because its easier to access GNUplot
directly.

Finally, and most importantly, nothing about any third party tools and
libraries has any bearing on the generality language itself.

>> Support for concurrency is really icing on the cake.  I find it rather
>> supprising that so many modern languages do not already support full
>> concurrency constructs.
>
> Go's most-lauded feature is its goroutines. I suspect that if this
> isn't a big deal for you, you aren't its primary use case.

Actually, I would consider Go's implicit interfaces to be a far more
important innovation.  The goroutines are nice but not ground breaking.
They are quite recognizable to other SCP concurrancy derivatives.

>> http://www.infoq.com/interviews/johnson-armstrong-oop
>>
>> Listen to the third point.  Object orientation is quite possible even
>> without inheritance.  Not all programming languages support the same set
>> of OOP features.  Not all classless OOP programming languages support
>> inheritance.  The basic definition of object oriented programming is
>> programing with self contained objects which contain their own data and
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> the procedures necessary to manipulate that data.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> So C is OOP. Let's agree to disagree on that.

C fails to be an object oriented language because it fails to provide
the syntactic sugar necessary to bind functions to the data that they
manipulate and because it doesn't provide the isolation necessary for
encapsilation of objects.

>>>> 2. Go has a similar mechanism to exceptions, defer/panic/recover.  It does
>>>>        downplay
>>>
>>> Defer, panic, and recover only allow you to build a recovery stack.
>>> That's like saying that try/except isn't needed anymore because you
>>> have the with statement. Do you think you could get through a rewrite
>>> of Django without ripping out some hair over that?
>>
>> I don't know what you are referencing about Django as I don't work on or
>> with the project; but, if one wanted exceptions with similar sematics to
>> Python's, it could easily be built around Go's defer/panic/recover.  There
>> are actually packages availble that recreate exceptions as they are used in
>> Ruby and other languages.  The only think defer/panic/recover lacks is an
>> exception class containing more more detailed information about what
>> actually went wrong.
>
> You could also build it in C, yet C is exceptionless and is commonly
> faulted for that fact.

defer/panic/recover is conceptually a world closer to exceptions then is
setjmp/longjmp.  It really isn't any further different then the variantions
in exceptions between different languages.