I need commitment before I can use Go

[urd...@gmail.com]

Hi,

Go seems to be an interesting (probably better) programming language but I am wary to use it.
Choosing a programing language is not only a technical decision. If I am to invest a lot time building something with this technology, I want to be reasonably sure that my program will continue to work N years down the road.

C and C++ are time proven alternative.Go has everything to prove.
Even if it does not seem likely right now, I fear that Go will be killed in a few years by Google like many other projects and it will slowly disappear. I understand that the license is permissive and that anyone could continue the work but it does not feel very realistic to me: maintaining many libraries and compilers is a lot of work.

So what do I need to start considering Go? I need commitments by Google but potentially by others too. I need to see that without Go, your company stops. I need to know that Go is crucial to your success. Only if it is, I can expect you to keep working on it, improve it, refine it year after year. Java is crucial to Oracle. Without it, most of their software is gone. They have a clear incentive to improve Java. As I said before, C is time proven and so many software are written in it that I cannot imagine that it can disappear one day.

So I have said it, I would lie to use Go but I will not until I see strong commitments behind it.

Keep up the good work.

[Jan Mercl]

On Saturday, March 31, 2012 11:34:41 AM UTC+2, urd...@gmail.com wrote:

Just one example: Did you know that on average 10+% of the global internet traffic at any given moment is backed by Go?

http://code.google.com/p/vitess/

[Zippoxer]

I guess PHP backs more, but disappoints more; I'll be surprised if any Go backed website will ever switch (language) due to slow performance.

[Uriel]

Given the organizations that have already bet their business on Go,
and given that go has over 200-non-Google contributors I think Go's
future is safe no matter what Google does. See

http://go-lang.cat-v.org/organizations-using-go

Also I can't imagine Google stopping their contributions to Go when
they are using it internally to build their own infrastructure.

Uriel

[Devon H. O'Dell]

Op 31 maart 2012 09:29 heeft Zippoxer <zipp...@gmail.com> het
volgende geschreven:

> I guess PHP backs more, but disappoints more; I'll be surprised if any Go
> backed website will ever switch (language) due to slow performance.

In this case it would be nice to know what the value of N is for N
years. PHP certainly hasn't been the pinnacle of language stability
(or API stability, or API consistency) given a 10 year window. Even in
the early 2000s, there was this year in which everything to do with
handling HTTP form data changed two or three times (superglobals,
auto-registration, etc). Most of these things happened between PHP 4.1
and 4.2, if I recall correctly (it's been over a decade :S). And it's
worth it to note that these were huge changes from programmer
perspectives because they required people to update TONS of code --
and changing the 'auto_register' configuration default isn't even a
language change.

Regardless, at this point it's not fair to even compare Go to this:
the language still hasn't changed *that* much from what we were all
playing around with in 2009, and even given its changes, it's as old
as PHP was in 2000 / 2001 (PHP 2 came out in 1997 as not just a set of
Perl scripts). When Go 4 (haha, gopher) comes out, the team has such a
good track record of style and interface consistency, I'd be surprised
if we'd see the kind of drastic changes that were responsible for
authors and publishers to update books twice in a year.

--dho

[Ugorji Nwoke]

See https://plus.google.com/116810148281701144465/posts/ExP5BeXUujn

"We've understood from the initial launch that Go needed to be more than just Google's language. The front page of golang.org has never mentioned Google and carries none of the Google logo or branding, and that is not accidental."

Key Points:

- Open Source Language. Sponsored by Google. Used by a lot of people within and outside google. 

So it's no way like Java was to SUN/Oracle or even Android is to Google. It's an open-source language that Google sponsored and invested in and paid some heavyweight experts to build.

Beyond that, no one can give you guarantees but you just have to look at history. If a language is in use, and people depend on it, it stays and grows. This language is in use in a lot of places, is one of the 3 official languages for building applications to run on Google's App Engine (along with Python and Java), and is one of the finite set of languages for writing backend software within Google (along with C++ and Java).

I think it will be around for a while.

[Liigo Zhuang]

No one can do it currently, IMO.

[Amitabh Arya]

I do agree with the post owner, we need commitment before using Go in any of our big project. I am the technical manager in a company and my commitment are big words for the company, they invest their money on it. So it's a big responsibility, me to pick a language.

But that's also true if we will not give time to grow to Go and will not use Go in our current projects then surely Go will not have a future and we will loose a really good language.

We should not compare Go with php as php has nothing to be a valid competitor. Go is a programming language which can build php, servers, OS and all and all. And I hope it will be like this only. I hope that later we will not drag Go only for web apps or web development, let go be a good competitor of C.

But now what should we do.....?

On this post People are saying, Go is used by inside and outside of google and there are about 20 companies are using Go. That does not help us to proove Go future is good to our companies. What do we need then, we need list of projects I guess.

A wikipedia page that will say something like google use Go language in their latest projects as google plus or something.

A list of other paid projects developed or developing by other tons of companies for current and future market in Go, surely at Wikipedia.

We don't want only google will invest in Go open source project. We should not forget that google is now a big commercial company. They didn't take time to close the google translation APIs project. And now google, apple and Microsoft are competitors. So what if tomorrow Apple Or Microsoft stop running/supporting Go applications.

So we want some other big companies also invest their resources for Go open source project.

Don't take this post as nagetive, I don't want to loose Go and trying to help for it's and our better future.

[Thomas Bushnell, BSG]

Use it or don't use it. What are you looking for here?

[Thomas Bushnell, BSG]

In my opinion, an engineering team should depend on no tool which they are not capable of taking over maintenance of if the need should arise.

There is no difference here between C and Go.

Use the best tool for the job. Hire people who know how to build and fix tools. Go is a great tool.

Thomas

[Thomas Bushnell, BSG]

Why is a technical manager picking languages, he asks himself sadly.

On Mar 31, 2012 9:08 AM, "Amitabh Arya" <amitab...@gmail.com> wrote:

[Michael Jones]

This is a question where you bring your own answer.

Many people have been using Go. Some to play, some to work, some who missed being at Bell Labs for C and refuse to miss their chance at a memorable effort of the same nature, some who bet their companies and some who are just watching to make sure they see what is happening.

Others have been waiting for Go the child to grow up and leave the nest. For them, the last few days have been the graduation party they've been waiting for. Just like companies waiting years until Gmail was out of beta, these people feel that Go is now worthy of their investment. It is certainly richer and more refined than at any point in its last few years, plus, the standardization around the grammar and library APIs, the tool suite, and so on mean that learning and training will not be wasted.

No doubt there are also people who see Go 1 as the "initial baby step" rather than the adolescent flight from the nest. Unmoved or at least unconvinced by recent year's work by hundreds of developers and contributors, their wait for legitimacy is just now starting. If you are in this group, and certainly if you want assurances of C/C++ levels of adoption across businesses around the world then you will need to wait. Just as you woud for a mighty oak to grow from acorn, or Go 1's sapling.

Michael Jones

--

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

[Scott Lawrence]

Both, I think.

At some point, you have to pick a few underlying technologies, and make the
hopeful assumption that said technologies will continue to function on the
systems you're targetting. Even if you /could/, hypothetically, pick up
maintenance on your own (which most development teams simply can't), it's an
enormous expenditure of resources which might be better spent elsewhere. So
whether or not a language is likely to be abandoned can be a significant
portion of the expected cost of adoption.

On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:

> Are we concerned about scale or ability? My answer to your question depends
> on that.
> On Mar 31, 2012 9:46 AM, "Scott Lawrence" <byt...@gmail.com> wrote:

>
>> On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:
>>
>> In my opinion, an engineering team should depend on no tool which they are
>>> not capable of taking over maintenance of if the need should arise.
>>>
>>

>> That's a rather impossible standard, isn't it? How many web startups do
>> you think are capable of taking over maintenance of Linux/*BSD?
>>
>> The probability of abandonment is definitely a relevant factor.
>>
>> --
>> Scott Lawrence
>>
>> go version weekly.2012-03-27 +98fc21971a1d
>> Linux jagadai 3.2.12-1-ARCH #1 SMP PREEMPT Mon Mar 19 17:50:01 CET 2012
>> x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux
>>
>

--
Scott Lawrence

[Thomas Bushnell, BSG]

On Sat, Mar 31, 2012 at 9:46 AM, Scott Lawrence <byt...@gmail.com> wrote:

On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:

In my opinion, an engineering team should depend on no tool which they are
not capable of taking over maintenance of if the need should arise.

That's a rather impossible standard, isn't it? How many web startups do you think are capable of taking over maintenance of Linux/*BSD?

The probability of abandonment is definitely a relevant factor.

Are we speaking of scale or ability?

If scale (we have the ability to do X, but not the time), then this is simply one more business risk. But to worry about abandonment of the technology when you're a web startup is rather a weird attitude towards business risk, and is amazingly penny wise and pound foolish. The odds are extremely high that the startup will have failed with in five years, so the horizon to look for isn't that long.

If ability, then I stand by my statement exactly as written. I understand this is quite radical, and not the way most people think; most people hear it and then ignore it. But I mean it. You need to be able to fix your tools, or you shouldn't be using them. Or, as I once put it, "if you have no idea how to write a compiler, you have no business using one."

Thomas

 

[Scott Lawrence]

On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:

> Are we speaking of scale or ability?
>
> If scale (we have the ability to do X, but not the time), then this is
> simply one more business risk. But to worry about abandonment of the
> technology when you're a web startup is rather a weird attitude towards
> business risk, and is amazingly penny wise and pound foolish. The odds are
> extremely high that the startup will have failed with in five years, so the
> horizon to look for isn't that long.

I think we're talking more about a mid-sized software factory beginning work
on a new product. Go's abandonment isn't likely to destroy the company, but it
would impose a significant added cost, either in maintenance of an extra 100k+
SLoC, or in a complete rewrite.

>
> If ability, then I stand by my statement exactly as written. I understand
> this is quite radical, and not the way most people think; most people hear
> it and then ignore it. But I mean it. You need to be able to fix your
> tools, or you shouldn't be using them. Or, as I once put it, "if you have
> no idea how to write a compiler, you have no business using one."

I'm not sure I'd go that far, but I certainly agree with the sentiment.

[Amitabh Arya]

Because Company trust my words friend :)

[Ugorji Nwoke]

That's fair.

A page on golang.org that lists companies using Go, how they're using Go and other large projects built on Go should satisfy this, beyond everything else we've said.

Currently, they're spread around the place:

- StatHat: http://blog.golang.org/2011/12/building-stathat-with-go.html

- Heroku: http://blog.golang.org/2011/04/go-at-heroku.html

- Youtube: http://code.google.com/p/vitess/

- Other companies: http://go-lang.cat-v.org/organizations-using-go

I know Andrew is said to have some publicizing ideas up his sleeve. I suppose this will be part of it in time.

[John Asmuth]

On Saturday, March 31, 2012 12:53:39 PM UTC-4, Thomas Bushnell, BSG wrote:

Or, as I once put it, "if you have no idea how to write a compiler, you have no business using one."

Seems like something would say to prove that your assertion about being able to fix your tools doesn't make sense...

[Thomas Bushnell, BSG]

On Sat, Mar 31, 2012 at 9:57 AM, Scott Lawrence <byt...@gmail.com> wrote:

On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:

Are we speaking of scale or ability?

If scale (we have the ability to do X, but not the time), then this is
simply one more business risk. But to worry about abandonment of the
technology when you're a web startup is rather a weird attitude towards
business risk, and is amazingly penny wise and pound foolish. The odds are
extremely high that the startup will have failed with in five years, so the
horizon to look for isn't that long.

I think we're talking more about a mid-sized software factory beginning work on a new product. Go's abandonment isn't likely to destroy the company, but it would impose a significant added cost, either in maintenance of an extra 100k+ SLoC, or in a complete rewrite.

This is similar to a latency addition, I think. If the front end depends on ten backends, and each has great average latency, but occasional bad latency, then the average latency of the front-end (which is essentially a max or sum of the backends in each case, generally) will be punitively effected by the variance in the latency of the backends.

For example, in a simply case, if you have a hundred back ends, and each has a 1% chance of 1sec latency, but otherwise hits a target of 10msec latency, and you can run them in parallel so that the front end transaction is a max of the backends...then each backend has a average of 19msecs latency, but the total has a 74% chance that one of the backends will be slow, for an average of a whopping 743msec average latency.

You should assume that at least one of your tools will become unmaintained given any interesting length of time, because, while each tool might have a small chance of vanishing on you, it's virtually certain that one of them will. You should plan on that at the beginning.

If ability, then I stand by my statement exactly as written. I understand
this is quite radical, and not the way most people think; most people hear
it and then ignore it. But I mean it. You need to be able to fix your
tools, or you shouldn't be using them. Or, as I once put it, "if you have
no idea how to write a compiler, you have no business using one."

I'm not sure I'd go that far, but I certainly agree with the sentiment.

And for the above reason, if you know that you're going to have to maintain some of your tools eventually, but you can't predict which ones, you should be very sure to hire people who can do it.

Thomas

 

[Amitabh Arya]

As I wrote earlier don't take it nagetive :). I do agree that Go is a good language no doubt. I am myself trying to build a web server in Go.

I have seen all the statement, people are saying companies are Doing this and that in Go. We just want a proof of that, some web page saying that on some good recognized website. That's it.

[Scott Lawrence]

I think there's an implicit "in real life / production code" qualifier. In
which case the assertion makes significantly more sense, and I actually agree
with it.

That's not to say you'd have to actually be able to write a compiler from
scratch, in a week, on a whim. But I definitely want to avoid software written
by people who lack a fundamental understanding of how the systems underlying
their code work.

[Scott Lawrence]

On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:

> On Sat, Mar 31, 2012 at 9:57 AM, Scott Lawrence <byt...@gmail.com> wrote:
>
>> On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:
>>
>> Are we speaking of scale or ability?
>>>
>>> If scale (we have the ability to do X, but not the time), then this is
>>> simply one more business risk. But to worry about abandonment of the
>>> technology when you're a web startup is rather a weird attitude towards
>>> business risk, and is amazingly penny wise and pound foolish. The odds are
>>> extremely high that the startup will have failed with in five years, so
>>> the
>>> horizon to look for isn't that long.
>>>
>>
>> I think we're talking more about a mid-sized software factory beginning
>> work on a new product. Go's abandonment isn't likely to destroy the
>> company, but it would impose a significant added cost, either in
>> maintenance of an extra 100k+ SLoC, or in a complete rewrite.
>>
>> This is similar to a latency addition, I think. If the front end depends
> on ten backends, and each has great average latency, but occasional bad
> latency, then the average latency of the front-end (which is essentially a
> max or sum of the backends in each case, generally) will be punitively

> effected by the *variance *in the latency of the backends.

>
> For example, in a simply case, if you have a hundred back ends, and each
> has a 1% chance of 1sec latency, but otherwise hits a target of 10msec
> latency, and you can run them in parallel so that the front end transaction
> is a max of the backends...then each backend has a average of 19msecs
> latency, but the total has a 74% chance that one of the backends will be
> slow, for an average of a whopping 743msec average latency.

It's a little more complicated, because it's always possible that someone else
will pick up the maintenance burden. Hence the OP's question of "who else
depends on it?". If 10 other folks who can more easily take over have strong
dependencies on the language, then you're much safer.

If each of 20 underlying technologies has a 0.01% chance of absolute
abandonment, you're pretty safe.

> You should assume that at least one of your tools will become unmaintained
> given any interesting length of time, because, while each tool might have a
> small chance of vanishing on you, it's virtually certain that one of them
> will. You should plan on that at the beginning.
>
> If ability, then I stand by my statement exactly as written. I understand
>>> this is quite radical, and not the way most people think; most people hear
>>> it and then ignore it. But I mean it. You need to be able to fix your
>>> tools, or you shouldn't be using them. Or, as I once put it, "if you have
>>> no idea how to write a compiler, you have no business using one."
>>>
>>
>> I'm not sure I'd go that far, but I certainly agree with the sentiment.
>
>
> And for the above reason, if you know that you're going to have to maintain
> some of your tools eventually, but you can't predict which ones, you should
> be very sure to hire people who can do it.
>
> Thomas
>

--

[Stefan Nilsson]

This thread wouldn't be complete without a link to the Go 1 compatibility document: http://golang.org/doc/go1compat.html.

For what it's worth, it makes a precise statement of the what to expect from Go in the future.

[John Asmuth]

(moving this back on-list)

On Sat, Mar 31, 2012 at 1:19 PM, Thomas Bushnell, BSG <tbus...@google.com> wrote:

On Sat, Mar 31, 2012 at 10:16 AM, John Asmuth <jas...@gmail.com> wrote:

I was worried that it was a bit confusing, sorry.

starting with the assumption that "if you don't know how to maintain the tool, you shouldn't use it", the logical conclusion is "if you have no idea how to write a compiler, you have no business using one."

My implication is that "if you have no idea how to write a compiler, you have no business using one" is far too hard of a constraint, and is not a practical rule to live by if you want to get things done on a large scale.

As I said, it seems crazy, and people will reject it out of hand.

But you're quite wrong.

Knowing how to write a compiler, and actually doing so every time you use one are two totally different things. I do not advocate the latter. 

I understood that you meant that.

Only fairly recently, when I took a class on compilers in grad school, did I fully make the connection between code text and a binary executable. However, before that point I considered myself a fairly good programmer, with lots of examples to prove it.

Of course, it's easy for someone to say, "you just weren't as good as you thought you were", but I wouldn't find that particular argument convincing.

In grad school, my field is machine learning. Most of my colleagues know very little about the internals of compilers, but they can still do amazing things with code. A lot of them use matlab, and are completely ignorant about the best ways to do SVD decomposition, yet they still use it as a primitive operation in their algorithms.

Computer science is *far* too broad a field to know everything. And if you're in a subfield  that only relates to compilers in that it uses code to get things done, the practical advantages of knowing exactly how compilers work is pretty negligible. What does a 5% speed or memory efficiency boost buy you when you're focusing on turning O(n^2 lg n) into O(n lg n)?

[Thomas Bushnell, BSG]

I have no opinion about whether academic CS programs are teaching good software engineering or not. I'm speaking about the latter, and not about the former.

However, my own graduate degree is in philosophy. I would be appalled if someone said they were great at Hegel, but didn't have a very good understanding of Plato, and because their own field was epistemology, didn't know much about logic. There was one professor in my department, hired almost as I was finishing, who was that sort of person, and found it very hard to get graduate students, or really, much respect at all except for the fans of the one teeny area in which they worked.

Don't think I'm a fan in general, but when Heinlein said that specialization was for insects, I think he was right.

[John Asmuth]

On Saturday, March 31, 2012 1:42:09 PM UTC-4, Thomas Bushnell, BSG wrote:

I have no opinion about whether academic CS programs are teaching good software engineering or not. I'm speaking about the latter, and not about the former.

So, the distinction is between software that works and software that works the way you like it to? 

[Rémy Oudompheng]

Le 31 mars 2012 19:07, Amitabh Arya <amitab...@gmail.com> a écrit :
> As I wrote earlier don't take it nagetive :). I do agree that Go is a good language no doubt. I am myself trying to build a web server in Go.
>
> I have seen all the statement, people are saying companies are Doing this and that in Go. We  just want a proof of that, some web page saying that on some good recognized website.  That's it.
>

The question is more about whether you, and/or your people, can write
Foo in the language Bar. Some companies are writing search engines in
Common Lisp. Others are doing financial applications in Ocaml. People
are writing web servers in C, databases in C++ or in Erlang. Most
often, quite successful ones.

And the proof of these facts is widely known and recognized. But
that's not why I would choose a programming language. An abandoned
language is not necessarily what costs you maintenance. C is far from
being abandoned, yet maintaining a software framework in C can eat you
years of work.

For me the best proof a language can be used by me to build things is
if I could indeed build things with it.

Regards,
Rémy.

[Thomas Bushnell, BSG]

I have interviewed PhD candidates in CS who come from no-slouch universities, but who really could not program their way out of a web paper bag. That doesn't mean they shouldn't get a degree, because CS degrees are about something different that software engineering. One floundered for forty-five minutes failing to write a working binary search function in an array, and at the end, asked me if we really use algorithms, since they were all already written.

I have adopted the casual language to distinguish between the programs taught in universities, which are usually labelled "computer science", and the practice in industry, which is generally to call people "software engineers". I don't care about finding some rigid definitional distinction between the two, beyond saying that computer science is what universities teach in departments of computer science, and software engineering is what companies like mine prize in hiring...and the observation that being good in one--even excellent--does not make you good in the other (in both directions).

So, the observation that you can be excellent in the academic field of computer science with the kind of specialization that you described, is neither here nor there to me. I find it surprising, but having not been a CS graduate student, I'll simply say that in my own graduate field it wouldn't fly. But in software engineering, I think it's a recipe for disaster to regard understanding compilers as the same kind of thing as understanding machine learning.

At the current state of the art, everyone is using a compiler (and should understand it). The people using machine learning engines should also understand them. But while in academia there is an easy symmetry: they are both fields, worthy of study, and that's that; in engineering there is not: the person using the machine learning engine is also using a compiler, but (generally speaking) not vice versa.

Thomas

[Devon H. O'Dell]

Op 31 maart 2012 13:55 heeft John Asmuth <jas...@gmail.com> het
volgende geschreven:

I don't get it. It's exactly like saying you don't have any business
using a computer if you're not an atomic physicist. If you follow this
"you shouldn't use a compiler unless you can write it" argument
logically, you must first invent the universe to write code. You have
to know how to write the compiler. But you have no business writing a
compiler for your language if you can't bootstrap one for any
language. And really, you shouldn't write in machine language unless
you know how to make an ALU. And you shouldn't make an ALU unless you
really understand atomic particle physics. Ad effing nauseum until you
invent the universe, assuming the existence of the universe is just a
quantum event.

Most people don't learn to write compilers, and even people who don't
do anything CS related for a living write things that are at least
compiled to bytecode, whether it's machine-interpreted or not (Excel
macros are a good example). So knowing how to write a compiler should
by no means be considered a barrier to using a compiler. Disclaimer:
I'm sure I could write a compiler in a pinch, but it wouldn't be
great. I certainly couldn't maintain gcc if every developer using it
dropped dead tomorrow.

This is also terribly off-topic. There are hundreds of non-Google
contributors, including myself, who will continue to work on the
compilers, runtime, and APIs even if Google decides to ditch Go (which
I would think would require their bankruptcy). If you can't support
the compilers, that is by no means a reason to not use go, and I'm
really surprised to see someone at Google arguing that it should be
(even ignoring the intentional lack of Google branding on golang.org
and such).

So to get back on topic: just use it, or don't. Nobody is going to
give you a warranty. The license expressly disclaims any guarantee of
fitness; you will get no such commitment from any engineer that Go is
100% going to exist and be supported forever. If you need that
guarantee, you need to spend money (and hope the vendor doesn't flush
it down the toilet).

--dho

[Thomas Bushnell, BSG]

On Sat, Mar 31, 2012 at 11:20 AM, Devon H. O'Dell <devon...@gmail.com> wrote:

I don't get it. It's exactly like saying you don't have any business
using a computer if you're not an atomic physicist. If you follow this
"you shouldn't use a compiler unless you can write it" argument
logically, you must first invent the universe to write code. You have
to know how to write the compiler. But you have no business writing a
compiler for your language if you can't bootstrap one for any
language. And really, you shouldn't write in machine language unless
you know how to make an ALU. And you shouldn't make an ALU unless you
really understand atomic particle physics. Ad effing nauseum until you
invent the universe, assuming the existence of the universe is just a
quantum event.

Actually, at MIT, computer science is taught in the department of electrical engineering and computer science, and graduates are expected to understand these things.

I know it's shocking.

Thomas

[Zippoxer]

I hope you just exaggerated in "if you have no idea how to write a compiler, you have no business using one", otherwise it's stupid.

Assume a person who knows python and nothing else, and writes web programs to earn few bucks in his free time. He's satisfied with his knowledge and never happened to encounter a bug in any of his tools. If he will, he knows he can always ask experts. That's as far as he is ready to go with programming, writing compilers is out of question. Is he really wrong?

[Thomas Bushnell, BSG]

On Sat, Mar 31, 2012 at 1:36 PM, Zippoxer <zipp...@gmail.com> wrote:

I hope you just exaggerated in "if you have no idea how to write a compiler, you have no business using one", otherwise it's stupid.

Assume a person who knows python and nothing else, and writes web programs to earn few bucks in his free time. He's satisfied with his knowledge and never happened to encounter a bug in any of his tools. If he will, he knows he can always ask experts. That's as far as he is ready to go with programming, writing compilers is out of question. Is he really wrong?

No, he's not wrong; I was being hyperbolic. Let me be more straightforward.

Tho original question was not about a person who uses python in their free time for a few bucks. That's an apprentice, and as log as his customers know he's an apprentice, I have no desire to recreate the guild system under which it would be illegal for him to work this way.

But if one is choosing a language for a significant project, it's important to study the available compilers and choose what's right for your case. Consider the recent question here which was, I believe, asking about the memory behavior of Go's maps. I myself had a similar question when I started playing around with Go. So I went and looked at the implementation of hashtables in the runtime library for Go. While I was sad that there seem to be no comments and all the variable names are one or two letters long, it didn't take long to identify the algorithms used and understand the code. (And, I'd add, the code is quite clear even though it seems to eschew documentation.)

When I was choosing Chicken Scheme for a project, I spent plenty of time learning how the compiler worked, because it matters. How could you choose between the two available go compilers without some ability to work with them in this way?

Remember, the question was about choosing which tool to use. And my point is that you cannot choose which tool to use without deeply understanding the tools.

These are basic tasks. And whatever your project is, your tools are essential, and to execute the project well is to understand the tool. An apprentice is still learning, and I have no intention of insulting apprenticeship and play and experimentation and hobbycraft and all the rest. These are things that make life worth living.

But if you're in business, I would urge hiring master craftsmen in addition to your apprentices, and a master craftsman knows the tools at this level.

[Scott Lawrence]

On Sat, 31 Mar 2012, Zippoxer wrote:

> I hope you just exaggerated in "if you have no idea how to write a
> compiler, you have no business using one", otherwise it's stupid.
>
> Assume a person who knows python and nothing else, and writes web programs
> to earn few bucks in his free time. He's satisfied with his knowledge and
> never happened to encounter a bug in any of his tools. If he will, he knows
> he can always ask experts. That's as far as he is ready to go with
> programming, writing compilers is out of question. Is he really wrong?

I assume he likewise lacks an understanding of the HTTP/TCP/IP stack? How
HTTPS works? XSRF? What sorts of security precautions he ought to take? I
don't want to go anywhere near what he produces.

(Also, I highly doubt that any reasonably experienced programmer lacks any
clue of how to write an interpreter.)

[Kyle Lemons]

There are no absolutes in life, and in the real world guarantees don't mean as much as contracts.

That being said, the 200+ non-Google contributors have already been mentioned, but there are also non-Google committers (people who have access to add code to the official Go repository).  So, if a magic school bus kidnapped the Go team next week or if Google loaded its employees onto a spacecraft and set out for Mars, Go development could (and, I suspect, would) continue.  The presence of Go 1 itself is, to me, a commitment to Go being around for the long term (see, for example, the Go 1 Compatibility document), because it has the express intent of being a stable foundation on which Go programs can be written and which will continue to work "over the lifetime of that specification."  This could, of course, end up being a week or it could end up being a decade (I don't think the Go team has made any explicit statements) but I feel pretty confident that the community as it stands today is dedicated to making Go 1 last O(years).

On Sat, Mar 31, 2012 at 9:08 AM, Amitabh Arya <amitab...@gmail.com> wrote:

I do agree with the post owner, we need commitment before using Go in any of our big project. I am the technical manager in a company and my commitment are big words for the company, they invest their money on it.  So it's a big responsibility, me to pick a language.

But that's also true if we will not give time to grow to Go and will not use Go in our current projects then surely Go will not have a future and we will loose a really good language.

We should not compare Go with php as php has nothing to be a valid competitor. Go is a programming language which can build php, servers, OS and all and all. And I hope it will be like this only. I hope that later we will not drag Go only for web apps or web development, let go be a good competitor of C.

But now what should we do.....?

On this post People are saying, Go is used by inside and outside of google and there are about 20 companies are using Go. That does not help us to proove Go future is good to our companies. What do we need then, we need list of projects I guess.

A wikipedia page that will say something like google use Go language in their latest projects as google plus or something.

Surely that little site that a few people use for the purpose of watching cat videos (powered partly by Go) counts for something...

 

A list of other paid projects developed or developing by other tons of companies for current and future market in Go, surely at Wikipedia.

Ah, Wikipedia, the standard repository of all knowledge.  I'd only trust such a page if there were citations for all of the companies listed.

[Dmitry Chestnykh]

On Saturday, March 31, 2012 11:34:41 AM UTC+2, urd...@gmail.com wrote:

C and C++ are time proven alternative.

 

Didn't Bell Labs discontinued their development?

[Paul Borman]

I think it is good to ask questions, and research answers, about any new technology you are about to use.  I did precisely this when selecting the language for a re-write of a project that had been in Python.  It took me several months to determine that Go was suitable.  I considered several factors, including

• Is the language up to the task?
• What will the costs be in terms of implementation and support be?
• Will I be able find/train engineers to us Go?
• How well integrated is it with our internal build infrastructure?
• Am I tied by libraries to another language?
• How much language flux will I have to deal with (having lived through the C++ changes of the mid 90's this was a big concern of mine)?
• Can I get buy-in from my management?

Some of these were easy to answer, others took more work, but I think they all needed to be asked.  As you might guess, all of these were answered to my satisfaction and we were on the Go.  I think it has already been mentioned that Go is one of the 4 canonical languages at Google (C++, Go, Java and Python).

It has been about a year now and I think Go really makes sense in many places where people have used C, C++, Python or Java for "systems programing".  The worst case scenario is that the proverbial bus accident happens during the mythical field trip for the Go team and all of the Go contributors (or some other highly unlikely thing happens that makes it impossible to continue with Go).  I still think starting with Go would be a win.  Go is fast to implement in (i.e., a prototyping language), has, in my opinion, lower maintenance costs than C, C++ or Python (I can't speak to Java), and has sufficient performance to be a production language.  I believe my project is farther along and probably better designed by my starting in Go even if some catastrophic event made me re-implement later.  Sure there would be a hit, but I would have taken the hit by not using Go in the first place, and I am betting I will never have to take the hit.

In terms of my third bullet point, I have been very pleased that all members of my team have been able to pick up Go rather quickly.  Nearby projects are now also considering using Go for new efforts.

I am not trying to say "take my word for it, just use Go" but want to give you words of encouragement to go through the process and realize others have and at least some of them have come back with a positive conclusion.  I would not hesitate to select Go again inside or outside of Google for any future project.

    -Paul

PS:  Google is a very large company with probably more projects that many of my previous companies had engineers.  I am only speaking from my personal experiences in my small little niche of a corner :-)

[Liigo Zhuang]

Priority in the use of time-tested, mature programming language, to reduce the risk of technical investments, to reduce maintenance costs. 

2012/4/1 Amitabh Arya <amitab...@gmail.com>

I do agree with the post owner, we need commitment before using Go in any of our big project. I am the technical manager in a company and my commitment are big words for the company, they invest their money on it.  So it's a big responsibility, me to pick a language.

But that's also true if we will not give time to grow to Go and will not use Go in our current projects then surely Go will not have a future and we will loose a really good language.

We should not compare Go with php as php has nothing to be a valid competitor. Go is a programming language which can build php, servers, OS and all and all. And I hope it will be like this only. I hope that later we will not drag Go only for web apps or web development, let go be a good competitor of C.

But now what should we do.....?

On this post People are saying, Go is used by inside and outside of google and there are about 20 companies are using Go. That does not help us to proove Go future is good to our companies. What do we need then, we need list of projects I guess.

A wikipedia page that will say something like google use Go language in their latest projects as google plus or something.

A list of other paid projects developed or developing by other tons of companies for current and future market in Go, surely at Wikipedia.

We don't want only google will invest in Go open source project. We should not forget that google is now a big commercial company. They didn't take time to close the google translation APIs project. And now google, apple and Microsoft are competitors. So what if tomorrow Apple Or Microsoft stop running/supporting Go applications.

So we want some other big companies also invest their resources for Go open source project.

Don't take this post as nagetive, I don't want to loose Go and trying to help for it's and our better future.

--
by Liigo, http://blog.csdn.net/liigo/

Google+  https://plus.google.com/105597640837742873343/

[Paul]

While I understand where you are coming from with the stated need for
comittment, based on my expierience in the IT Industry its not
actually how the game works.

You might be able to get that kind of a comittment from the sales
department of any of the well known big 5 software Vendors for some
given programming language, * if the price is right*. You will be
talking about big numbers like upwards of 17% maintenance fees
without anykind of real comittment as to the deliverables.

I don't even want to start on the Java story. All I can say is that
some bet their business on it, and now there is only FUD left. I
think there are likely some sorry C-Level decision makers on the
long end of Java.

Try this for a comittment test: File a bug for Java, with a Vendor
that you have been paying 22% maintenance fees to for the last 2-3
years and then see if and when you will get a fix (perhaps a
security bug...), see how fast they respond and how qualified they
will respond. Next try filing a request for a simple enhancement.

As far as the Go-language goes: the kind of comittment,
responsiveness and turnaround from the people working on this list is
hard to top by any measure.



On Mar 31, 11:34 am, urd...@gmail.com wrote:
> Hi,
>
> Go seems to be an interesting (probably better) programming language but I
> am wary to use it.
> Choosing a programing language is not *only* a technical decision. If I am
> to invest a lot time building something with this technology, I want to be
> reasonably sure that my program will continue to work N years down the
> road.
>
> C and C++ are time proven alternative.Go has everything to prove.
> Even if it does not seem likely right now, I fear that Go will be killed in
> a few years by Google like many other projects and it will slowly
> disappear. I understand that the license is permissive and that anyone
> could continue the work but it does not feel very realistic to me:
> maintaining many libraries and compilers is a lot of work.
>
> So what do I need to start considering Go? I need commitments by Google but
> potentially by others too. I need to see that without Go, your company
> stops. I need to know that Go is crucial to your success. Only if it is, I
> can expect you to keep working on it, improve it, refine it year after
> year. Java is crucial to Oracle. Without it, most of their software is
> gone. They have a clear incentive to improve Java. As I said before, C is
> time proven and so many software are written in it that I cannot imagine
> that it can disappear one day.
>
> So I have said it, I would lie to use Go but I will not until I see strong
> commitments behind it.
>
> Keep up the good work.

[André Moraes]

> I have seen all the statement, people are saying companies are Doing this and that in Go. We  just want a proof of that, some web page saying that on some good recognized website.  That's it.

The vitess client that scale MySQL for YouTube is written in Go and is
open-sourced. This is a "good recognized website"?

I agree that everybody that is writing something in Go need somebody
to trust that Go is viable.

Well, this will sound egocentric, but I just trust on myself. Every
other person/company/machine/etc... I hope that I am putting my eggs
on the right basket.

With that in mind, ask yourself these questions:

Can I take on the development of the Go lang if something really bad happens?

Do I trust that the guys at Google, the people on the AUTHORS files
and some of the guys that created the technology that I use and don't
even notice (Pike, Thompson, Griesemer)?

If the answer to any of those questions is true, then you can trust in Go.

--
André Moraes
http://andredevchannel.blogspot.com/

[Gustavo Niemeyer]

On Sat, Mar 31, 2012 at 06:34, <urd...@gmail.com> wrote:
> Choosing a programing language is not only a technical decision. If I am to

> invest a lot time building something with this technology, I want to be
> reasonably sure that my program will continue to work N years down the road.

As a minor but curious distraction in that wise perspective, have you
ever realized that we cannot tell for sure that we, as persons, will
be around N years down the road? I know it sounds a bit esoteric to
be pondering about that in this context, but I actually include that
fact when considering what I want to be doing for the next M (< N?)
years of my life.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.