Go failed to solve significant problems (according to ex-googler)

[Archos]

A Google's ex-employee [says][1]:

"Internally-developed languages like Go and Dart failed to solve any
significant problems."

Does anybody of the Go team could say in what kind of problem has
failled? (Go)


[1]: http://www.spencertipping.com/posts/2012.0530.why-i-left-google.html

[Brad Fitzpatrick]

He also said something like his team only used Java.

So, yeah, Go didn't convert his team's big codebase over to Go overnight. That's probably good.

For new code, Go is great.

[Andrew Gerrand]

I'm don't see how someone who was at Google for only 6 months would be in a position to judge the success or failure of anything. 

Andrew 

[Michael Jones]

It was plain to me, when you read his note, that he wants to see the mental model of Scala and Clojure, functional programming, and post OO, post C/C++, post Java. He would certainly not find the Go team tilting at windmills in this particular way. For the most part, Go is a wise, clean, insightful, fresh thinking approach to the greatest-hits subset of the well understood. This is why it is likely to grow up to be huge, global, and successful. But (despite the parallelism and type system) it is not the tool for those who want to challenge the fundamental conception of programming, the way prolog, or ML, or Backus' FP, Clojure, Scala, or Ken Iverson's J does. I think this is wisdom to upgrade the actual practice and improve the lives of millions of developers, but it may well not be spicy enough for someone who's tied their thoughts to all new and all different.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Thomas Bushnell, BSG]

He worked for six months, on a team which only used Java, in a company with tens of thousands of engineers.

I think his conclusions may relation to his own experience, but not the company as a whole.

[Paddy Foran]

From the notes at the top, I think it's pretty clear he's only trying to speak to his own experience and why Google wasn't a good match for him. Extrapolating on the statements from that post seems to be a pretty shaky way to try and draw conclusions.

That said, this seems like a pretty easy dispute to solve: does Go solve a problem for you? If yes, you should use it. If no, you're probably fine using whatever you're currently writing in. Why is this hard?

[David Anderson]

On Sun, Jun 3, 2012 at 3:41 PM, Brad Fitzpatrick <brad...@golang.org> wrote:

He also said something like his team only used Java.

So, yeah, Go didn't convert his team's big codebase over to Go overnight. That's probably good.

And to contrast with that guy's experience, I work on a team with a C++/Java codebase, and we've given serious consideration to rewriting most of our code in Go, because Go's concurrency model would be a true breath of fresh air. To us, Go is solving a very real, very significant problem. We're pushing the languages we currently use to breaking point, where Go would take it all in its stride. The concurrency model in particular is a life-saver for us, but the more subtle benefits of interfaces and a blazingly fast compiler would also be wonderful.

Realistically, it's highly likely that a lot of our new code will be in Go, but we'll keep existing code. Existing code has the benefit of years of bug fixes and battle-hardening. Throwing that out is a bit too big of a step for the time being.

- Dave 

[David Anderson]

On Mon, Jun 4, 2012 at 12:45 AM, David Anderson <da...@natulte.net> wrote:

On Sun, Jun 3, 2012 at 3:41 PM, Brad Fitzpatrick <brad...@golang.org> wrote:

He also said something like his team only used Java.

So, yeah, Go didn't convert his team's big codebase over to Go overnight. That's probably good.

And to contrast with that guy's experience, I work on a team with a C++/Java codebase, and we've given serious consideration to rewriting most of our code in Go, because Go's concurrency model would be a true breath of fresh air. To us, Go is solving a very real, very significant problem. We're pushing the languages we currently use to breaking point, where Go would take it all in its stride. The concurrency model in particular is a life-saver for us, but the more subtle benefits of interfaces and a blazingly fast compiler would also be wonderful.

... And since I missed gmail's undo by a fraction of a second, I should clarify that I'm talking about engineering at Google here. In our team, we find Spencer's assertion about Go to be severely incorrect. What you should take away from this is that Google is a big place, and different teams and contexts can have rather different opinions about things, especially when it comes to highly polarizing topics like programming languages.

[André Moraes]

>
> I hadn't expected the post to go viral, so I was writing it mostly for
> people who knew me personally.

This shows the power of Hacker News :)

> When I wrote "significant", I figured this
> would be interpreted as "significant in PL theory/research", since that's
> what I'm always going on about. And that's exactly how I meant it: I'm sure
> the Go team wasn't just spinning their wheels -- they had real problems to
> solve; but if Google isn't innovating in PL theory, who is?

I don't think that Go is "old news" in terms of PL theory.
Go is making a good theory (CSP) being available to a broader audience
and be appliend in real world scenarios.
It's like "applied physics" but for PL.

Also, AFAIK, the way Go handle types is quite new.

--
André Moraes
http://amoraes.info

[⚛]

On Monday, June 4, 2012 2:51:14 PM UTC+2, spencer...@gmail.com wrote:

When I wrote "significant", I figured this would be interpreted as "significant in PL theory/research", since that's what I'm always going on about.

What new language feature would you rate as "significant"?

 

And that's exactly how I meant it: I'm sure the Go team wasn't just spinning their wheels -- they had real problems to solve; but if Google isn't innovating in PL theory, who is?

I believe there do exist at least 100 new or experimental programming languages not supported by Google. A decisive factor here is their completeness.

[Uriel]

On Mon, Jun 4, 2012 at 2:51 PM, <spencer...@gmail.com> wrote:
> Hi guys, sorry I wasn't more specific when I wrote the post. I've updated it
> to clarify.

>
> I hadn't expected the post to go viral, so I was writing it mostly for

> people who knew me personally. When I wrote "significant", I figured this

> would be interpreted as "significant in PL theory/research", since that's

> what I'm always going on about. And that's exactly how I meant it: I'm sure

> the Go team wasn't just spinning their wheels -- they had real problems to
> solve; but if Google isn't innovating in PL theory, who is?

If I had been forced to write Java for six months I also would be
quite disappointed, pissed off and plain bitter.

As for Go, as someone put it ( http://go-lang.cat-v.org/quotes ):

"Go is not meant to innovate programming theory. It’s meant to
innovate programming practice."

I think it succeeds. And as rog paraphrasing rob put it:

"Why would you have a language that is not theoretically exciting?
Because it's very useful."

I wonder why making languages more "theoretically exciting" always has
to involve making languages more complex, one of the most exciting
things about Go is how it manages to be both more useful and simpler,
but I don't think that is a coincidence either.

[Han-Wen Nienhuys]

On Mon, Jun 4, 2012 at 9:51 AM, <spencer...@gmail.com> wrote:
> Hi guys, sorry I wasn't more specific when I wrote the post. I've updated it
> to clarify.
>
> I hadn't expected the post to go viral, so I was writing it mostly for
> people who knew me personally. When I wrote "significant", I figured this
> would be interpreted as "significant in PL theory/research", since that's
> what I'm always going on about. And that's exactly how I meant it: I'm sure
> the Go team wasn't just spinning their wheels -- they had real problems to
> solve; but if Google isn't innovating in PL theory, who is?

Most of the technology in Google (eg. Chubby, bigtable, GFS) is not
about innovating CS theory, but taking known concepts from research
and turn them into efficient, scalable, and usable systems. The
concepts in Go aren't that new, but someone has to sit down and
engineer them into a usable, coherent whole.

--
Han-Wen Nienhuys
Google Engineering Belo Horizonte
han...@google.com

[Ted Stockwell]

On Jun 3, 5:15 pm, Archos <raul....@sent.com> wrote:
> A Google's ex-employee [says][1]:
>
> "Internally-developed languages like Go and Dart failed to solve any
> significant problems."
>

Like the author of the post, I'm a fanatical Java programmer.
However, Go solves a BIG problem for me - concurrency.
I'm trying to create a system that is massively concurrent and I'm
tired of trying to make Threads and locks do what I want.
Go gives me 1) static typing, 2) well designed lightweight
concurrency, and 3) closures, in an imperative programming language.
Those things, together in one language, solve a big problem for me.

[Paulo Pinto]

On 4 Jun., 15:09, André Moraes <andr...@gmail.com> wrote:

> Also, AFAIK, the way Go handle types is quite new.
>

Ada?

[Spencer Tipping]

On Jun 4, 7:30 am, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
> What new language feature would you rate as "significant"?

IMO, it isn't about what is included; it's about what is left out.
Scheme, for example, doesn't define OO, yet for many purposes it's
still very useful. I feel like Go included a lot of stuff that didn't
need to be there -- like Java, it contains a lot of higher-level
features that could be implemented in fewer lower-level ones.

For example, what happens if the module system is made first-class?
Does this make it possible to write a library that does hot code
replacement?

I also want to point out that my argument is, to a large extent,
preposterous. I have yet to write a programming language that has
succeeded by any means, so who am I to say Google is wrong? The extent
of my criticism is that I think Go is too boring to be a creation of
the field's greatest minds.

> I believe there do exist at least 100 new or experimental programming
> languages not supported by Google. A decisive factor here is their
> completeness.

I believe you. My question was intended to be rhetorical, but I think
it ended up being ambiguous.

[Spencer Tipping]

> If I had been forced to write Java for six months I also would be
> quite disappointed, pissed off and plain bitter.

Well, ok. I'm not pissed off or bitter. I'm just a little
disappointed, and that's mostly my own fault. Before I joined Google,
I thought of them as being an academic haven of great ideas. And I
think there are parts of the company like this, but it's also become a
large get-it-done software shop. Honestly, I am grateful for my
experience; my post was about how it differed from what I expected.

> As for Go, as someone put it (http://go-lang.cat-v.org/quotes):
>
> "Go is not meant to innovate programming theory. It’s meant to
> innovate programming practice."
>
> I think it succeeds. And as rog paraphrasing rob put it:
>
> "Why would you have a language that is not theoretically exciting?
> Because it's very useful."
>
> I wonder why making languages more "theoretically exciting" always has
> to involve making languages more complex, one of the most exciting
> things about Go is how it manages to be both more useful and simpler,
> but I don't think that is a coincidence either.

It doesn't always have to do this. Scala, for example, is a disaster
of academic arrogance. In my limited point of view, true innovations
in language theory involve coming up with a better low-level basis and
implementing higher-level features in libraries. A limit case of this
is something like Forth, where the comment word (open paren) is
defined as a function that advances the input pointer to the next
close-paren. A more realistic example is something like Lisp, where
the OO system can be defined within the language as a series of macros.

[Aram Hăvărneanu]

Saying Go is not theoretically exciting because it does not introduce
new features is like saying computers were not theoretically exciting
because we already had vacuum tubes and transistors.

--
Aram Hăvărneanu

[David Anderson]

A more fitting analogy is that if you're looking to be on the bleeding edge of memristor technology, incremental improvements in transistor-based technology isn't that exciting.

- Dave

[Gustavo Niemeyer]

On Mon, Jun 4, 2012 at 11:19 AM, Spencer Tipping
<spencer...@gmail.com> wrote:
> of my criticism is that I think Go is too boring to be a creation of
> the field's greatest minds.

(...)

> I believe you. My question was intended to be rhetorical, but I think
> it ended up being ambiguous.

No, that's called trolling, and you're still doing it. I can't even
take you seriously enough to provide useful facts. Please excuse me as
I have some coding to do.


gustavo @ http://niemeyer.net

[⚛]

On Monday, June 4, 2012 4:19:32 PM UTC+2, Spencer Tipping wrote:

On Jun 4, 7:30 am, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
> What new language feature would you rate as "significant"?

IMO, it isn't about what is included; it's about what is left out.

If it isn't in the Go language, it can be in a library written in Go (or it can be somewhere elsewhere). 

 

Scheme, for example, doesn't define OO, yet for many purposes it's
still very useful. I feel like Go included a lot of stuff that didn't
need to be there -- like Java, it contains a lot of higher-level
features that could be implemented in fewer lower-level ones.

- If a feature is included into a programming language, that single feature can grow (increase the size of) the language by a large amount. This is because the set which includes the feature needs to be complete or at least needs to be convenient to use.

- Even Lisp and Scheme programs have layers.

 

For example, what happens if the module system is made first-class?
Does this make it possible to write a library that does hot code
replacement?

If you cannot replace code at run-time, you can replace data at run-time. The latter can be done very easily in Go.

It would be possible to add hot code replacement to Go, but some major parts of it would need to be written in C.

 

I also want to point out that my argument is, to a large extent,
preposterous. I have yet to write a programming language that has
succeeded by any means, so who am I to say Google is wrong? The extent
of my criticism is that I think Go is too boring to be a creation of
the field's greatest minds.

 

Go never claimed to be a research language. Go is practical. 

Maybe boredom is to some extent a fact of life, and it is irreducible.

It is impossible to design a problem around a programming language - programming language, or source code written in that programming language, needs to be designed around a problem.

Can you describe the problem you are trying to solve?

[⚛]

On Monday, June 4, 2012 4:19:18 AM UTC+2, Andrew Gerrand wrote:

I'm don't see how someone who was at Google for only 6 months would be in a position to judge the success or failure of anything.

When Google was 6 months old (in 1996 or 1997), all its employees were in position to judge success or failure - despite the fact that they were at Google for only 6 months.

... in my opinion, it would be better to investigate why the author of http://www.spencertipping.com/posts/2012.0530.why-i-left-google.html thinks that "Go and Dart failed to solve any significant problem", instead of pointing out the length of employment. If the author's supporting arguments are incorrect, the incorrectness of arguments will slowly show off during the discussion.

[Thomas Bushnell, BSG]

On Tue, Jun 5, 2012 at 9:26 AM, ⚛ <0xe2.0x...@gmail.com> wrote:

On Monday, June 4, 2012 4:19:18 AM UTC+2, Andrew Gerrand wrote:

I'm don't see how someone who was at Google for only 6 months would be in a position to judge the success or failure of anything.

When Google was 6 months old (in 1996 or 1997), all its employees were in position to judge success or failure - despite the fact that they were at Google for only 6 months.

No, I don't think so. Even then, it was possible in six months in 1996 to know everything that was going on at Google. It is not possible today.

 

... in my opinion, it would be better to investigate why the author of http://www.spencertipping.com/posts/2012.0530.why-i-left-google.html thinks that "Go and Dart failed to solve any significant problem", instead of pointing out the length of employment. If the author's supporting arguments are incorrect, the incorrectness of arguments will slowly show off during the discussion.

The author's length of employment has nothing to do with whether Go and Dart failed to solve any significant problem indeed. But it does have something to do with his lack of awareness of what's going on in the company at large. Did Spencer's team have a pathological love for Java? I don't know; perhaps it did. But the company as a whole certainly does not. How can Spencer assert that "most engineers were not comfortable with..." whatever styles of programming he most loves? Is he speaking about his own team, or the small minority he ran across in his six months? Where does he have the experience to say that?

And, on and on. He is clear that he's speaking only from his own experience, but it's worth noting that it's a strikingly small experience, and completely not sufficient to speak to the claims he makes. Given that, we should interpret his statement about Go thus: "Go and Dart failed to solve any significant problems on his team."

Thomas

[Jim Whitehead II]

You don't have to interpret anything. He's here, in this thread. He's
responded, several times. He's provided an update on the blog post
clarifying that he wrote the post for a limited audience and did not
expect it to go as far as it did.

I think he's been fairly clear in why he wrote what he did about Go,
and there's not much more to see here.

- Jim

[Patrick Mylund Nielsen]

Agree. I'm surprised how excessively defensive the response has been.
Rather attack or ridicule the person than recognize any faults with
this beautiful and marvelous language.

I love Go. It's efficient, I'm efficient and productive using it, and
it tends to just make sense, but I don't see why people are so
defensive about it being theoretically exciting. It's not. It's
practically exciting, and that's by design. The quote from Rob Pike is
in this very thread!

Spencer has responded calmly and constructively several times,
pointing out that his comments are subjective, only speak for a very
small part of Google (which should be obvious, anyway--we hear about
big teams at Google using Go for great success all the time), and that
his major disappointment is a lack of innovation in PL theory, yet
several of you respond like you just had an ice cream knocked out of
your hands. Calm down. Try to recognize valid, constructive points in
his arguments. If you can't, what's the problem?

For the Googlers: If you love working at Google, explain why. Don't
make fun of people who said they "did, but". It's self-defeating.

[Gustavo Niemeyer]

> Spencer has responded calmly and constructively several times,

In a constructive conversation, by definition, one attempts to
construct something. This isn't achieved by disregarding someone
else's work because "you think it's boring" or because you think it's
a "disaster of academic arrogance". That kind of opinion simply
doesn't matter, whether your preference is for getting things done
or sweating on the latest unproven whitepaper. It does work to
get people heated up and emotional, though.

Luckily, this list frequently sees great debate, and a lot of
on-the-ground discussions with cross-language considerations. I'll be
waiting for more of those.


gustavo @ http://niemeyer.net

[Paul]

On Jun 4, 4:24 pm, Spencer Tipping <spencer.tipp...@gmail.com> wrote:
" A more realistic example is something like Lisp, where
the OO system can be defined within the language as a series of
macros."

Lisp is a very interesting Language and today we actually have the
hardware to run it, which sadly was not the case when that language
was first invented or even in the decades that followed. It is
actually very amazing to see how advanced some PL's already were in
the 50-70s. A small team of Lisp experts can probably be
incredibably productive and get a lot done, if they have an
industrial grade developement environment which is well maintained; I
am not deep enough into Lisp to know if such a thing is available
somewhere or not.

There are very many considerations that play a role however, when a
language gets selected for a project or a program of projects. I
remember round about 2003 when certain management levels of some very
big Software Vendors, were saying that its primarily important to use
Java because there are all these (...millions?) unemployed programmers
in India and elsewhere in Asia and eastern Europe that know Java ...
this was from an economical point of view a very important argument
for some high-level Java proponents. Needless to say there were
incredibly huge failures of Java Projects; few of them we heard about
and many we did not hear about, because corporations do not publically
speak about these kinds of major failures. With the recent squabbles
about copyright and patent issues the problems have significantly
gotten bigger.

The reasons I got interested in the Go-Language is mainly because it
compiles to native code, and its designed to exploit multi-core
architectures and has concurrency built in (still some ongoing work on
that part, also in GC). I have developed a strong dislike for VM's for
all the various troubles we had with them; and if your language has
to run on a VM then it will always be limited by the VM. It takes
years for a programming language to mature, and I think GO is coming
along nicely, I think it has a good chance to succeed. My hope is
that when the low hanging fruit in optimizations gets done, that it
will outperform just about anything else out there. And its reasonably
easy for C or C++ programmers to transition to it.

[Corey Thomasson]

Can you imagine if someone said something like this in another field?

"CERN has the intellectual firepower to be going where no physicist has gone before, yet their experiments remain solidly in the realm of existing scientific methods and, for the most part, mathematical models. Smashing atoms together may be interesting, but it makes me want collide my brain with a wall"

On 8 June 2012 17:18, Sean Walsh <sean.pea...@gmail.com> wrote:

His latest update to this:

"Google has the intellectual firepower to be going where no programmer has gone before, yet languages like Go remain solidly in well-understood and, for the most part, commonly-implemented territory. I have no doubt that this is a good strategic move on Google's part, and that Go solves a number of important problems that Google faces, but I was disappointed that Google hadn't taken a more experimental and research-focused approach." 

I basically read this as: "Go isn't a nerdy enough language."  As a C++ programmer by day I'm not even remotely interested in a language that favours an "experimental" approach rather than a "well-understood" and practical one.

IMO it sounds as though he'd be better suited to academia.    And for the record I am not a Google employee and have only recently discovered Go, so please don't accuse me of fanboyism.

[Sean Walsh]

Exactly.  I found his reasoning to be extremely obtuse.

[Andrew Gerrand]

Might we end this thread now?

I think it's clear what Spencer meant. There is nothing more to see here.

Andrew

[bugpowder]

On Tuesday, June 5, 2012 9:36:29 PM UTC+8, Gustavo Niemeyer wrote:

> Spencer has responded calmly and constructively several times,

In a constructive conversation, by definition, one attempts to
construct something. This isn't achieved by disregarding someone 

else's work because "you think it's boring" or because you think it's
a "disaster of academic arrogance". 

Constructive conversation is not (much less so "by definition") about constructing something.

The dictionary definition gives this particular use as "helping to improve; promoting further development or advancement".

Now, you can very well help something to improve by """disregarding someone else's work because "you think it's boring" or because you think it's a "disaster of academic arrogance".""" 

 

Criticizing something as bad, boring, me-too, too academic etc is as much part of improving it (or improving the general field, i.e PL research) as anything.

[Tibor]

Hey! Thanks for the apology.

However it is still not clear to me whether you *really* tried Go.

What languages do you use for your projects?

Many people just flip through the pages and code samples and say "alright I get it" and then either forget about it or start trolling right away. I am personally having a hard time having certain people try Go for real. I might do something wrong or maybe it just depends on the people.

Anyways I wish you could try Go and see how radically different kind of programming it brings compared to the Java-esque languages.

[Tibor]

[Patrick Mylund Nielsen]

Go is not Clojure. Try to write something in Go!

On Sat, Dec 1, 2012 at 5:47 PM, <spencer...@gmail.com> wrote:

I haven't really used Go yet. The experience I'm referring to is using Clojure, which does a great job with concurrent programming and is perhaps the most fun language I've ever used. At first I had written Clojure off as a compromised (due to reader support for maps and vectors) Lisp, but now that I'm using it on a regular basis I'm really impressed with it. And Clojure is similar to Go in that its value isn't primarily conceptual, but rather from how well it suits its purpose in practice. (Though I should add that Clojure does bring some conceptual innovation to the table as well, at least within the space of Lisps.)

Regarding motivating people to use Go, it occurs to me that Google might not be very good at selling languages. I could be overgeneralizing on that point, but as a Javascript developer the Dart synonym page looked fairly uninspiring: http://synonym.dartlang.org/ (and in some cases the page is incomplete or misleading; e.g. "const" in newer versions of Javascript). The reason it's uninspiring to me is that, coming at it from the perspective of Javascript, I see the introduction of a type system (which I'm not really a fan of, being a JS developer), some kind of worrying browser compatibility stuff, and a bunch of other stuff that in many cases can be solved with libraries. I also have to learn a whole new set of semantics and idioms; for instance, suppose I'm interfacing with JS code that gives me undefined ... how do I check for that case? I do get some nice features for it, like string interpolation, but I can get rid of most of the negative adoption costs by going with a thinner abstraction layer like CoffeeScript instead.

Another point is that Java has been the status quo for some time; people who enjoy adopting new languages have had lots of time to explore alternatives, and many of those alternatives aren't very Java-like (Ruby, Scala, Clojure, Haskell, etc). So using C/Java-style syntax in the Go language might work against its adoption, since early adopters who are used to non-Java stuff may assume that the syntactic similarity implies a conceptual similarity, or they may just not like C-style syntax. (Both apply in my case, and that's part of the reason it took me so long to see why Go might be useful. The other part is that I was just being closed-minded.)

I'm mostly thinking out loud here in response to your point about Go adoption, but I think it's really interesting question. You may have just given me an idea for another blog post.

--
 
 

[Thomas Bushnell, BSG]

Selling languages doesn't make them better.

On Sat, Dec 1, 2012 at 8:47 AM, <spencer...@gmail.com> wrote:

I haven't really used Go yet. The experience I'm referring to is using Clojure, which does a great job with concurrent programming and is perhaps the most fun language I've ever used. At first I had written Clojure off as a compromised (due to reader support for maps and vectors) Lisp, but now that I'm using it on a regular basis I'm really impressed with it. And Clojure is similar to Go in that its value isn't primarily conceptual, but rather from how well it suits its purpose in practice. (Though I should add that Clojure does bring some conceptual innovation to the table as well, at least within the space of Lisps.)

Regarding motivating people to use Go, it occurs to me that Google might not be very good at selling languages. I could be overgeneralizing on that point, but as a Javascript developer the Dart synonym page looked fairly uninspiring: http://synonym.dartlang.org/ (and in some cases the page is incomplete or misleading; e.g. "const" in newer versions of Javascript). The reason it's uninspiring to me is that, coming at it from the perspective of Javascript, I see the introduction of a type system (which I'm not really a fan of, being a JS developer), some kind of worrying browser compatibility stuff, and a bunch of other stuff that in many cases can be solved with libraries. I also have to learn a whole new set of semantics and idioms; for instance, suppose I'm interfacing with JS code that gives me undefined ... how do I check for that case? I do get some nice features for it, like string interpolation, but I can get rid of most of the negative adoption costs by going with a thinner abstraction layer like CoffeeScript instead.

Another point is that Java has been the status quo for some time; people who enjoy adopting new languages have had lots of time to explore alternatives, and many of those alternatives aren't very Java-like (Ruby, Scala, Clojure, Haskell, etc). So using C/Java-style syntax in the Go language might work against its adoption, since early adopters who are used to non-Java stuff may assume that the syntactic similarity implies a conceptual similarity, or they may just not like C-style syntax. (Both apply in my case, and that's part of the reason it took me so long to see why Go might be useful. The other part is that I was just being closed-minded.)

I'm mostly thinking out loud here in response to your point about Go adoption, but I think it's really interesting question. You may have just given me an idea for another blog post.

On Thursday, November 29, 2012 11:25:14 AM UTC-6, Tibor wrote:

--
 
 

[Patrick Mylund Nielsen]

Because doing so will help you answer those questions. No one else can tell you why language X is "better" than Y, only what features one has and another doesn't. It's too subjective.

Go is a nice, modern C, or "C++ as it should have been." It is killer for many applications you'd write in C, or applications you'd like to write in Ruby or Python, but need to be fast, concurrent, parallel, and reasonably predictable. If you don't like C, that's okay. Don't use Go. It sounds like you prefer functional languages, and Go certainly isn't one. Square peg in a round hole.

On Sat, Dec 1, 2012 at 6:11 PM, <spencer...@gmail.com> wrote:

That's a fair point, but why? (And I'm not trying to be a troll or anything; it's an honest question)

Clojure gives me a number of things that I really like, among which are syntax macros, dynamic typing, immutable data structures and excellent destructuring binds, transparent JVM interop, REPL-oriented development, non-OO multimethods, and a nice hybrid of familiar semantics from Lisp and Java. Now it also comes with some disadvantages, but since I already knew Java and Lisp the adoption cost was very low for me and Clojure is decisively better than either one for what I'm doing.

My honest question is, from my point of view (i.e. relative to Clojure) what does Go bring to the table? If I were writing a large application and collaborating with other developers, it would bring API stability (due to types), performance, and a unified way of doing inter-process communication. And if I were coming from Java only, it would be a clear win, since it makes a lot of things easier than they are in Java. But you're already assuming that I'm willing to adopt Go over Java, which would mean I'm a member of the demographic that is willing to learn a new language to solve a problem. Once that's the case, Go isn't competing with Java anymore; it's competing with Java, Ruby, Lisp, Scheme, OCaml, Haskell, Scala, Clojure, F#, D, CoffeeScript, Factor, Erlang, etc. Go has a natural advantage in that because it was developed by Google it probably has a lot of internal consistency and is likely to be well-engineered, but since it's a new language without a well-known killer library (e.g. Rails for Ruby, jQuery for Javascript, Cascalog for Clojure), people could be justifiably hesitant to absorb the cost of learning it.

By the way, I'm not saying this to put Go down. I didn't apologize about criticizing it just to go and repeat my mistake :) I really want to better understand where it fits in the space of languages and what its killer use case is. But I also want to be realistic in comparing it to alternatives. If I use Go, I want it to be because it's the shortest path from one of my problems to a good solution.

--
 
 

[Rémy Oudompheng]

On 2012/12/1 <spencer...@gmail.com> wrote:
> My honest question is, from my point of view (i.e. relative to Clojure) what
> does Go bring to the table?

Go is here precisely because it doesn't bring something in particular.
We already have tons of languages that provide asynchronous network
processing, interfaces, that have better support for generics,
libraries to do every single possible wicked thing in the world.

> If I were writing a large application and
> collaborating with other developers, it would bring API stability (due to
> types), performance, and a unified way of doing inter-process communication.
> And if I were coming from Java only, it would be a clear win, since it makes
> a lot of things easier than they are in Java. But you're already assuming
> that I'm willing to adopt Go over Java, which would mean I'm a member of the
> demographic that is willing to learn a new language to solve a problem. Once
> that's the case, Go isn't competing with Java anymore; it's competing with
> Java, Ruby, Lisp, Scheme, OCaml, Haskell, Scala, Clojure, F#, D,
> CoffeeScript, Factor, Erlang, etc. Go has a natural advantage in that
> because it was developed by Google it probably has a lot of internal
> consistency and is likely to be well-engineered, but since it's a new
> language without a well-known killer library (e.g. Rails for Ruby, jQuery
> for Javascript, Cascalog for Clojure), people could be justifiably hesitant
> to absorb the cost of learning it.

Go is competitive because it's trivial to learn the basics. Because
the lack of weirdly built libraries forces you to write in a clean and
understandable style. Because it doesn't haave lisp parentheses nor
C++ semicolons.

It might be very dififcult for it to integrate into an existing
environment and the advantages may seem very little. But the expected
improvement is simultaneously a long-term maintainability and a
short-term satisfaction for things that most people will consider
irrelevant details (but that really make a difference).

Rémy.

[Lucio]

I could not agree more, Go is really "a better C", although it is not "a better assembler".  In a way (and in my opinion) it is to the OS what assembler is to the hardware.  And maybe not so much to the OS as to the more generic impression of what a modern OS ought to be.

In a way I think Go will be as influential in the distributed world created by the Internet as C was in the multiuser world of Unix (while oversimplifying, of course).

[Mathieu Lonjaret]

Hi,

in all the time it took you to read/write the e-mails in this thread
you could have completed the go-tour by now
(http://tour.golang.org/#1), or started your own little project in Go,
and I bet you'd have most of the answers of the questions you're
asking yourself right now.
But then you don't seem to be the only one who apparently prefers
spending hours in e-mail threads rather than trying things for
yourself. That's a curious trend, which I'm having some trouble
understanding.

Still, kudos to you for keeping an open mind.

Cheers,
Mathieu

On Sat, Dec 1, 2012 at 6:11 PM, <spencer...@gmail.com> wrote:
> That's a fair point, but why? (And I'm not trying to be a troll or anything;
> it's an honest question)
>
> Clojure gives me a number of things that I really like, among which are
> syntax macros, dynamic typing, immutable data structures and excellent
> destructuring binds, transparent JVM interop, REPL-oriented development,
> non-OO multimethods, and a nice hybrid of familiar semantics from Lisp and
> Java. Now it also comes with some disadvantages, but since I already knew
> Java and Lisp the adoption cost was very low for me and Clojure is
> decisively better than either one for what I'm doing.
>

> My honest question is, from my point of view (i.e. relative to Clojure) what

> does Go bring to the table? If I were writing a large application and

> collaborating with other developers, it would bring API stability (due to
> types), performance, and a unified way of doing inter-process communication.
> And if I were coming from Java only, it would be a clear win, since it makes
> a lot of things easier than they are in Java. But you're already assuming
> that I'm willing to adopt Go over Java, which would mean I'm a member of the
> demographic that is willing to learn a new language to solve a problem. Once
> that's the case, Go isn't competing with Java anymore; it's competing with
> Java, Ruby, Lisp, Scheme, OCaml, Haskell, Scala, Clojure, F#, D,
> CoffeeScript, Factor, Erlang, etc. Go has a natural advantage in that
> because it was developed by Google it probably has a lot of internal
> consistency and is likely to be well-engineered, but since it's a new
> language without a well-known killer library (e.g. Rails for Ruby, jQuery
> for Javascript, Cascalog for Clojure), people could be justifiably hesitant
> to absorb the cost of learning it.
>

> By the way, I'm not saying this to put Go down. I didn't apologize about
> criticizing it just to go and repeat my mistake :) I really want to better
> understand where it fits in the space of languages and what its killer use
> case is. But I also want to be realistic in comparing it to alternatives. If
> I use Go, I want it to be because it's the shortest path from one of my
> problems to a good solution.
>
>
> On Saturday, December 1, 2012 10:53:58 AM UTC-6, Patrick Mylund Nielsen
> wrote:
>>

> --
>
>

[Archos]

El sábado, 1 de diciembre de 2012 17:11:17 UTC, spencer...@gmail.com escribió

My honest question is, from my point of view (i.e. relative to Clojure) what does Go bring to the table?

The code that I write is compiled and it works in main architectures and operating systems with a balance between speed and usage of memory, and the addition of easy handling of concurrency.

Go isn't competing with Java anymore; it's competing with Java, Ruby, Lisp, Scheme, OCaml, Haskell, Scala, Clojure, F#, D, CoffeeScript, Factor, Erlang, etc.

Go has very few competitors:

+ Against dynamic languages, mainly, Go performs in memory and ease of debugging (static typing is a great help)
+ Against functional languages, Go has a clear sintaxis
+ Against Java, Go performs and memory, speed of execution, and lower vervosity.
+ Against JavaScript, performs in memory, in addition of be well designed. There are many problems known in the design of JS like the usage of floats to handle all numbers.

since it's a new language without a well-known killer library (e.g. Rails for Ruby, jQuery for Javascript, Cascalog for Clojure), people could be justifiably hesitant to absorb the cost of learning it.

"You must first sow".

There are many interesting project that can be done in Go with the help of Rust (where I'm wrapped), i.e. desktop applications that can work in whatever system (included tablets/smart phones) and internet using the same code. And the same for Games. Sorry by Microsoft.

Einstein said once that imagination is more important than knowledge so you don't think about that Go can do by you, else you can do by Go.

I'm sure that Go will be in the Top 20 of languages most used before of 2015.

[⚛]

On Monday, December 3, 2012 3:41:02 PM UTC+1, Archos wrote:

El sábado, 1 de diciembre de 2012 17:11:17 UTC, spencer...@gmail.com escribió

My honest question is, from my point of view (i.e. relative to Clojure) what does Go bring to the table?

The code that I write is compiled and it works in main architectures and operating systems with a balance between speed and usage of memory, and the addition of easy handling of concurrency.

Go isn't competing with Java anymore; it's competing with Java, Ruby, Lisp, Scheme, OCaml, Haskell, Scala, Clojure, F#, D, CoffeeScript, Factor, Erlang, etc.

Go has very few competitors:

+ Against dynamic languages, mainly, Go performs in memory and ease of debugging (static typing is a great help)
+ Against functional languages, Go has a clear sintaxis
+ Against Java, Go performs and memory, speed of execution, and lower vervosity.
+ Against JavaScript, performs in memory, in addition of be well designed. There are many problems known in the design of JS like the usage of floats to handle all numbers.

In my opinion, the apparent absence of integers in JS is mainly a problem for the JS compiler rather than for the programmer.

[Archos]

I should be more specific.

JavaScript can not actually do meaningful integer arithmetic on anything bigger than 2^53. By this reason, the integers of 64 bits are unsupported.
Also bitwise logical operations only have defined results (per the spec) up to 32 bits. 

[Robert Johnstone]

While I really like Go, I disagree with this statement.  For the applications areas where C (or C++) would have been the best choice, Go changes nothing.  I have a few firmware projects for embedded microprocessors - they are going to remain in C.  I have a few engineering simulation projects that are mathematically very intense - they are going to remain in C++.  Personally, I have no projects written in either C or C++ where Go would be feasible, let alone better.  Go is not a better C, nor is it a better C++.

Go is an excellent language, but positioning matters.  On my first approach at using Go, I walked away in disgust because it was such an inappropriate choice for my projects written using C.  I've since come back Go, and it has been an excellent choice for some other projects.  But, for my two cents, if someone finds Go killer for applications that they were writing in C, they probably should not have been using C in the first place.

[Patrick Mylund Nielsen]

> For the applications areas where C (or C++) would have been the best choice, Go changes nothing.  I have a few firmware projects for embedded microprocessors - they are going to remain in C.

Almost all applications that are written in C and available in e.g. the Debian package repositories could have been written in Go with good results. There is a very large number of C and C++ programs that don't run on embedded devices, need manual memory managemenet, etc.

--
 
 

[Robert Johnstone]

I agree, but those programs had a wide range of possible languages to begin with.  And, as I said, they probably should not have been written in C in the first place.  For those applications that really need to be in C, for those applications where C really is the best choice, Go is not a feasible alternative.  That is why I believe that saying Go is a better C is misleading.

[Patrick Mylund Nielsen]

Your argument is a little self-defeating. You say they shouldn't have been written in C, but Go is a nice alternative to imperative languages that the applications could have been written in, like Python. So you shouldn't use Go instead of C, rather you should use e.g. Python, but then you should use Go instead of Python?

I'm not trying to say that C is obsolete, just that Go is now a better choice when writing alternatives to a very large array of applications written in C. I agree with you that there are still areas where C is still the clear winner. (I don't really agree about C++, except maybe for some cases where it's what you have to use for compatibility/interoperability.)

--
 
 

[⚛]

On Monday, December 3, 2012 6:35:58 PM UTC+1, Patrick Mylund Nielsen wrote:

> For the applications areas where C (or C++) would have been the best choice, Go changes nothing.  I have a few firmware projects for embedded microprocessors - they are going to remain in C.

Almost all applications that are written in C and available in e.g. the Debian package repositories could have been written in Go with good results. There is a very large number of C and C++ programs that don't run on embedded devices, need manual memory managemenet, etc.

I agree, except that I think it isn't "almost all". There exist applications written in C that could be more succinctly written in Go, while running at approximately the same speed as the C code. For example one could rewrite top, bind, nasm, wget, file. A very nice example is that one could rewrite make. Rewriting the code would make it safer and the code can take advantage of garbage collection.   It is hard to say what would be the actual difference without actually rewriting at least one of the mentioned utilities.

A major issue is that Go code isn't directly callable from C as a library function. This means that rewriting software from C to Go in an incremental way is impossible.

[bryanturley]

On Monday, December 3, 2012 12:01:00 PM UTC-6, Robert Johnstone wrote:

I agree, but those programs had a wide range of possible languages to begin with.  And, as I said, they probably should not have been written in C in the first place.  For those applications that really need to be in C, for those applications where C really is the best choice, Go is not a feasible alternative.  That is why I believe that saying Go is a better C is misleading.

I can only think of a few niche software realms where go would not be a good choice over c.
You say you are writing firmware perhaps you are seeing it only from that angle. I would agree if you are writing firmware for devices at the moment go is probably not a good choice.
Assuming you are not working at a company that ships full 1u opteron servers and calls the linux based install "firmware".

[Robert Johnstone]

This is becoming a question of semantics, and we are probably nearly on the same page.  I just want to emphasize that those applications where C really shines, where it is the only choice, are those areas where Go is infeasible.  I gave the example of firmware, but there are also operating systems, hardware drivers, etc.  There is quite a lot of code out there where Go is not really better than C.  Go is an excellent language, but calling it a replacement for C is misleading, and will cause confusion.

I realize that nobody called Go a replacement for C, but calling Go a better C than C essentially implies the same thing, hence my disagreement.

[Patrick Mylund Nielsen]

Let me rephrase: Go is a modern language in the style of C.

--
 
 

[Thomas Bushnell, BSG]

The arguments that Go is not suitable for such things would, if correct, also prove that Lisp is not. But Lisp has quite productively been used for such things. Only two possibilities could account for this. First, it could be that there's a hidden premise for the argument, which explains the unsuitability of Go for these cases where Lisp works fine. Or, it could be that the argument isn't valid for either.

But when the argument is so disconnected from facts as this, I suspect a third possibility. The speaker may simply know so little about, for example garbage collection, that they can't detect true from false. This is especially true when they repeat things which were disproven decades ago.

Thomas

--
 
 

[Dan Kortschak]

I'd disagree with this with a caveat; C is undoubtedly the "best" choice for the software I write is only finished product performance is considered. I don't write in C because my C is not good enough and my time is too limited to ensure that I can get out reasonable quality software that safely passes peer review.

The very reason I took up Go was to rewrite a C program. The context is important here. I wanted something that was fast enough to run with very large data and fast enough to write with limited C or C++ background (mine and that of future students in the lab who would be maintaining it and writing new similarly specified tools). Go has satisfied this requirement very well, and so has changed a lot in our lab in terms of what software we can expect to develop.

Dan

[Robert Johnstone]

From your brief description, your project is not in the group of applications I was talking about.  In fact, it sounds to me like, even without Go, that C would not be the best choice.  I'm glad your project has been successful, but your example does address the point that I was making.  Note:  Fallacy of composition - you've assumed that since Go was better than C for you, that it will be better in all cases.

Please not that I was not arguing that C is better than Go either.  I was just pointed out that the phrase "better C than C" is misleading.  As you said, which language is more appropriate will depend.

[Robert Johnstone]

Given that Go has a well known memory problem on 32-bit systems, it would be interesting to see how it handles my 16-bit MCUs.  Still, if you can provide a tool chain for dsPICs, please let me know.

[bryanturley]

On Monday, December 3, 2012 3:37:51 PM UTC-6, Robert Johnstone wrote:

Given that Go has a well known memory problem on 32-bit systems, it would be interesting to see how it handles my 16-bit MCUs.  Still, if you can provide a tool chain for dsPICs, please let me know.

That isn't go the languages problem that is the current implementation's problem and is being rectified.
It would take a good bit of work to get go working on 16bit anythings and probably not be worth it in the end on a device with so little ram.

[Thomas Bushnell, BSG]

This is a deficiency in one implementation, not in the language.

--
 
 

[Robert Johnstone]

You are correct, and I was being unfair to the 32-bit implementation.  Still, seeing as my current tool chain in C omits most of the standard library (too big to fit), I'm doubtful that there is room for the Go runtime.

In the end, it is not disparaging to Go to say, this is not what Go was meant for.  It is a little funny to see multiple people rushing in to defend Go as a possible solution for embedded devices!

[Thomas Bushnell, BSG]

The Go runtime is pretty small.

Frankly, I think that the idea that languages are suited to particular tasks to be itself quite incorrect. It's a natural way of thinking ("different tools are good for different things"), but it's generally lazy thinking, and it isn't even a good principle. We would never accept the idea that different typewriters are suited for writing different kinds of fiction.

--
 
 

[⚛]

On Monday, December 3, 2012 11:37:52 PM UTC+1, Thomas Bushnell, BSG wrote:

The Go runtime is pretty small.

Frankly, I think that the idea that languages are suited to particular tasks to be itself quite incorrect. It's a natural way of thinking ("different tools are good for different things"), but it's generally lazy thinking, and it isn't even a good principle. We would never accept the idea that different typewriters are suited for writing different kinds of fiction.

In many cases the ability for a person to do certain tasks depends solely on the distance to a goal. Different tools = different distances. Different languages = different distances.

[Rui Maciel]

Go might be "a better C", and it might one day supersede C, but by no
means it is "C++ as it should have been". That's just plain nonsense.


Rui Maciel

[Rui Maciel]

On 12/03/2012 05:35 PM, Patrick Mylund Nielsen wrote:
> Almost all applications that are written in C and available in e.g. the
> Debian package repositories could have been written in Go with good
> results. There is a very large number of C and C++ programs that don't run
> on embedded devices, need manual memory managemenet, etc.

Truth be told, that doesn't say much about Go, because it remains just
as true if you replace "Go" with $language_of_choice.




Rui Maciel

[Patrick Mylund Nielsen]

Go was created mainly as a replacement to C++. http://commandcenter.blogspot.se/2012/06/less-is-exponentially-more.html

--

[Patrick Mylund Nielsen]

Some other languages, yes. All languages, no.

Rui Maciel

--

[Rui Maciel]

I'm sure that you can come up with some language which you can argue
that, in some aspect, according to your personal taste it is somehow
inferior to Go. Yet, that would still say nothing relevant and
objective about Go.

I understand your enthusiasm, but let's not get carried away. It's far
too early to form a cult.


Rui Maciel

[Rui Maciel]

On 12/03/2012 06:09 PM, Patrick Mylund Nielsen wrote:
> Your argument is a little self-defeating. You say they shouldn't have been
> written in C, but Go is a nice alternative to imperative languages that the
> applications could have been written in, like Python. So you shouldn't use
> Go instead of C, rather you should use e.g. Python, but then you should use
> Go instead of Python?
>
> I'm not trying to say that C is obsolete, just that Go is now a better
> choice when writing alternatives to a very large array of applications
> written in C. I agree with you that there are still areas where C is still
> the clear winner.

Notice that your argument lacks objectivity. Although your own
description of Go is that it is essentially nothing more than yet
another "nice alternative" available in the programming world, you are
quick to claim that it is automatically a "better choice when writing
alternatives to a very large array of applications written in C", in
spite of not making any case, or having presented any evidence or
reasoning to back that assertion.

I understand the enthusiasm, and I also share your interest in Go, but
it is better to let the language speak for itself, and let it show the
value of its technical qualities, instead of trying to speak on its
behalf, and show nothing at all.


Rui Maciel

[Patrick Mylund Nielsen]

I like how you went from my statement about Go being a nice C to me forming a cult. Look up my posts to see how you're wrong. I criticize Go just as often as I praise it.

Come back when you can add something constructive, or anything at all, to the conversation.

[Rui Maciel]

On 12/03/2012 06:18 PM, bryanturley wrote:
> I can only think of a few niche software realms where go would not be a
> good choice over c.
> You say you are writing firmware perhaps you are seeing it only from that
> angle. I would agree if you are writing firmware for devices at the moment
> go is probably not a good choice.

Systems programming is essentially the only place (hyperbole!) C is used
nowadays, and even in that area some have already migrated to other
languages, such as C++.


Rui Maciel

[Patrick Mylund Nielsen]

> Systems programming is essentially the only place (hyperbole!) C is used nowadays

This statement is false. You criticize me for not providing any evidence; show me yours.

> even in that area some have already migrated to other languages, such as C++.

Are you implying that C++ is preferable to C? If so, aren't you making the same error that you accused me of making?

The irony in the air is thick!

> Systems programming

Go started out as a systems programming language :)

Rui Maciel

--

[Rui Maciel]

On 12/03/2012 06:52 PM, Robert Johnstone wrote:
> There is quite a lot of code out there
> where Go is not really better than C. Go is an excellent language, but
> calling it a replacement for C is misleading, and will cause confusion.

Hear, hear.

Besides confusion, these overly enthusiastic praises also have a
detrimental effect on the perception of the language, because
overselling invariably leads to disappointments.


Rui Maciel

[Rui Maciel]

I'm starting to believe you are here to troll.

Read the message you've replied to. It looks like you haven't.


Rui Maciel

[Jesse McNelis]

On Tue, Dec 4, 2012 at 11:50 AM, Patrick Mylund Nielsen <pat...@patrickmylund.com> wrote:

> Systems programming is essentially the only place (hyperbole!) C is used nowadays

This statement is false. You criticize me for not providing any evidence; show me yours.

Come on chaps, this is 'computer science' we don't do evidence based reasoning.

We do 'Argument from authority' and generally just make things up based on experience.

You can't ask someone to give evidence of their claim when you know full well that the evidence doesn't exist and is really hard to create.

Go is a language not designed based on rigorous studies of the benefits of various features, it's based on the experiences of the designers.

Every other programming language is designed in the same way.

[Patrick Mylund Nielsen]

Fact: Go is the world's best programming language.

[Rui Maciel]

On 12/03/2012 10:37 PM, Thomas Bushnell, BSG wrote:
> The Go runtime is pretty small.
>
> Frankly, I think that the idea that languages are suited to particular
> tasks to be itself quite incorrect. It's a natural way of thinking
> ("different tools are good for different things"), but it's generally lazy
> thinking, and it isn't even a good principle. We would never accept the
> idea that different typewriters are suited for writing different kinds of
> fiction.

It's not a matter of not being possible to use a language to pull
something off, it's a matter that with some other language it is
significantly easier and simpler to do so. Oddly enough, it appears
that that's exactly why Go came into existence, and C as well.

As a metaphor, if you need to describe in detail a snowy and icy
landscape, someone speaking eskimo will have a far easier job than
someone speaking swahili. That doesn't mean swahili speakers aren't
suited to talk about water in freezing conditions.


Rui Maciel

[Patrick Mylund Nielsen]

> It's not a matter of not being possible to use a language to pull something off, it's a matter that with some other language it is significantly easier and simpler to do so.

Coincidentally that's exactly what I've been saying about Go over C in this thread. Go is one of the better examples of this since its semantics and constructs are very similar to those from C -- hence a "better C."

[Dan Kortschak]

On Mon, 2012-12-03 at 13:33 -0800, Robert Johnstone wrote:
> I'm glad your project has been successful, but your example does
> address the point that I was making. Note: Fallacy of composition -
> you've assumed that since Go was better than C for you, that it will
> be better in all cases.

Not really. I provided one counter example.

[Robert Johnstone]

A quick test just showed me that a simple hello world using println was over 200kB on Linux.  That is pretty lightweight for a desktop, but still way too much for most embedded systems.

I find the idea that all languages are equally suited for all tasks lazy thinking.  You've created a false analogy.  You might as well say, all types of hammers are equally suited for driving nails - something that is plainly false.

[bryanturley]

On Monday, December 3, 2012 8:56:01 PM UTC-6, Robert Johnstone wrote:

A quick test just showed me that a simple hello world using println was over 200kB on Linux.  That is pretty lightweight for a desktop, but still way too much for most embedded systems.

I find the idea that all languages are equally suited for all tasks lazy thinking.  You've created a false analogy.  You might as well say, all types of hammers are equally suited for driving nails - something that is plainly false.

That's what she said.

[Robert Johnstone]

Lesson in logic.  If I say that all A are B, then a single counter example invalidates the argument.  If I say that some A are B, then a single counter example proves nothing.

It is actually quite ironic, as my original point was that saying Go is always better than C is incorrect...

[Thomas Bushnell, BSG]

You're still talking about one implementation, not the language, afaict.

Can you say exactly what about Go (the language, not one implementation or one set of standard libraries) makes it unsuitable for embedded systems? Be sure to distinguish from other languages used in such systems that share the same features.

--
 
 

[Patrick Mylund Nielsen]

> It is actually quite ironic, as my original point was that saying Go is always better than C is incorrect...

Who said that?

This is so far removed from the original comment (which was that Go is a nice language for C programmers, and that if you lean toward the functional side rather than C, Go is unlikely to interest you) it's starting to get sad. By definition, any language that is Turing complete can do the things that have been discussed, but I don't think anyone here is saying that any one language, its implementations or its ecosystem should or must be used for anything and everything.

Go is a nice fit for e.g. a C programmer looking to write something they might have written in C (and don't want to write in a dynamic language for performance or functionality reasons.) It is a "modern" C--that is to say it is very close and familiar to C whilst as high-level (or close to) as many dynamic languages. By virtue of being a "modern C", it is also "C++ as it should have been" (at least in the eyes of the people who designed the language, and me personally. Interfaces also come more naturally for me, a C programmer, than do the popular OO constructs, but hey, that's me.) Look at the syntax, the constructs, the performance, the people behind the language and their motivations, and the people who use the language. I don't see how this is "trying to start a cult", talking "utter nonsense", or "being misleading." If you can't bear hearing somebody say that they prefer Go over X, why are you on this mailing list? It seems like you are just arguing for arguing's sake.

Do you really expect all statements made on this mailing list to be entirely objective and empirical, and, if so, what makes you think people are able, have the time, or care enough about being that thorough when it's about contributing to what has devolved into "no, I like the red ice cream better!" (and which ultimately isn't going to affect the mindset of people who are actually using Go to write programs), much less if you don't do so yourself?

It's worth considering whether you should use Go for new applications since you get a lot of the benefits of C along with the expressiveness traditionally reserved to dynamic languages. That is my opinion, and many Go programmers share it. Deal with it.

--
 
 

[David Symonds]

On Tue, Dec 4, 2012 at 2:44 PM, Thomas Bushnell, BSG
<tbus...@google.com> wrote:

> Can you say exactly what about Go (the language, not one implementation or
> one set of standard libraries) makes it unsuitable for embedded systems? Be
> sure to distinguish from other languages used in such systems that share the
> same features.

int and uint are defined to be either 32 or 64 bits
(http://golang.org/ref/spec#Numeric_types), and are the types used for
a bunch of builtins; if your embedded system is 8 bit or 16 bit then
arranging for such fundamental types to work correctly could be quite
inefficient; doable, but perhaps bad enough to label it as
"unsuitable".


Dave.

[Thomas Bushnell, BSG]

That's a nice example. Scheme avoids this by having very light numeric requirements, but go's type system doesn't really allow for that.

But...

Suppose you use int16 and byte for your own variables. The compiler is not required to use 32 bits to hold the return value of len if it has enough information to avoid it. So then it's annoying to use because you have to cast everything to smaller types all the time.

But now notice that nothing actually requires 4 bytes to hold an int. As long as the arithmetic does the right thing, it can use a smaller cell. So I think a clever compiler could make it convenient. But I agree that it's a stretch.

[Robert Johnstone]

Please, the original post that started this tangent was "Go is a better C than C," which essentially implies you should always use Go than C, was the reason I made my first post in this thread. Many of the responses have essentially rested on the assumption that Go is always the better choice.  Nobody used those exact words, but many people have certainly been arguing that point.

Further, while we won't always have entirely objective and empirical data, that does not mean we should accept unsubstantiated points either.  You've engaged in a false dichotomy.

And to re-emphases a point I've made several times, I like Go.  I use Go.  I just don't think that Go is the one language to rule them all.

[Patrick Mylund Nielsen]

You're jumping to conclusions. Nobody said that you always should use Go, or that Go is better than C (at everything), as far as I can tell.

> I just don't think that Go is the one language to rule them all.

I don't either. In fact, I use Go for ~30% of my new projects, but the remainder are not things that I would have considered writing in C.

--
 
 

[distributed]

Can you say exactly what about Go (the language, not one implementation or one set of standard libraries) makes it unsuitable for embedded systems? Be sure to distinguish from other languages used in such systems that share the same features.

 

IIRC, a large portion of the executable size of a Go program is used for type information which might be used at runtime. This information is in part responsible for making the Go type system as handy as it is. I don't know how much this runtime type information can be reduced or compressed. If it can't be reduced, Go executables will probably always clock in with several hundreds of kilobytes or even megabytes in size.

Depending on your definition of "embedded system", this might not be workable. The executable might be larger than your memory or it might even be larger than your address space. For example, the dsPIC processor mentioned above, has an address space of 64 kbytes for RAM. Instructions reside within a different address space, this might pose implementation difficulties. At my day job I'm working with a system containing a Coldfire processor with 64 megabytes of external RAM. On such a platform I imagine that Go might be workable.

As it has been noted before, even when you manage to get go running on a small embedded processor, performance might be not acceptable.

[Kevin Gillette]

On Monday, December 3, 2012 10:16:16 AM UTC-7, Robert Johnstone wrote:

Go is an excellent language, but positioning matters.  On my first approach at using Go, I walked away in disgust because it was such an inappropriate choice for my projects written using C.  I've since come back Go, and it has been an excellent choice for some other projects.  But, for my two cents, if someone finds Go killer for applications that they were writing in C, they probably should not have been using C in the first place.

I think you overestimate both the average "competency" of software "engineers" (in general) and the degree to which a language or implementation's merits affect decisions of when and where to use it.

With one primary exception, portability, I've found that either incompetency or a lack of familiarity with multiple languages in the same use-case category couple quite well with language popularity. People choose or are made to learn what is popular (either from on-the-job training or in academia). C++ and Java have had a stranglehold on higher education for a long time. For a great many tasks, C is a much saner C++, and some competent programmers who first learned C++ gravitate towards C (or a very small subset of C++) for many projects, and leave it at that (no real inclination to explore alternate languages). PHP is very popular among self-taught programmers, because it's ubiquitous, despite possessing little or no merit relative to other languages. Collaboration also has a large impact on this: I've worked on many programming teams where the "weakest link" programmer's sole language implicitly becomes the defacto language for all projects in that team, especially when code quality is deemed a non-concern in light of the need for raw coding throughput (again, this is common where PHP is involved).

I agree with the underlying notion of Patrick's assessment: most FOSS packages written in C could have been better served in some other language, particularly where none of C's merits are useful (low level coupling with syscalls, performance) except for portability, and where C's deficits become major drawbacks (complex logic [no real 'clean algorithms'] with much potential for memory leaks and security exploits).