Can golang has the chance to be as fast as C or C++?

[davy zhang]

Golang is a compiled static typed language with GC.

C/C++ is a compiled static typed language without GC.

So I am just sometimes wondering the main issue is GC performance ?

[Ian Lance Taylor]

There is no general answer to that question. For some specific
programs Go is already faster than C/C++. For most programs C/C++ is
faster. In some cases GC time is indeed an issue, in others it is
not.

Ian

[davy zhang]

Thanks for the points. I really love golang, and wish it could replace c someday as system programming language

[Kevin Gillette]

Go is already within a reasonable speed margin of C, and in the standard toolchain c and assembly files are first-class languages (they're auto-compiled just like go files), so when highly time-constrained algorithms or low level access is needed, you can do so easily. Go already solves a lot of systems-programming problems better than C/C++, and in many of those problems, the speed difference between Go and traditional languages is either irrelevant, or far outweighed by the benefits of Go.

The garbage collectors are not guaranteed to be slower than malloc-based manual memory management. As Go's GC matures, the overhead will diminish.

[steve wang]

Some operations in Go are definitely faster than in C++, such as calculating the length of a string:)

[Jan Mercl]

On Mon, Apr 15, 2013 at 6:20 AM, davy zhang <davy...@gmail.com> wrote:
> Golang is a compiled static typed language with GC.

Golang? Where can I learn about that language?

-j

[andrey mirtchovski]

> Golang? Where can I learn about that language?

http://golanglang.com, naturally.

[chris dollin]

On 15 April 2013 08:39, Jan Mercl <0xj...@gmail.com> wrote:

Golang? Where can I learn about that language?

www.golang.org seems like a good start.

Chris

--
Chris "things can have more than one name" Dollin

[Dave Cheney]

> http://golanglang.com, naturally.

Looks fine to me.

[Bienlein]

 

So I am just sometimes wondering the main issue is GC performance ?

There is something you can do when the GC is running mad like reusing already allocated memory. See the comment by Ethan Burns where he comments on the tuned version of the Havlak benchmark being enormously faster using this approach: https://groups.google.com/forum/?hl=de&fromgroups=#!topic/golang-nuts/jTzFLinwI7U

[Bienlein]

Some operations in Go are definitely faster than in C++, such as calculating the length of a string:)

Some operations like array shuffling as in this sudoku benchmark are even slower than in Java using Go 1.1: http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/

The garbage collectors are not guaranteed to be slower than malloc-based manual memory management. As Go's GC matures, the overhead will diminish.

The GC needs to search for unreferenced pointers, which is unused data it can remove from memory when it seems appropriate to the GC. Searching for unreferenced pointers is a process that consumes CPU cycles which is not the case when memory is freed manually. So GCs will always impose some overhead no matter what maturity level a GC has reached. Modern GCs have stop-the-world times below 10 ms. So this is good enough for server-side systems programming which is what Google wants to use Go for.

[Kevin Gillette]

On Monday, April 15, 2013 2:41:08 AM UTC-6, Bienlein wrote:

The GC needs to search for unreferenced pointers, which is unused data it can remove from memory when it seems appropriate to the GC. Searching for unreferenced pointers is a process that consumes CPU cycles which is not the case when memory is freed manually. So GCs will always impose some overhead no matter what maturity level a GC has reached. Modern GCs have stop-the-world times below 10 ms. So this is good enough for server-side systems programming which is what Google wants to use Go for.

There are a remarkable number of ways in which this scan can be reduced or sometimes eliminated at runtime, not to mention what static analysis can potentially do at compile time; dynamic allocations that do not escape from a given call-graph can be either stack allocated or at least can be deterministically freed on stack pop, and those pointers do not need to be scanned. Systems with compacting GCs (not that Go is particularly compatible with that tech) can use runtime analysis to place related information into the same cache lines, offsetting or potentially even exceeding initial cost in overhead. Further, if GC software systems overtake C++ and friends in marketshare, we may see a resurgance in hardware supported GC, which would make overhead negligible.

[John Nagle]

With some work, Go could probably beat C on number-crunching.
The remaining problem is a lack of real multidimensional arrays.
Arrays of arrays are slower than dense arrays, and the subscript
checking is much slower, because each row potentially has a
different length. With dense arrays, all the loop optimizations
that FORTRAN compilers have been doing for decades become possible.

(A surprising amount of number-crunching is still done in
FORTRAN on supercomputers or machines with a lot of cores. While
Go wasn't originally intended for that market, it may be the
best language around adaptable to it. It's not there yet, though.)

John Nagle

[Jan Mercl]

I'm not sure but it seems to me like you're using 'array' where 'slice' is the real  meaning. B/c Go _has_ "true" multidimensional arrays.

-j

[Kevin Gillette]

On Monday, April 15, 2013 11:32:45 AM UTC-6, John Nagle wrote:

    With some work, Go could probably beat C on number-crunching.

That depends. C leaves the behavior of many operations undefined in special circumstances (such as integer overflow), while Go fully specifies the behavior, and Go's behavior in many or all of these cases may not be what is fastest for a given platform to compute. Certainly that makes Go 'safer' in general, though except in cases where the compiler could, for example, prove that overflow could not occur (and thus disable overflow traps), or when a C compiler is instructed to use defined behavior equivalent to Go's, then the C code will likely be faster.

Theoretically, there may be some offsetting cases where the well-structured nature of Go code could allow a compiler to make safe optimization assumptions that couldn't be made with C, but I'm not aware of any actual examples of this (not that I'm an expert in this area).

[Harley Laue]

Keep in mind that below is my opinion and may not reflect the reality of
situation. Also, below is all very anecdotal and thus should be taken
with a grain of salt.

I like some perspective when looking at performance. C & C++ have been
around for roughly 40 & 30 years respectively. Go has been around
(publicly) for about 4 years.

Obviously, language age isn't /really/ a factor. Take, for example,
JavaScript, PHP, Ruby, and Java, all came out about around the same
time, and all have vastly different performance. A general observation
(and over simplification) that I'd make would be that the more popular a
language becomes, the more time goes into optimizing said language. For
instance, Java became quite popular for enterprise applications quite
early on and performance was a major focus for the 1.1 release. Ruby,
arguably, didn't really start to become popular until Rails came along
nearly ten years later, at which point performance became a major focus.
It seems to me the situation was similar with both PHP & JavaScript as well.

Now, I'm by no means implying that Go produces unoptimized code. It
actually does a very good job in certain use cases, but there's always
room for improvement. This is why one of the goals of Go 1.1 was to
improve performance over the 1.0 release, and it's done a pretty good
job in a lot of cases. The fact that Go is quite young (relatively
speaking) and is already performing quite well (in fact, better than
most of the languages mentioned above[1][2][3]) should be a pretty good
indication that the performance gap will continue to shrink into
irrelevance (or may already be there for your particular usage. ;)

Lastly, on a very personal note, I can't emphasize enough how awesome I
think the entire Go team is for all the work they've put into the
language, runtime, compiler, tools, et al. so far.

[1]
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=yarv
*
[2]
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=v8
*
[3]
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=php
*
* The standard disclaimer(s) about benchmarks obviously applies here as
well.

[Paul Kline]

Hi,

I did a quick benchmark on the lastest dev (1.1beta2 msi build) on windows 7 x64.   [ http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=nbody ] 

The visual C++ x64 Release Mode vs GO 1.1 with a 50,000,000 run 3x.

Visual C++ => 6.3396554  

Go => 8.1501993

Its very very close, at least on the first benchmark.   At this level, the difference is very little in my mind.

[John Nagle]

On 4/15/2013 10:55 AM, Kevin Gillette wrote:
> Theoretically, there may be some offsetting cases where the well-structured
> nature of Go code could allow a compiler to make safe optimization
> assumptions that couldn't be made with C, but I'm not aware of any actual
> examples of this (not that I'm an expert in this area).

A major example is iterating over a dense multidimensional array
or slice. Most matrix operations (especially multiply and invert)
involve iterating over more than one dimension of a multidimensional
array. So it's important to be able to cheaply traverse a
multidimensional array along any dimension.

For an array of arrays (or slices, in Go), each access to a
new row involves an extra indirection, an access of the row length,
and a subscript check against the row length. Alternatively,
there are packages which represent multidimensional arrays as
single-dimension arrays with access functions. Neither approach
is optimal.

For a dense 2D array, the program can advance by
row by adding one "stride" (the difference between the starting
address of each row) to an index. FORTRAN compilers have been
doing this since Backus's compiler on the IBM 704 in the 1950s.
(Ref: http://polaris.cs.uiuc.edu/publications/c1070.pdf)
This is cheaper than the indirection, access, and add
required for an array of arrays (or slice of slices).

Go has subscript checking. But that doesn't mean that
subscripts have to be checked on every operation. Often,
subscript checks can be hoisted out of loops. That's been
done in the past for Pascal compilers, and about 90% of
subscript checks can be optimized out. C doesn't check
subscript at all, which is paid for in crashes and security holes.

With multidimensional slices, Go could potentially do
all the FORTRAN optimizations, plus check subscripts, and
go faster than C on number-crunching.

John Nagle

[Jan Mercl]

On Mon, Apr 15, 2013 at 8:28 PM, John Nagle <na...@animats.com> wrote:
> For an array of arrays (or slices, in Go), each access to a
> new row involves an extra indirection

Please stop posting such false "facts".

-j

[chris dollin]

I'm not so sure it's false.

If A is of type [][]T, computing the address of A[i][j] involves

two indirections -- one in A[i] to get a reference to the column,

the other, given that column, to calculate A[i][j]. The address

of the (WLOG) first element of the column A[i] is essentially

unrelated to that of the column A[i+1].

With a "two-dimensional slice", you have one indirection to

get an A[i, j] element, but the address of A[i+1, j] can then

be computed without further indirections.

Hence the slice-of-slices does an extra indirection WRT a

2d-slice.

That's how I read it, anyways.

--
Chris "allusive" Dollin

[Jan Mercl]

John said "For an array of arrays (or slices, in Go), each access to a
new row involves an extra indirection".


What you're depicting holds for arrays of slices (or a slice of
slices). It's not true for array of arrays.

-j

[Job van der Zwan]

On Monday, 15 April 2013 21:33:27 UTC+2, Jan Mercl wrote:

John said "For an array of arrays (or slices, in Go), each access to a
new row involves an extra indirection".


What you're depicting holds for arrays of slices (or a slice of
slices). It's not true for array of arrays.

-j

So? John said he was referring to slices in Go. Or are you saying that the arrays in Fortran are like the arrays in Go, and not like the slices in Go?

[David Leimbach]

On Sunday, April 14, 2013 11:22:02 PM UTC-7, steve wang wrote:

Some operations in Go are definitely faster than in C++, such as calculating the length of a string:)

Seriously?  Why would this be faster in Go?  Doesn't the class basic_string<CharT> have a member with the length it can just return?

I'm genuinely curious why this would be faster in Go.

Dave

[steve wang]

To be clear, by "a string in C++" I meant char*.

[Jan Mercl]

http://play.golang.org/p/HV8zrt_3Rg

-j

[Bienlein]

[1]
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=yarv
*
[2]
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=v8
*
[3]
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=php 

It's interesting that Go is by a multitude slower in the regex-dna benchmark compared to almost all other languages. Admittedly, I'm too lazy to have a closer look into what this regex-dna is doing. Evnetually it is a GC intensive one. Hope the guys at benchmarksgame.alioth.debian.org will update their measurments for Go 1.1. in not much time. Am really curious to see how the results are then.

Beying that comparing Go with PHP and Ruby really doesn't make sense. These language are dynamically typed and interpreted anyway. Makes more sense to compare Go with C/C++ and Java.

-- Bienlein

[Job van der Zwan]

Yeah, I see that that is an array of arrays in Go. But that wasn't my point - I read John's wording as Fortran being capable of using strides instead of indirection to arrays with size determined during runtime, not compile time like Go, which would make Fortran arrays the equivalent of slices. Now I don't know Fortran, so I can't say if that is the case or not.

[Volker Dobler]

I do not think that these arguments and comparisons are helpful.

Fortran arrays are alias free in function calls so Fortran compilers may

generate more effective code than e.g. C or Go.

It is really comparing apples  to oranges and neither apples nor

oranges will change just because one is superior one way or

the other.

V.

[Jan Mercl]

On Tue, Apr 16, 2013 at 9:40 AM, Bienlein <jet...@web.de> wrote:
>
>> [1]
>>
>> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=yarv
>> *
>> [2]
>>
>> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=v8
>> *
>> [3]
>>
>> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=php
>
>
> It's interesting that Go is by a multitude slower in the regex-dna benchmark
> compared to almost all other languages. Admittedly, I'm too lazy to have a
> closer look into what this regex-dna is doing. Evnetually it is a GC
> intensive one. Hope the guys at benchmarksgame.alioth.debian.org will update
> their measurments for Go 1.1. in not much time. Am really curious to see how
> the results are then.

This particular benchmark is already an evergreen discussed at many
other sites. It "shows" Go regular expression engine is very slow,
specifically wrt 'pcre' which most of the other languages at shootout
use. Actually, Go regular expression engines is of many orders of
magnitude _faster_ then 'pcre':
http://swtch.com/~rsc/regexp/regexp1.html

You can find a certain (small) part of the quadratic function which is
"better" than a linear function. Basing a benchmark on that atypical
part is a fraud. It's an example how rubbish the numbers from made-up
benchmarks are or could be. Intention or ignorance, who knows?

-j

[Starfish]

I don't think it is really honest to suggest Go will be as fast as C++. 

After all, C++ is a lower level language and a language hardware vendors develop compilers and optimized libraries for. In addition there is a lack of generics, which make it hard to develop something like Blitz++ for Go.

A similar question would be: will C++ ever be as fast as machine code, and the answer is obvious.

[Péter Szilágyi]

Just my 2c:

  Theoretically, ideal low level code will always be at least as fast as ideal high level code. Practically, high level code will always be simpler, and thus the compiler has much more room to optimize. Of course it won't be able to reach the low level theoretical limits, but what code does? Unless you're intimately familiar with a low level language and are willing to put in significant effort, a higher level one with some nice optimizations can potentially beat your low level implementation.

  So my take on the topic is: use whatever gives you enough performance for the job, but is the easiest of them all (i.e. right tool for the right job). Go strikes a very nice balance between performance and abstraction level. Besides, if you're worried about the gc, you can make sure you don't allocate/deallocate frequently, but instead cache, use blocks of stuff, etc.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bienlein]

I don't think it is really honest to suggest Go will be as fast as C++.

I don't think so, either. Go has to offer a considerable performance improvement over Java to make a case for itself. It doesn't have to be as fast as C/C++. In many Java IDEs compilation is incremental and you only need to create a time consuming build for some integration test. Using JRebel you can even sort of develop in the debugger. So the build times don't matter in the same way as in C/C++.

The Go book by Balbaert mentions that some people at Google moved from Python to Go. So Go is merely used as some scripting language that compiles to the metal and runs very fast. For the server farms admin programs at Google this seems to make sense.

[Péter Szilágyi]

So Go is merely used as some scripting language that compiles to the metal and runs very fast.

Ouch, please do take that back: https://code.google.com/p/go-wiki/wiki/SuccessStories

[Bienlein]

So Go is merely used as some scripting language that compiles to the metal and runs very fast.

Ouch, please do take that back: https://code.google.com/p/go-wiki/wiki/SuccessStories

This is one way it is used. Go as a scripting language besides other use cases has something to it. Same development speed/productivity, but much better performance than Python, Ruby, Lua, etc. It can't replace those scripting languages in every way, but for me it's my primary scripting language now.

[Jan Mercl]

What the fsck are you guys talking about? Go is _no_ scripting
language. It doesn't even remotely resemble a(ny) scripting language
wrt its design, tool chain, ...

-j

[Ethan Burns]

On Tuesday, April 16, 2013 6:50:11 AM UTC-4, Bienlein wrote:

I don't think it is really honest to suggest Go will be as fast as C++.

I don't think so, either. Go has to offer a considerable performance improvement over Java to make a case for itself.

I disagree; Go does not need to offer a performance improvement over Java to make a case for itself.  Go already offers many other non-performance improvements (simplicity, tool, etc.).  Better performance is nice, but personally I would prefer Go even if it was 2x slower than Java.

Best,

Ethan

[Bienlein]

What the fsck are you guys talking about? Go is _no_ scripting
language. It doesn't even remotely resemble a(ny) scripting language
wrt its design, tool chain, ...

-j

You are not getting it. You can use it in a similar way. That's what the guys at Google are doing who moved from Python to Go.

[Archos]

Go can replace easily to whatever dynamic language getting a better performance, and it also can replace to languages based in VMs outperforming in memory although it is not fast like anyone of them -e.g. Java-, at least by now.

Respect to C: It's impossible to be "as fast as C" in all cases while remaining safe
http://pcwalton.blogspot.de/2010/12/c-design-goals-in-context-of-rust.html

And respect to C++, there will cases where the GC will not be a problem, i.e. in tools for the command line.

In Go, when it's time to collect garbage, the entire system is stopped while the GC runs. This approach is fine if your program is going to run once, write output, and then quit (like in command line tools). But in long-running applications, like desktop, mobile, or server programs, this one results in frozen user interfaces and slow response times.

[Jan Mercl]

On Tue, Apr 16, 2013 at 1:22 PM, Bienlein <jet...@web.de> wrote:
>> What the fsck are you guys talking about? Go is _no_ scripting
>> language. It doesn't even remotely resemble a(ny) scripting language
>> wrt its design, tool chain, ...
>

> You are not getting it. You can use it in a similar way. That's what the
> guys at Google are doing who moved from Python to Go.

I disagree. IMHO mixing of the terms 'Go' and 'scripting language' in
this thread is a total BS. Maybe I don't get it. Maybe I'm not the one
who doesn't get it.

-j

[Jan Mercl]

On Tue, Apr 16, 2013 at 1:37 PM, Archos <raul...@sent.com> wrote:
> In Go, when it's time to collect garbage, the entire system is stopped while
> the GC runs. This approach is fine if your program is going to run once,
> write output, and then quit (like in command line tools). But in
> long-running applications, like desktop, mobile, or server programs, this
> one results in frozen user interfaces and slow response times.

Please tell this to Java people and then report back how it went ;-)

-j

[Gerard]

Exactly! If speed is the only thing that counts, go and write assembler.

Op dinsdag 16 april 2013 12:23:46 UTC+2 schreef Starfish het volgende:

[Archos]

I don't expect that Java people accept this fact, although the development and usage of Java applications in desktop environments is minimal. Almost nobody wants an app. that takes near 1 minute in startup, e.g. Eclipse.

[Bienlein]

I disagree; Go does not need to offer a performance improvement over Java to make a case for itself.  Go already offers many other non-performance improvements (simplicity, tool, etc.).  Better performance is nice, but personally I would prefer Go even if it was 2x slower than Java.

I see what you mean. Problem is that in this plastic world in the end you need a business case ... Channels in Java are already there and the class that does the same is called BlockingQueue. Spawn as many goroutines as you like? You can do this in Java as well using HawtDispatch. Sockets? There is Mina, Jetty, Raw NIO. It's all there and really nicely done.

For a business case Go has to throw in some bone in addition. That's the point I was making. But I understand your point that a language that can show how to achieve lots of things of the same level of complexity with much simpler means has it's place in the CS world by itself.

-- Bienlein

[SteveD]

On Tuesday, April 16, 2013 1:47:14 PM UTC+2, Jan Mercl wrote:

I disagree. IMHO mixing of the terms 'Go' and 'scripting language' in
this thread is a total BS.

I'd use the question 'what is a program and what is a script?' to illuminate the difference. A script is an informal program that automates something and isn't really intended to be extended.  Go can do that just as well as Python, with the benefit of providing a completely self-contained implementation.

It's one of those false dichotomies (like interpreter/compiler) which aren't really that useful anymore.  I did a C++ interpreter in my youth, and so I could script in C++.  That was just a function of practically-zero build times, really, and it would not be impossible for a C++ _compiler_ to get that fast, _if_ it could drop its elderly C tool chain philosophy.  (It turns out that C++ makes a poor scripting language, because it's fussy and over-verbose - not because it usually builds like a dog)

[Aram Hăvărneanu]

> Channels in Java are already there and the class
> that does the same is called BlockingQueue. Spawn as many goroutines as you
> like? You can do this in Java as well using HawtDispatch.

Concurrency is almost useless without select/alt, and select requires
language (not library) support.

--
Aram Hăvărneanu

[Jan Mercl]

On Tue, Apr 16, 2013 at 2:35 PM, SteveD <steve.j...@gmail.com> wrote:
> On Tuesday, April 16, 2013 1:47:14 PM UTC+2, Jan Mercl wrote:
>>
>> I disagree. IMHO mixing of the terms 'Go' and 'scripting language' in
>> this thread is a total BS.
>
>
> I'd use the question 'what is a program and what is a script?' to illuminate
> the difference. A script is an informal program that automates something and
> isn't really intended to be extended. Go can do that just as well as
> Python, with the benefit of providing a completely self-contained
> implementation.

My ad hoc definition.

If a program:

- is swallowed by a compiler and later a linker spits out machine code
to be directly executed by the CPU
- is statically type checked AOT

then such program is not written in a scripting language.

-j

PS: It surprises me again and again. Go is so close to C in almost
every aspect (except the troubled ones). Anyone claiming that C is a
scripting language (even though CINT exists) is seldom taken seriously
or is probably joking. Yet so many people talk about scripting in Go
with ease. Yes, I don't get it ;-)

[Bienlein]

Concurrency is almost useless without select/alt, and select requires
language (not library) support. 

I don't understand what you mean with select/alt. Could you explain? HawtDispatch distributes a large number of queues (aka channels) over a small number of threads just in the same way as Go distributes a large number of channels on a small number of processes. Apple has done that before with Grand Central Dispatch based on C. HawtDispatch has just brought the approach from Apple to Java and Go has done something similar.

-- Bienlein

[Bienlein]

- is swallowed by a compiler and later a linker spits out machine code
to be directly executed by the CPU
- is statically type checked AOT

then such program is not written in a scripting language.

You work in the same way as if you were working with a scripting language ("no types" aka type inference, build times almost zero, you have closures), productivity is the same. And, eventually, you are writing a program that otherwiese typically would have been written with a scripting language.

[Matt Kane's Brain]

select/alt doesn't refer to the way goroutines are mapped to OS threads. select is the mechanism by which a goroutine can wait on multiple potentially blocking channel operations and only one will go forward.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
matt kane's brain
twitter: the_real_mkb / nynexrepublic
http://hydrogenproject.com

[Ethan Burns]

The "additional bone" is that Go was designed well for engineering software: http://talks.golang.org/2012/splash.article.  All of the other features you mention are great, but Go isn't designed to emphasize some particular tool like go routines, or channels, or interfaces; it's about all of them: selecting the right tools that fit together well, are very simple, and are completely sufficient.

Ethan

[Bienlein]

Am Dienstag, 16. April 2013 14:53:26 UTC+2 schrieb Bienlein:

- is swallowed by a compiler and later a linker spits out machine code
to be directly executed by the CPU
- is statically type checked AOT

then such program is not written in a scripting language.

"Go's interfaces let you use duck typing like you would in a purely dynamic language like Python." The person who wrote this is a guy named Russ Cox, see http://research.swtch.com/interfaces

[Jan Mercl]

On Tue, Apr 16, 2013 at 3:34 PM, Bienlein <jet...@web.de> wrote:
> "Go's interfaces let you use duck typing like you would in a purely dynamic
> language like Python." The person who wrote this is a guy named Russ Cox,
> see http://research.swtch.com/interfaces

Go is not a scripting language. Additionally, rsc's quote doesn't
support the opposite in any way. Go is as a scripting language as C
is. Yes, you can implement interfaces in C too, e.g. GObject. And no,
fast compilation doesn't mean anyone is using Go "as a scripting
language". Or yes, some people do it like that. They are wrong.

Let's agree our disagreement is permanent ;-)

-j

PS: I would even disagree with Russ about the duck typing note. IMO
duck typing would mean that this would be valid iGo: `a := 42; b :=
"314"; c := a + b`. But it is not valid. Go, not even in this version:
`var a, b, c interface{}; a = 42; b = "314"; c = a + b`. Actually
interfaces in Go have always perfectly known static type and the
dynamic type must conform to the static type (have matching method
set) at any given moment. No automatic type conversion which allow
"duck typed" operations on objects inside interfaces exists.

[Bienlein]

I would even disagree with Russ about the duck typing note.

I would agree here about disagreeing with Russ ;-). The statement has some potential of being led into the wrong direction.

-- Bienlein

[Bienlein]

Let's agree our disagreement is permanent ;-)

@Jan Mercl:

Would you agree if it were put this way: Google’s Go: „A modern C with the Productivity of a Scripting Language“ ?

-- Bienlein

[Jan Mercl]

On Tue, Apr 16, 2013 at 4:14 PM, Bienlein <jet...@web.de> wrote:
> Would you agree if it were put this way: Google’s Go: „A modern C with the
> Productivity of a Scripting Language“ ?

Productivity of coding in most scripting languages is, by my
experiences, terrible low compared to productivity of coding in Go.

I'm serious. The static type safety per se means one never has to hunt
down where-in-the-world this number get into the
should-be-always-string variable. It's a major productivity boost - to
not to have to debug silly mistakes which the _compiler_ catches for
me.

Really, productivity in almost any scripting language is IMO much
worse. And the uncertainty about might-surface-at-any-time-errors is a
big source of stress. Which harms productivity as well. That's why I
feel likening Go to a scripting language as almost an offense. Go is
way better than a scripting language, including productivity ;-)

-j

[Harley Laue]

On 04/16/13 02:57, Jan Mercl wrote:
> On Tue, Apr 16, 2013 at 9:40 AM, Bienlein <jet...@web.de> wrote:
>>> [1]
>>>
>>> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=yarv
>>> *
>>> [2]
>>>
>>> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=v8
>>> *
>>> [3]
>>>
>>> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=php
>>
>> It's interesting that Go is by a multitude slower in the regex-dna benchmark
>> compared to almost all other languages. Admittedly, I'm too lazy to have a
>> closer look into what this regex-dna is doing. Evnetually it is a GC
>> intensive one. Hope the guys at benchmarksgame.alioth.debian.org will update
>> their measurments for Go 1.1. in not much time. Am really curious to see how
>> the results are then.
> This particular benchmark is already an evergreen discussed at many
> other sites. It "shows" Go regular expression engine is very slow,
> specifically wrt 'pcre' which most of the other languages at shootout
> use. Actually, Go regular expression engines is of many orders of
> magnitude _faster_ then 'pcre':
> http://swtch.com/~rsc/regexp/regexp1.html
>
> You can find a certain (small) part of the quadratic function which is
> "better" than a linear function. Basing a benchmark on that atypical
> part is a fraud. It's an example how rubbish the numbers from made-up
> benchmarks are or could be. Intention or ignorance, who knows?
That's why I had:
> * The standard disclaimer(s) about benchmarks obviously applies here
> as well.
which Bienlein removed from the reply. It's still good to point out
things like http://swtch.com/~rsc/regexp/regexp1.html (and I forgot to
do that myself.)

[Kevin Gillette]

On Tuesday, April 16, 2013 7:51:09 AM UTC-6, Jan Mercl wrote:

PS: I would even disagree with Russ about the duck typing note. IMO
duck typing would mean that this would be valid iGo: `a := 42; b :=
"314"; c := a + b`.

Duck-typing is strictly about behaviors, not characteristics ("if it quacks like a duck..."). Your example is about characteristics ("if has feathers of duckish appearance, it must be a duck"). This is the same debate about using interfaces vs structs (behavior vs data). Many will distinguish duck typing from structural programming such that duck typing is a looser name-based binding, but those are still both quite different from the hypothetical model you describe, which simply looks like the odd combination of static weak typing.

Bienlein

It's interesting that Go is by a multitude slower in the regex-dna benchmark compared to almost all other languages. Admittedly, I'm too lazy to have a closer look into what this regex-dna is doing. Evnetually it is a GC intensive one. Hope the guys at benchmarksgame.alioth.debian.org will update their measurments for Go 1.1. in not much time. Am really curious to see how the results are then.

See Jan's note of course. Still, this is not much of an issue in Go, and most of us really wouldn't care if we came last in this benchmark for the next decade (and that may well be the case). Many languages, particularly interpreted languages, use regex to do heavy lifting for trivial tasks, since interpreting an equivalent loop written in that language's own code would be much slower; in Go, native custom matching/searching code is always much faster (if you know what you're doing), and yet is often quite simple to write code for.  Because of this, the primary purpose of regexp in Go is efficient runtime-dynamic pattern matching (such as accepting input regexps from a UI) -- ironically, that's the role in which pcre-based implementations, such as those used by nearly every other language, are entirely unsafe to use.  In short, regexp doesn't get built into most Go programs, even complex ones, and a low benchmark here doesn't imply that real-world programs will be slow. otoh, if typical interpreted languages scored low on this mark, it'd have serious implications about the speed of many common processing tasks, since unlike Go, there'd be no reasonably fast way to solve those problems in those languages natively if they couldn't rely on regex.

[Jeff Mitchell]

Kevin Gillette wrote:
> See Jan's note of course. Still, this is not much of an issue in Go, and
> most of us really wouldn't care if we came last in this benchmark for
> the next decade (and that may well be the case). Many languages,
> particularly interpreted languages, use regex to do heavy lifting for
> trivial tasks, since interpreting an equivalent loop written in that
> language's own code would be much slower

^ Question 1

; in Go, native custom
> matching/searching code is always much faster (if you know what you're
> doing), and yet is often quite simple to write code for. Because of
> this, the primary purpose of regexp in Go is efficient runtime-dynamic
> pattern matching (such as accepting input regexps from a UI) --
> ironically, that's the role in which pcre-based implementations, such as
> those used by nearly every other language, are entirely unsafe to use.
> In short, regexp doesn't get built into most Go programs, even complex
> ones, and a low benchmark here doesn't imply that real-world programs
> will be slow. otoh, if typical interpreted languages scored low on this
> mark, it'd have serious implications about the speed of many common
> processing tasks, since unlike Go, there'd be no reasonably fast way to
> solve those problems in those languages natively if they couldn't rely
> on regex.

I'm intrigued by this comment -- can you provide:

1) Any good references about how regex libraries are used by most
interpreted language ("Question 1" above) -- I've never heard of that,
but don't know much about the internal design of most languages

2) Information on why it is unsafe to run regexes on input strings in
other languages (unless it's just because of potential DoS attacks by
e.g. exhausting available memory with carefully constructed or very
large strings that affect specific regexes if they're doing things like
greedy matching) -- and why such a thing is not unsafe in Go

Not trying to catch you at anything, I honestly don't know the answers
to those and I'm very curious.

Thanks,
Jeff

[andrey mirtchovski]

> 1) Any good references about how regex libraries are used by most interpreted language

> 2) Information on why it is unsafe to run regexes on input strings in other languages

once more, with feeling: http://swtch.com/~rsc/regexp/regexp1.html

[Kevin Gillette]

On Tuesday, April 16, 2013 11:28:35 AM UTC-6, Jeff Mitchell wrote:

I've never heard of that, but don't know much about the internal design of most languages 

I'll elaborate: many programs in some languages, particularly interpreted languages... I'm not claiming that the runtime or interpreter for any popular language leverages regexs -- just, to varying degree, the majority of information-processing programs that are written in those languages.

On Tuesday, April 16, 2013 11:28:35 AM UTC-6, Jeff Mitchell wrote:

2) Information on why it is unsafe to run regexes on input strings in

other languages (unless it's just because of potential DoS attacks...

DoS vurnerability unless special provisions are taken to avoid that, such as any of the following: 1) checking the input regex for sanity [hard]), 2) putting an upper limit on the time/resources that can be used by the regex operation (but most implementations don't expose hooks to allow that, and not all of them are pre-emptible, so if you try throw an exception into that thread, it may have to wait until the end of the universe before it'll switch back to the vm and process the exception), 3) use an alternative regex implementation (many languages have an re2 binding, for example).

 

Since likely most programmers don't know that pcre and similar implementations take exponential worst-case time (and most of those don't know what that means, in the programming domains where regexes are most frequently used), they are unlikely to protect themselves against this problem.

[Gerard]

BTW, my comment was not meant offensive.

Op dinsdag 16 april 2013 14:02:05 UTC+2 schreef Gerard het volgende:

[Isaac Gouy]

On Tuesday, April 16, 2013 12:40:43 AM UTC-7, Bienlein wrote:

Hope the guys at benchmarksgame.alioth.debian.org will update their measurments for Go 1.1. in not much time. Am really curious to see how the results are then.

Go 1.1 needs to be released before the measurements can be updated :-)

The x64 one core and x86 quad-core measurements were made with go1.1beta1.

[Sugu Sougoumarane]

As a many of you know, vitess has been handling the entirety of YouTube's MySQL traffic for nearly two years now. But there were some things we could not do yet. These are things you would notice only if you plan to serve the kind of volume we do.

However, every time we hit such limits, we asked ourselves if it was due to the language design or the current (young) implementation of the compiler/runtime. The answer has almost always been the latter. As we hit those limits, we just filed bugs/feature requests, and the go team has been fixing them.

I just started running some benchmarks using the 1.1 beta, and the initial numbers are looking pretty impressive. From what I hear, gccgo should produce even more impressive results once it inherits the new runtime.

[Isaac Gouy]

On Tuesday, April 16, 2013 12:57:14 AM UTC-7, Jan Mercl wrote:

-snip-

This particular benchmark is already an evergreen discussed at many
other sites. It "shows" Go regular expression engine is very slow,
specifically wrt 'pcre' which most of the other languages at shootout
use.

It "shows" one Go program is slow wrt a bunch of other programs.

It's an example how rubbish the numbers from made-up
benchmarks are or could be. Intention or ignorance, who knows?

It's an example of how rubbish conclusions based on measurement of programs that solve just one task are or could be.
 
http://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.php

[Isaac Gouy]

On Tuesday, April 16, 2013 8:33:04 AM UTC-7, Harley Laue wrote:

-snip-

That's why I had:
> * The standard disclaimer(s) about benchmarks obviously applies here
> as well.
which Bienlein removed from the reply. It's still good to point out
things like http://swtch.com/~rsc/regexp/regexp1.html (and I forgot to
do that  myself.)

 The disclaimers shown on the benchmarks game website obviously apply ;-)

[Jeff Mitchell]

Kevin Gillette wrote:
> I'll elaborate: many programs in some languages, particularly
> interpreted languages... I'm not claiming that the runtime or
> interpreter for any popular language leverages regexs -- just, to
> varying degree, the majority of information-processing programs that are
> written in those languages.

Ah, okay. I thought you meant the former -- that internally these
languages are using regexes as part of their runtime/interpreter because
it's faster (perhaps due to using a C library) than interpreting some
types of code directly. But you meant the users of these languages in
their programs.

> 2) Information on why it is unsafe to run regexes on input strings in
> other languages (unless it's just because of potential DoS attacks...
>
>
> DoS vurnerability unless special provisions are taken to avoid that,
> such as any of the following: 1) checking the input regex for sanity

I missed this the first time. If I understand correctly, you are talking
about the input being a regex itself, not the input being a string that
is sent to a regex that is hardcoded into the code.

Thanks for the clarifications.

--Jeff

[John Nagle]

On 4/16/2013 12:43 AM, Job van der Zwan wrote:
> On Tuesday, 16 April 2013 09:32:52 UTC+2, Jan Mercl wrote:
>
>> On Mon, Apr 15, 2013 at 10:42 PM, Job van der Zwan
>> <j.l.van...@gmail.com <javascript:>> wrote:
>>> On Monday, 15 April 2013 21:33:27 UTC+2, Jan Mercl wrote:
>>>>
>>>> John said "For an array of arrays (or slices, in Go), each access to a
>>>> new row involves an extra indirection".
>>>>
>>>>
>>>> What you're depicting holds for arrays of slices (or a slice of
>>>> slices). It's not true for array of arrays.
>>>>
>>>> -j
>>>
>>>
>>> So? John said he was referring to slices in Go. Or are you saying that
>> the
>>> arrays in Fortran are like the arrays in Go, and not like the slices in
>> Go?
>>
>> http://play.golang.org/p/HV8zrt_3Rg
>>
>> -j
>>
>
> Yeah, I see that that is an array of arrays in Go. But that wasn't my point
> - I read John's wording as *Fortran* being capable of using strides instead
> of indirection to arrays with size determined during* runtime*, not *compile
> time* like Go, which would make Fortran arrays the equivalent of slices.

Right. You can create a 2D array in Go, but you can't take
it anywhere. Here, try to pass that array to another function that
accepts a variable sized 2D slice. That won't work, of course.

http://play.golang.org/p/aG32kVz5Lv

You can do this, but the second subscript has to be fixed, like C.

http://play.golang.org/p/AP4q9C-qnT

Go has roughly the same array semantics as C, with most of the
same limitations. Slices don't work like arrays. For matrix work,
this is painful. A useful math library needs ways to pass variable
sized multidimensional arrays around. Preferably efficiently.

John Nagle

[Kevin Gillette]

On Tuesday, April 16, 2013 1:44:47 PM UTC-6, Jeff Mitchell wrote:

Ah, okay. I thought you meant the former -- that internally these
languages are using regexes as part of their runtime/interpreter because
it's faster (perhaps due to using a C library) than interpreting some

types of code directly...

Forget a library written in C -- contemporary interpreted languages tend to have their interpreters and much of their stdlibs wholly written in C (and no, interpreting imperative code, if possible to do through some extended regexp engine, would likely be orders of magnitude slower than the most naive direct approach). Many of these languages also have Java interpreters.

 

I missed this the first time. If I understand correctly, you are talking
about the input being a regex itself, not the input being a string that
is sent to a regex that is hardcoded into the code.

The expression is what is unsafe in pcre-like engines, not the input -- if an expression is hard-coded or derived from a trusted source, then it's either always safe or always unsafe (depending on whether the expression has a large runtime exponent), and it shouldn't be considered the user's fault for making it take years longer just for passing in a few dozen bytes of extra non-expression input. On the other hand, if the input is the expression itself, then pcre-like engines are never safe, and Thompson-style engines (those that actually handle regular expressions, and do so efficiently, such as in Go's regexp stdlib package) are always safe, and processing time will always be linear to the size of the input.

In general, you should never accept a regular expression from an untrusted user unless you are sure the regexp implementation has linear-time guarantees (though if it's a program running on someone's own computer for their own use, they're allowed to blow themselves up).

[Kevin Gillette]

How often do you really need to translate between fixed-size matrices and the variable-sized/dimensioned variety? In most of the application domains I've worked in that involve matrices, there are usually only a few fixed dimensions and sizes used, and by keeping them as fixed-size types, the compiler can potentially produce code far more efficient than the runtime efficiency gains you're asking for.

[John Nagle]

On 4/16/2013 1:36 PM, Kevin Gillette wrote:
> How often do you really need to translate between fixed-size matrices and
> the variable-sized/dimensioned variety? In most of the application domains
> I've worked in that involve matrices, there are usually only a few fixed
> dimensions and sizes used, and by keeping them as fixed-size types, the
> compiler can potentially produce code far more efficient than the runtime
> efficiency gains you're asking for.

For simple graphics work, it's mostly fixed-size matrices. For
most other numerical work, matrices come in different sizes,
and libraries for them are written to accept variable sized
arrays.

I used to write "physics engines" for game-type simulation,
which involves integrating nonlinear differential equations.
The functions for that all have to work on variable sized arrays.
The same is true for machine learning, for which the most
popular languages seem to be Matlab and Python, neither of
which handles parallelism well.

Go to "nr.com" and look at some common libraries for
number-crunching. Those are the things that have to go fast.

John Nagle

[Rémy Oudompheng]

On 2013/4/16 Starfish <ahn...@rocketmail.com> wrote:
> I don't think it is really honest to suggest Go will be as fast as C++.
>
> After all, C++ is a lower level language and a language hardware vendors
> develop compilers and optimized libraries for. In addition there is a lack
> of generics, which make it hard to develop something like Blitz++ for Go.
>
> A similar question would be: will C++ ever be as fast as machine code, and
> the answer is obvious.

Not everyone writes code that will burn days of CPU over a 1000-server
cluster. Actually, most people write useful programs that will consume
a tiny amount of computing power compared to the time spent writing
it.

For these people, being able to write bug-free, concurrent code in
minutes instead of days is definitely a performance improvement.

Rémy.

[Dan Kortschak]

I believe 50,000 angels can dance on the head of a pin.

[bugpowder]

On Tuesday, April 16, 2013 2:47:14 PM UTC+3, Jan Mercl wrote:

On Tue, Apr 16, 2013 at 1:22 PM, Bienlein <jet...@web.de> wrote:
>> What the fsck are you guys talking about? Go is _no_ scripting
>> language. It doesn't even remotely resemble a(ny) scripting language
>> wrt its design, tool chain, ...
>
> You are not getting it. You can use it in a similar way. That's what the
> guys at Google are doing who moved from Python to Go.

I disagree. IMHO mixing of the terms 'Go' and 'scripting language' in
this thread is a total BS. Maybe I don't get it. Maybe I'm not the one
who doesn't get it.

No, I'm pretty sure you are the one who "doesn't get it".

A language such as Go doesn't have to be a "scripting language" per se to be compared to one or used like one.

A lot of people use Go on domains where they used a scripting language like Python before.

Rob Pike himself alluded to this, saying: " Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.".

And Go's introductory notes said: "Go attempts to combine the ***development speed of working in a dynamic language like Python*** with the performance and safety of a compiled language like C or C++."

It is often said that due to the fast compile times, type inference, and overall simpleness, Go feels much like a dynamic language.

That it's compiled and has different internal workings doesn't matter much for this kind of comparison.

And I don't much appreciate your language either. I mean rude comments like:

-- "Please stop posting such false "facts"", (instead of pointing why you think he is wrong -- as if he's doing it on purpose to mislead people), 

-- "it is total BS", 

-- "what the fsck are you guys talking about"

etc. 

[Rob Pike]

Surely there are more productive things to be doing, or even arguing about.

-rob

[Sébastien Paolacci]

Hello Bienlein,

That benchmark was definitely not limited by the GC, but by the overall non-optimizing code generation. Just profile and/or disassemble it by yourself and you'll see the point.

Compiling with gccgo (4.8), keeping very same solver implementation, provides with results equivalent to the C ones. Those numbers were just not integrated by the author "just" because gccgo is currently broken on Mac OS X (where the benchs were to run on).

Bottom-line: the compiler technology does also matter. `gc' (the "main" compiler) is damn fast, but the (slower) gcc has solide and mature optimisation capabilities. Depending on what you're benchmarking, it can make a lot of differences.

Cheers,

Sebastien

On Mon, Apr 15, 2013 at 10:41 AM, Bienlein <jet...@web.de> wrote:

Some operations in Go are definitely faster than in C++, such as calculating the length of a string:)

Some operations like array shuffling as in this sudoku benchmark are even slower than in Java using Go 1.1: http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/

The garbage collectors are not guaranteed to be slower than malloc-based manual memory management. As Go's GC matures, the overhead will diminish.

The GC needs to search for unreferenced pointers, which is unused data it can remove from memory when it seems appropriate to the GC. Searching for unreferenced pointers is a process that consumes CPU cycles which is not the case when memory is freed manually. So GCs will always impose some overhead no matter what maturity level a GC has reached. Modern GCs have stop-the-world times below 10 ms. So this is good enough for server-side systems programming which is what Google wants to use Go for.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeff Mitchell]

Kevin Gillette wrote:
> On Tuesday, April 16, 2013 1:44:47 PM UTC-6, Jeff Mitchell wrote:
>
> Ah, okay. I thought you meant the former -- that internally these
> languages are using regexes as part of their runtime/interpreter
> because
> it's faster (perhaps due to using a C library) than interpreting some
> types of code directly...
>
>
> Forget a library written in C -- contemporary interpreted languages tend
> to have their interpreters and much of their stdlibs wholly written in C

> (and no, interpreting /imperative/ code, if possible to do through some

> extended regexp engine, would likely be orders of magnitude slower than
> the most naive direct approach). Many of these languages also have Java
> interpreters.

Of course. You can see why I was confused when i thought you were
indicating that these languages (in their runtimes) delegate to regexes
under the hood for various operations. :-)

--Jeff

[Lars Seipel]

On Tuesday 16 April 2013 14:39:35 Aram Hăvărneanu wrote:
> Concurrency is almost useless without select/alt, and select requires
> language (not library) support.

I once used some Java library (JCSP) that implemented alt/select on channels.
It was a bit clunky to use but it did work. You basically called a function
and switched on its return value. The function (given an array of channels)
would block until a channel gets ready. Then you do the read from the channel
in the case clause.

In accordance with customary practice in the Java community you even get to
choose between a hundred subtly different types of channels out of (at least)
two hundred different channel factories.

http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Lars

[Bienlein]

Are you implying that Go allows you to write "bug-free, concurrent code"? :)

I like your irony ;-).. Blocking channels can easily result in the system or components of it to lock up in case some expected message required by the coordination logic does not arrive. So you have to work with timeouts to prevent the system from freezing. If the system runs too often into timeouts it becomes irresponsive and performance will plummet. Process synchronisation remains an inherently difficult problem area with no silver bullet.

The work done by the people at Akka is interested in that regard, f.ex. the new kinds of futures they have introduced. Unhappily, it is all geared towards OTP as in Erlang from which i was cloned and there is nothing that has been done to make exception handling in an asynchronous environment easier to handle.
 

I once used some Java library (JCSP) that implemented alt/select on channels.
It was a bit clunky to use but it did work. You basically called a function
and switched on its return value. The function (given an array of channels)
would block until a channel gets ready. Then you do the read from the channel
in the case clause.

(...)

http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Thanks a lot for the link :-). I spent some time thinking about how to do it, but didn't know it is a well-known field in IT.

-- Bienlein

[Bienlein]

Am Donnerstag, 18. April 2013 07:18:30 UTC+2 schrieb Lars Seipel:

On Tuesday 16 April 2013 14:39:35 Aram Hăvărneanu wrote:
> Concurrency is almost useless without select/alt, and select requires
> language (not library) support.

I once used some Java library (JCSP) that implemented alt/select on channels.
It was a bit clunky to use but it did work. You basically called a function
and switched on its return value. The function (given an array of channels)
would block until a channel gets ready. Then you do the read from the channel
in the case clause. 

(...)

http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Lars

@Lars: How did you figure out to do this? God no is the documentation bad ....

Thanks, Bienlein

[⚛]

On Monday, April 15, 2013 6:20:51 AM UTC+2, davy zhang wrote:

Golang is a compiled static typed language with GC.

C/C++ is a compiled static typed language without GC.

So I am just sometimes wondering the main issue is GC performance ?

There are multiple factors. GC is just one of the factors that affect performance.

Some additional factors that have an effect on program performance:

- Go is safer than C/C++. Representation of information in C has fewer bits than Go representation of the same information.

- Go compiler isn't tightly integrated with source code editing.

- Goroutine scheduling.

Maybe it is possible for most Go programs to run at C speeds by means of a different Go compiler technology. Unfortunately, nobody knows how to do this yet.

[Michael Harooni]

On Thu, Apr 18, 2013 at 1:54 AM, Bienlein <jet...@web.de> wrote:

I like your irony ;-).. Blocking channels can easily result in the system or components of it to lock up in case some expected message required by the coordination logic does not arrive. So you have to work with timeouts to prevent the system from freezing. 

Not to mention shared mutable state, with no explicit way to enforce immutability without compromise. You either pass a copy of a structure and incur copy overhead, or you pass a pointer to it, and lose immutability.