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
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
"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."
No one can do it currently, IMO.
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.
Use it or don't use it. What are you looking for here?
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
Why is a technical manager picking languages, he asks himself sadly.
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
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.
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.
Or, as I once put it, "if you have no idea how to write a compiler, you have no business using one."
On Sat, 31 Mar 2012, Thomas Bushnell, BSG wrote:
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.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'm not sure I'd go that far, but I certainly agree with the sentiment.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 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.
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.
> 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
>
--
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 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.
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.
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
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.
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 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.)
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.
C and C++ are time proven alternative.
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.
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/
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.