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

[geremy condra]

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:
>>> I wouldn't say Go is narrowly targeted.  It's a systems language that can
>>> compete in the same domain with scripting languages.  It is true that most
>>> languages have long incubation periods; but, corporate support can change
>>> that quite a bit.  C#, being backed by Microsoft, managed to go mainstream
>>> pretty quickly.
>>
>> This seems... shall we say, overly optimistic. I've seen no evidence
>> at all that Go is even trying to compete with scripting languages, and
>> I don't know of anyone who would actually use it where a shell script
>> might do. AFAICS, it is an unabashedly concurrency-centric systems
>
> I don't write Python where shell scripts will do either.  I have rewritten
> several simple Python scripts in Go.  I will not be leaving Python
> completely; but, Go will likely replace Python for most of my large scale
> programming needs.

I'm happy that you've found a language you like. I don't happen to
share your enthusiasm for it, and I think my arguments are better
grounded. I suspect you feel the same about yours, and I'm happy to
leave it at that.

>> might do. AFAICS, it is an unabashedly concurrency-centric systems
>> language for people who are willing to sacrifice some speed and
>> control for legible code. That's not an impossibly narrow niche (and
>> it certainly has deep pockets) but it *is* narrow compared to a
>> general purpose language like Java or Python.
>
> You are writing Go into far too narrow of a niche then it actually is.  In
> fact, whatever language you are commenting on doesn't sound like Go at all.
>
> 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.

I'm a C, Python, and Haskell developer. Everything I've done could be
done in C. I would probably not be happy if I had to, though.

Some people get very attached to one language and use it for
everything. I'd rather use the right tool for the job.

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

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

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.

Taking these things out you are left with very little that Go is
compellingly good at. I certainly don't see it displacing Java or C,
which you claim is equivalent.

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

>>>> Python's very widely used for scripting and related tasks, and has a
>>>> pretty big user base in academia and the sciences.
>>>
>>> Python has been widely used by people like us that happen to like the
>>> language and found ways to use it in our workplaces; but, most of the
>>> time it is an unofficial use that the company.  You still don't see many
>>> companies doing large scale internal development using Python and you
>>> definately don't see any doing external developement using a language
>>> that gives the customers full access to the source code.
>>
>> Right, I mean, it's not like the company that wrote Go would *ever*
>> stoop to using Python ;)
>
> I have never said that there are not companies doing developement in
> Python and certainly not for web programming; but, a handful of companies
> that have adopted Python doesn't make it mainstream.  Good luck finding
> many Python jobs in my area.  Java, C#, Visual Basic, PHP, *COBOL*,
> RPG-IV, and, to a lesser extent, C++ jobs are available in abundance.
> The few Python jobs that are available are for web based programming.

Let me know when you get a job writing Go.

>>> 1. Go has an object model.  What it lacks is an object hierarchy where all
>>>        object are decended from a single root "object" since it does
>>>        not support object inheritance as it is used in most languages.
>>>        In Go we simply adapt an object to meet the needs of the newer
>>>        object by adding whatever new functionality is needed.
>>
>> Go has structs. Its structs are not objects, principally because they
>> can't do real inheritance. You can do similar things ('structural
>> inheritance') to C structs, and nobody argues that C is OO.
>
> 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.

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

>>> The current
>>> interest in functional programming stems merely because some announced
>>> that it would be *the* way to utilize multicore computers.  Having looked
>>> into the space somewhat, there is more hype then substantiation for
>>> purely functional concepts.  What the hype did do was return attention
>>> to SCP style concurrency using actors and MPI and I think that will be
>>> the direction taken for concurrent programming into the future.
>>
>> I'm not an expert in concurrency and can't evaluate the claims many
>> are making in that space. I know that I still find writing highly
>> parallel programs easier in C and Python than I do in Haskell, but I
>> seldom wind up thinking that concurrency was the hard part of the
>> problem I was solving.
>
> I don't know much about Haskells concurrent programming constructs.  If you
> have found concurrent programming easy, then your problems probably don't
> involve many shared resources.

Not an enormous number, no.

Geremy Condra