On Mon, Jan 17, 2011 at 4:02 PM, Tim Harig <user...@ilthio.net> wrote:
>> 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.
The question isn't whether you will use it; right or wrong, it seems
certain that you will. The question is whether it will see significant
uptake, and this is a big barrier for many.
> 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.
I'm sorry, but you're wrong on this. Java's performance can be
excellent, particularly when it comes to mathematical functions. I
recall reading a pretty smug paper a few years ago describing how they
managed to beat C on a number of numerical benchmarks.
> 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.
No idea, never used it.
>> 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.
Then don't argue about performance, it makes you look like a hack just
eager to shill for your language.
> 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.
This is inconsistent with your argument about PyPy. See my earlier comment.
>> 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.
It will nevertheless preclude its use in most enterprise software
development. That's most systems software.
> 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.
I suppose that for some small value of market penetration ('mom uses
it!') you're right. I don't see any evidence of major movement at this
moment though.
>> 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.
Hahahaha. You mean like wave?
> Furthermore, few dying languages already
> have not one, but two, open source compilers available for use.
Two compilers by the same people. Not two active projects. Big difference.
> 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:
Sounds like a two-language solution, ie, the thing you criticized Python for.
> 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.
And miles behind Python and other large standard libraries.
> Finally, and most importantly, nothing about any third party tools and
> libraries has any bearing on the generality language itself.
Except for its uptake.
>>> 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.
I think if we did a poll of people who had heard of Go, they would
generally say that concurrency was its big selling point. I suspect
that its (ugly, IMHO) interface mechanism would not appear on the
list.
> 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.
No, it doesn't. I can add functions to structures using function
pointers, and languages like Python only provide encapsulation by
convention. There's no reason why that couldn't be true for C as well.
Ergo, if Go is OO, then C is OO.
> 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.
We can agree to disagree here. As I say, I find it much closer to
things like the with statement than true exceptions, and general
internet rabble seems to agree.
As a question, given how hot you are for this language I have to
wonder how much of it you've actually written. Could you provide a
link? Google code search turned up nada.
Geremy Condra
--
http://mail.python.org/mailman/listinfo/python-list
