Go has caught up Rust in the number of github stars

1,283 views
Skip to first unread message

Pablo Rozas Larraondo

unread,
May 3, 2016, 11:48:01 AM5/3/16
to golang-nuts
Hello Gophers,

I've been checking how the Go repo has been gaining on Rust in the star count, since it was moved to Github. I see that as of today both projects have 16,522 stars, and if this trend continues Go will take the lead.

It's not really important but I just wanted to share this with you :-)

Cheers,
Pablo 

RogerV

unread,
May 4, 2016, 2:28:22 PM5/4/16
to golang-nuts
Ah, but there's a new kid in town - Pony.

Pony is a ground up actor programming language and like Rust can compile time prove a program to be data race free, dead locks (no such thing as locks), and no memory violations (buffer overruns, no null pointer errors as has no null concept).

It is GC memory managed but has no stop the world pauses, writer barriers, or any of the other problems introduced by typical GC.

John McKown

unread,
May 4, 2016, 2:37:04 PM5/4/16
to golan...@googlegroups.com
​<sigh>. I'm just too old to keep up with the language du jour. I'm just going to go back to playing "pong".​
 


--
The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Maranatha! <><
John McKown

Rob Pike

unread,
May 4, 2016, 2:55:13 PM5/4/16
to John McKown, golan...@googlegroups.com
"It is GC memory managed but has no stop the world pauses, write barriers, or any of the other problems introduced by typical GC." That sounds too good to be true. There must be something else to compensate, such as mutexed reference counts. Where are details of the algorithm recorded?

-rob


--
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/d/optout.

Ian Lance Taylor

unread,
May 4, 2016, 3:06:11 PM5/4/16
to Rob Pike, John McKown, golan...@googlegroups.com
On Wed, May 4, 2016 at 7:54 AM, Rob Pike <r...@golang.org> wrote:
> "It is GC memory managed but has no stop the world pauses, write barriers,
> or any of the other problems introduced by typical GC." That sounds too good
> to be true. There must be something else to compensate, such as mutexed
> reference counts. Where are details of the algorithm recorded?

It seems to use rnon-mutexed eference counting:
http://tutorial.ponylang.org/appendices/garbage-collection.html ;
http://www.ponylang.org/papers/OGC.pdf .

I think a key point in making this work is that the language ensures
that all pointer aliasing is clearly documented at the language level.
Also actor methods are atomic--that's where they put the mutexes.

I have not found a clear description of how they collect cycles.

Ian

Jesper Louis Andersen

unread,
May 4, 2016, 3:08:33 PM5/4/16
to Rob Pike, John McKown, golan...@googlegroups.com

On Wed, May 4, 2016 at 4:54 PM, Rob Pike <r...@golang.org> wrote:
"It is GC memory managed but has no stop the world pauses, write barriers, or any of the other problems introduced by typical GC." That sounds too good to be true. There must be something else to compensate, such as mutexed reference counts. Where are details of the algorithm recorded?

The ultrashort version: The GC is reference counting per actor. In the Pony message-passing model, ownership is handled by having "ownership" modes on data, so if you want to give data away to another process while also having access to it yourself, you must make a copy, etc. In turn, you can obtain rather efficient relamation of data since an actor usually only reaches for a small set of the heap and hence GC is often bounded in size.

--
J.

Zippoxer

unread,
May 4, 2016, 4:09:09 PM5/4/16
to golang-nuts
The search is over. I'm dropping Go and picking up Pony immediately.

Roberto Zanotto

unread,
May 4, 2016, 5:36:38 PM5/4/16
to golang-nuts
Maybe "immediately" is a bit too soon? :D

Apparently, they threw a lot of "cool features" into the language without reasoning about orthogonality
and without caring to write the language specification.
Also, they guarantee deadlock-freedom by using channels with unbounded buffers...

roger peppe

unread,
May 4, 2016, 6:06:26 PM5/4/16
to Roberto Zanotto, golang-nuts

From my brief look, the main loss in Pony is that you can't block. That is, you can't call a function that  does any network IO, reads a file, talks to a network server, etc without using some kind of callback to acquire the results.

In this respect it's quite like other current languages where blocking is considered anathema, such as Javascript.

Personally I very much like being able to hide intricate external interactions behind simple function calls, but of course this does allow deadlock.

ISTM that Pony is another "bi-coloured" language ( http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ ). I started off quite interested but this rather turned me off it.

It's also a very big language and there's no spec.

--

Zippoxer

unread,
May 5, 2016, 1:00:24 AM5/5/16
to golang-nuts
> Also, they guarantee deadlock-freedom by using channels with unbounded buffers..
Hehe, so deadlocks are replaced by out of memory crashes then :P

Honestly, I like the idea they are describing. But I don't like that they force the actor model. I also think they're introducing too much complexity. For example, just look at http://tutorial.ponylang.org/capabilities/combining-capabilities.html

andrey mirtchovski

unread,
May 5, 2016, 1:02:44 AM5/5/16
to Zippoxer, golang-nuts
Rust had three kinds of pointers, Pony has three kinds of something else:

https://bluishcoder.co.nz/2016/05/04/bang-hat-and-arrow-in-pony.html

Good things come in threes.

Dan Kortschak

unread,
May 5, 2016, 1:08:12 AM5/5/16
to Zippoxer, golang-nuts
On Wed, 2016-05-04 at 18:00 -0700, Zippoxer wrote:
> For example, just look at
> http://tutorial.ponylang.org/capabilities/combining-capabilities.html

I stopped at "When a field of an object is read, its reference
capability depends both on the reference capability of the field and the
reference capability of the origin".

When you need a reference table to determine behaviours, the game is
lost.

Zippoxer

unread,
May 5, 2016, 1:14:46 AM5/5/16
to golang-nuts, zipp...@gmail.com
Exactly. Their reference table is a significant cognitive overhead, and a primitive of the language, not some feature you can safely ignore.

RogerV

unread,
May 5, 2016, 2:10:00 PM5/5/16
to golang-nuts
The designers of the language (Imperial College London - if memory serves me) say it takes a couple of weeks for students working in Pony to make the mental shift of working with capabilities. Sounds similar to the initial cognitive hurdle of Rust where need to learn ownership, borrowing, scope annotations.

Even Modern C++11(14,17) requires a new cognitive approach due to need to learn move semantics and all the implications of that. I'd say is about a similar two hurdle there too if one is working in code during the learning process.

Rust, Pony, and future C++ (2020?) are (or are heading toward) compile time correct languages.

Torsten Bronger

unread,
May 5, 2016, 3:46:47 PM5/5/16
to golan...@googlegroups.com
Hallöchen!

RogerV writes:

> The designers of the language (Imperial College London - if memory
> serves me) say it takes a couple of weeks for students working in
> Pony to make the mental shift of working with capabilities. Sounds
> similar to the initial cognitive hurdle of Rust where need to
> learn ownership, borrowing, scope annotations.

The question is, what do they mean with "working with capabilities"?
If it is the same as with Rust, it means "being able to transform
compiler error messages into code changes without getting
frustrated".

I compared Rust with Go in January without knowing anything of the
two, and with no initial preference. I implemented the same program
in both languages, trying being ideomatic. I doubt that you are
more *productive* with Rust (and Pony, probably). And this is what
counts. You detect errors just in another phase of development. If
Rust's approach was sound, Python (my primary language) should be
impossible to work with. However, this is far away from practical
evidence.

I think Rust and Pony live the computer scientist's dream of the
Correct Program(tm). Instead, a programming language should be easy
for the human mind rather than just possible. (Well, as easy as
programming can be in the first place.) Worse is better.
Productivity counts.

> [...]
>
> Rust, Pony, and future C++ (2020?) are (or are heading toward)
> compile time correct languages.

I don't object to a correct program per se -- but it should come
with zero additional burden for the programmer. Maybe I have to
wait for such compilers until there is a Commander Data existing.
But that's okay with me.

Tschö,
Torsten.

--
Torsten Bronger Jabber ID: torsten...@jabber.rwth-aachen.de

Matt Harden

unread,
May 5, 2016, 4:02:26 PM5/5/16
to golan...@googlegroups.com
I think that languages and their error messages should guide the programmer away from poor decisions and toward good ones. I don't think we currently use nearly enough psychological (sociological?) expertise in the design of programming languages. I don't want a PL designed by a psychiatrist; that would be a disaster. I do want the design to be informed by what we know about how people think. I think Go is currently the best language out there from that point of view.

Torsten Bronger

unread,
May 5, 2016, 4:26:32 PM5/5/16
to golan...@googlegroups.com
Hallöchen!

Matt Harden writes:

> [...] I do want the design to be informed by what we know about
> how people think. I think Go is currently the best language out
> there from that point of view.

FWIW, I think that the scripting languages are friendlier to the
human mind. However, the compromises a PL must make are more
complex. Efficiency also plays a role, and this is where the
statically typed languages shine.

But I agree with you that Rust makes an unfortunate compromise. It
is certainly a good PL and a great scientific effort but this is
also true for Lisp, Haskell, D, and many others that weren't really
successful.

Matt Harden

unread,
May 5, 2016, 5:47:22 PM5/5/16
to golan...@googlegroups.com
I've never actually understood why people find dynamic typing simpler. For me it's easier to think in terms of types, but maybe that's from years of study. I actually find Haskell's type system easier to use than Go's, because it allows me to express my thoughts more directly.

mcguir...@gmail.com

unread,
May 5, 2016, 7:44:50 PM5/5/16
to golang-nuts, john.arch...@gmail.com


On Wednesday, May 4, 2016 at 9:55:13 AM UTC-5, Rob 'Commander' Pike wrote:
"It is GC memory managed but has no stop the world pauses, write barriers, or any of the other problems introduced by typical GC." That sounds too good to be true. There must be something else to compensate, such as mutexed reference counts. Where are details of the algorithm recorded?

-rob

Someone else has pointed to the paper describing Pony's GC. The only catch I've seen in practice is that, if you write serial code, i.e. in the Main actor's create, the garbage collector will never run until the program terminates.

When they say "actor based", they kind of mean it.

Torsten Bronger

unread,
May 5, 2016, 8:06:37 PM5/5/16
to golan...@googlegroups.com
Hallöchen!

Matt Harden writes:

> I've never actually understood why people find dynamic typing
> simpler. For me it's easier to think in terms of types, but maybe
> that's from years of study.

I also think in types when using Python. But in Python, "type" is
not a memory layout but an interface. In a way, it is like Go with
Go interfaces all over the place, which also include fields rather
than only methods.

Justin Israel

unread,
May 5, 2016, 8:14:51 PM5/5/16
to golan...@googlegroups.com
I remember looking over the Pony Language tutorial a month or two ago. I was really into the concepts...until I got to the 6 types of reference capabilities. Then I lost interest. It was, like others have said, too much cognitive load.

Justin

mura

unread,
May 6, 2016, 2:49:39 AM5/6/16
to golang-nuts
I have been thinking about that why there are still so many bugs, including segfaults, being reported for the projects using compile time correct languages, provided that the projects are sufficiently large-scale.

The answer I can come up with so far is:
1. They inevitably introduce extra complexities to the *whole system* to gain the helps from the languages/compilers.
2. The total of complexities is not reduced, but just being pushed away and hid underneath, in the dependent libraries or the compilers.

And that reminds me of the so-called bureaucratic management — maybe we can call it bureaucratic programming.
In a bureaucratic organization, the guys in upper layers don't solve problems, but either assign problems or create new problems to their subordinates.
And then for the ease of life of the top managers when their jobs get heavy and messy, they would add yet another middle managerial layer rather than streamlining the tasks and/or improving the procedures to eliminate the bottleneck of the system. The complexity in the view point of the top guy would then seemingly get reduced, however we all know the total productivity/complexity of the whole organization isn't improved at all.

Many lessons have also taught us that the most robust systems are mostly those with the simplest bottom layer, and having the messy things pushed to upper layers, rather than the opposite.
But in a bureaucratic (mainstream?) style of programming, we usually presume that the tops must be dumb and can only have them do the dumbest things, leaving the hardcore stuff to the dependencies/subordinates.

Not that the "compile time correct" languages necessarily advocate or encourage bureaucratic programming, but that seems to be the natural thing to happen when complexities are hid and accumulated instead of eliminated.

Daniël de Kok

unread,
May 6, 2016, 3:44:08 PM5/6/16
to Torsten Bronger, golan...@googlegroups.com
On 05 May 2016, at 17:45, Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
> I compared Rust with Go in January without knowing anything of the
> two, and with no initial preference. I implemented the same program
> in both languages, trying being ideomatic. I doubt that you are
> more *productive* with Rust (and Pony, probably).

I don’t think it differs much. In the beginning, ‘satisfying’ [1] the borrows checker does slow down development, but this is largely compensated by stronger abstractions that make your life easier (the try! macro, iterator mapping/filtering, better type inference, etc.).

Recently, I wrote a small library and some utilities in Rust and I would say that it took approximately as much time as it would in Go. If anything, it’s currently the small ecosystem and (quite literally) compile times that slow you down.

Kind regards,
Daniël


[1] This is the wrong word, because you are actually removing incorrect memory use, races, etc.

Jesper Louis Andersen

unread,
May 6, 2016, 3:57:12 PM5/6/16
to Roberto Zanotto, golang-nuts

On Wed, May 4, 2016 at 7:36 PM, Roberto Zanotto <roby...@gmail.com> wrote:
Also, they guarantee deadlock-freedom by using channels with unbounded buffers...

Channels with unbounded buffers does not guarantee deadlock-freedom by itself. Erlang uses, essentially, unbounded buffers, but if A calls B expecting a reply, and at the same time, B calls A expecting a reply, you have a deadlock. You can avoid deadlocks, but unbounded buffers are not a sufficient condition, and I believe there are other features in Pony which are used to achieve the property of deadlock-freedom.

It isn't a necessary condition as well. Haskells STM implementation gives you software-transactional-memory in a way which is deadlock free. But even though you may react to that with joy, it still does not guard you against livelocks, which arguably can be worse: the program appears to work until it stops giving service by exhaustion.

Interestingly, unbounded buffers is not a problem in practice, as long as you heed to a certain system design which coincidentally is very popular in Erlang systems: you flow-control in the boundary of the application, but run no flow control inside the application. Done correctly, your inner parts are hard to deadlock by accident since all blocking is skewed and only happening on the receiver side. And the flow-control in the boundary makes sure you don't accidentally overload the system with too much work. In essence, you use a single bounded buffer, or an equivalent construction, to protect a large number of unbounded buffers from overload and memory problems.


--
J.

Torsten Bronger

unread,
May 6, 2016, 6:26:40 PM5/6/16
to golan...@googlegroups.com
Hallöchen!

Daniël de Kok writes:

> On 05 May 2016, at 17:45, Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>> I compared Rust with Go in January without knowing anything of
>> the two, and with no initial preference. I implemented the same
>> program in both languages, trying being ideomatic. I doubt that
>> you are more *productive* with Rust (and Pony, probably).
>
> I don’t think it differs much.

I don't think so too, however, if a new language doesn't differ much
from established ones productivity-wise, there is no compelling
reason to switch.

(BTW, I mean with productivity the time it takes to create a product
that meets the predefined requirements, including the
quality/stability. So I take into account that the Rust compiler
finds bugs the C++ user has to find with other methods.)

Daniël de Kok

unread,
May 7, 2016, 5:37:44 AM5/7/16
to Torsten Bronger, golan...@googlegroups.com
On 06 May 2016, at 20:21, Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
> I don't think so too, however, if a new language doesn't differ much
> from established ones productivity-wise, there is no compelling
> reason to switch.

As you were hinting at in the remainder of your message — if you need a language with manual memory management and/or RAII, Rust will be a much saner choice than C++. Also, in many cases, Rust has better correctness guarantees than Go (compile-time data race detection, variable (im)mutability, etc.).

At any rate, Go and Rust are only partially overlapping in their application domains, so there is plenty of space for both ;).

Kind regards,
Daniël de Kok

Henry

unread,
May 7, 2016, 6:23:56 AM5/7/16
to golang-nuts, bro...@physik.rwth-aachen.de, m...@danieldk.eu
Since people started breaking down long program into procedures, we are already making a tradeoff between performance and productivity. The key is to find the right balance between the two. It is easy to measure raw performance, but measuring productivity isn't that straightforward. Productivity isn't measured only in terms of the number of lines written, or the number of hours invested, or the number of bugs found. You must also take into account scalability, how well the language copes as a communication medium in a larger team and how well the language deals with changes and design entropy. It is productivity in a larger context and in a real world setting. I believe this is the bigger picture that Go is trying to solve.

Many other programming languages tend to focus on the micro and lose sight of the bigger picture. When you are working with many people whose background, skills and experience are varied and they may come and go throughout the lifetime of the software, is it still possible to keep everyone on the same page and still write high-performing software? This is performance in a larger context.

Torsten Bronger

unread,
May 7, 2016, 7:46:44 AM5/7/16
to golan...@googlegroups.com
Hallöchen!

Daniël de Kok writes:

> [...]
>
> As you were hinting at in the remainder of your message — if you
> need a language with manual memory management and/or RAII, Rust
> will be a much saner choice than C++.

If we had a fresh start, maybe. I express only my gut feeling
anyway. It will be interesting to see how real-world projects
suffer or benefit from this different compromise.

> Also, in many cases, Rust has better correctness guarantees than
> Go (compile-time data race detection, variable (im)mutability,
> etc.).

You didn't do that, but *very* often I read about compile-time
correctness of Rust and Pony. This is highly misguiding. The
Python compiler finds some errors, the C++ compiler more, Rust even
more than that -- but there are still plently of possibilities for
bugs to hide left.

Roberto Zanotto

unread,
May 7, 2016, 3:43:19 PM5/7/16
to golang-nuts, roby...@gmail.com
Thanks for the clarification :)
Reply all
Reply to author
Forward
0 new messages