We're close to issuing a Go 1 release candidate, and so I would like
to enlist your help in testing the binary distributions. We now
provide pre-built Go tool chains for FreeBSD, Linux, OS X, and
Windows. These break the installation dependencies on Mercurial and
GCC, making it much easier for users to get started with Go. Yay!
Please follow the installation instructions here:
http://weekly.golang.org/doc/install
The files are available here:
http://code.google.com/p/go/downloads/list
We want to make sure that new users have the best experience possible,
so please let us know if you have any issues with installation, the
documentation, or using the tools after installation.
Please leave feedback (both positive and negative) in the issue
tracker entry relevant to your operating system and architecture:
http://golang.org/issue/3210 darwin-386
http://golang.org/issue/3208 darwin-amd64
http://golang.org/issue/3212 freebsd-386
http://golang.org/issue/3213 freebsd-amd64
http://golang.org/issue/3209 linux-386
http://golang.org/issue/3211 linux-amd64
http://golang.org/issue/3214 windows-386
http://golang.org/issue/3215 windows-amd64
Make sure you tell us the version of the operating system you use.
Thanks for your help!
Andrew
It will be tagged as a weekly but we will publicise it as the release candidate.
Andrew
I hadn't planned on it, mainly because installing Mercurial isn't a
big hurdle to the kind of people that build from source.
Andrew
I think an official source tarball would also benefit to Gentoo or any
system which automates package building.
Then we would need to do checksumming in a different way, which could
potentially break people who are using security wrappers around ports
installs (that require correct checksums / check versions for CVE
vulnerabilities, etc). We'd have to have a checksum of every file.
We'd have to make mercurial a build dependency (which it really isn't
if you consider it's only needed to get source, not to build it). Once
mercurial is a dependency, suddenly the person needs python and a host
of other ports that nobody who uses go cares about (per se!) unless
they are developing go.
I'm not saying you should give us all these things (a weekly tarball +
checksum, or some similar alternative) to make the FreeBSD port easier
to maintain, but I am saying that it is not an invalid motivation.
There are nuanced situations that you aren't considering that make
doing this cleanly within the ports / package infrastructure
prohibitively difficult.
I would prefer to see FreeBSD 9.x, and 8.x releases of Go 1 in a
format that someone can pkg_add. There are no run dependencies, so
this shouldn't be a huge hassle, and I'm sure that either one of
Julien or I would be happy to help out with that. I'll add comments to
the tickets to the same effect.
--dho
Good points. Does this give you what you need?
http://code.google.com/p/go/downloads/detail?name=go.weekly.2012-03-04.src.tar.gz
The SHA1 sum is on that page.
> I would prefer to see FreeBSD 9.x, and 8.x releases of Go 1 in a
> format that someone can pkg_add. There are no run dependencies, so
> this shouldn't be a huge hassle, and I'm sure that either one of
> Julien or I would be happy to help out with that. I'll add comments to
> the tickets to the same effect.
Thanks!
Andrew
I think so -- Julien, does that make your life easier? :)
--dho
Some more FreeBSD comments...A lot of people using FreeBSD are __VERY__ concerned about stability. I use FreeBSD extensively for servers (no GUI) and decided to NOT use go there until it achieves at least the stability of a GO-1 release. It's bad enough chasing weekly changes in one OS at a time as I prefer Ubuntu for desktop use. Once GO-1 is released I plan to immediately start using it on FreeBSD. But not until. SO I guess I'm saying that your relying on counting downloads of binary distributions might be completely off as an indicator of "Interest in Go" from the FreeBSD community.On the other hand, I prefer to stay with the package/port paradigm where I can (using the FreeBSD port mechanism) inspect and / or compile the code being run on my system before actually deploying it. Making that harder to do is "not a good thing". So to be clear, I'd agree that a binary port of go to FreeBSD could be back-burner, but please don't drop FreeBSD from the source distribution.
Whomever said this originally doesn't speak for the Go project.
FreeBSD is and will remain fully supported. We are not going to just
throw that work away because of some off hand comment on a mailing
list.
The goal is to support more platforms, not less.
Andrew
I think people using Linux or FreeBSD would prefer to install Go from
their package manager.
I know we are talking about binary distribution here, but we will have a
source tarball too, right?
In short: No binaries for Linux required and actually harmful. Please provide proper distribution packaging or support others doing it.
On Wednesday, March 7, 2012 12:52:32 AM UTC+1, kimelto wrote:I think people using Linux or FreeBSD would prefer to install Go from
their package manager.
I know we are talking about binary distribution here, but we will have a
source tarball too, right?No binary tar balls required for Linux, since one size fits all doesn't work with the variety of distributions.Just support people like the great Gophers at https://launchpad.net/~gophers/+archive/goand help people with older binaries of the tool chain get the odd fix running.
I had the weekly stuff running even on vintage Debian Lenny using their source packageand a small fix from the Mecurial to get some of our stuff running.Good example how to do it right, even when you want to provide the binaries yourself is Virtual Box.See https://www.virtualbox.org/wiki/Linux_Downloads for the matrix usually required.
I would go as far as claiming that binaries for Linux are even harmful because desktop users tend to try them and risk their niceand consistent package management with it and ask for help half a year later because sth. doesn't work.
According to the FHS (I don't know what SUS says about this), /usr/local
is for the local administrator's use. Third party software should be
installed in /opt.
...Marvin
Fair enough. I just wish that Google placed a fair amount of their infinite resources
on the most important platform,which happens to be Windows.
And by "fair amount" I mean that if Google cared about the Go language then we would already have an official GUI library and a great IDE. Of course I'm not blaming the Go team (they have done more than we could ever expect).
That happens to be subjective. To Google, subjectively, the most important platform is linux-amd64. We have a few of those machines.
We're the wrong people to write a GUI library, since we wouldn't be using it. Itches should be scratched by the people with the itch. Somebody who's actually using a GUI library would probably write a much better GUI library.
> And that's the problem. It seems to me that Google is persuaded by the
> stupid idea that GUI libraries are unnecessary because everything should
> run in a browser. Obviously Google could hire an army of experts in GUI
> libraries. They don't do it because they don't want / don't care, and as a
> result they are making it impossible for Go to become a successful language.
Google != Go. The Go team is relatively small.
I agree that if a criteria for a succesful language is having a GUI
library, then Go is failing. Fortunately for me, I don't use a GUI
library.
Ian
Great!Seems that people have already voted with their downloads, and the numbers say...- Don't waste a single minute on the FreeBSD port.
- Focus on the Windows port.
On Wednesday, March 7, 2012 8:32:31 PM UTC+1, Brad Fitzpatrick wrote:That happens to be subjective. To Google, subjectively, the most important platform is linux-amd64. We have a few of those machines.If I'm not mistaken, Go is a general purpose language,
for all kinds of computers, of which 90% run Windows.
Why you say the "most important platform is windows"? Just because it
has "more user"? I think you are just counting one side of the coin
(the desktop).
On the server side most of the computers are running Linux which are
much more than desktops. It is very likely that the DNS that you used
to sent your complaints are running on Linux.
> by "fair amount" I mean that if Google cared about the Go language then we
> would already have an official GUI library and a great IDE. Of course I'm
> not blaming the Go team (they have done more than we could ever expect).
You could asked for some GUI libs for windows that most people would
sent you this link: http://go-lang.cat-v.org/library-bindings
There you can find GTK bindings and some for native windows toolkits.
Also follow "https://github.com/mattn" on github since he is the
responsible for some tookits.
--
André Moraes
http://andredevchannel.blogspot.com/
Google != Go. The Go team is relatively small.
I agree that if a criteria for a succesful language is having a GUI
library, then Go is failing.
Fortunately for me, I don't use a GUI
library.
Should the core language team at Google be in the business of officially endorsing libraries for specific domains? I am working on a Twitter API library. Should I expect Google to endorse it?
It is wrong to assume that third party libraries are spare time efforts.
Google may not prioritize how it uses its constrained resources the same as you, but that does not mean that they don't care.
Sum servers + desktops + laptops. Windows wins hands down.
On Wednesday, March 7, 2012 10:20:03 PM UTC+1, Peter Thrun wrote:Should the core language team at Google be in the business of officially endorsing libraries for specific domains? I am working on a Twitter API library. Should I expect Google to endorse it?If it is good enough and it is useful for millions of developers, probably. Google could even hire people for that, since they have so much money.
It is wrong to assume that third party libraries are spare time efforts.I believe that current GUI libraries for Go are spare time efforts.
Google may not prioritize how it uses its constrained resources the same as you, but that does not mean that they don't care.Because Google is a tiny company like Borland who struggles to stay afloat, right?
> Sum servers + desktops + laptops. Windows wins hands down.
When you add in phones and tablets I think the situation is less clear.
> Note that I was talking about an officially endorsed GUI library, not a
> library developed by someone in his spare time because Google doesn't care.
Go is an open source project with many contributors outside of Google.
Ian
Google already provides an excellent GUI library. It's called Chrome.
There is a related point--very important--also to consider. Some tools
or libraries when done well are a complete solution. The sqrt()
function is like this when fast and +/- 1ULP, then that is all there
is to do for all time. And on a larger scale the math library can
aspire to perfection even if is not complete in terms of all known
functions.
But other libraries, such as graphics libraries and GUI libraries,
have a different character. One of my products when I was the director
of advanced graphics software at SGI was OpenGL. We were proud of it
and millions use it. Yet, even so, Microsoft had reasons to build
DirectX. Same with windowing and GUI toolkits. There are many
solutions, more than there are operating systems. These tools embody a
philosophy and it is the differences in philosophy that may cause a
developer to prefer one over another when two or more are available.
Because of this, and in situations like this, Google may care very
much that solutions exist but may not believe that the right answer is
a single, official answer. You see this in the encoding libraries and
the encryption libraries which have evolved over time to be more of a
framework for expressing a variety of different mechanisms. What is
"official" here is the unified Go interface for the common functions.
GUI tools and code are this on an even larger scale.
I think a better way for us (Google) to show the importance of UI
frameworks would be to wait until developers have created at least
four of them then begin to see where there could be something in
common. The ratio of the common to the unique would then determine the
degree to which a consistent Go language framework would make sense
(as in the encryption case.) The database tools are approaching this
maturity but the GUI tools lag that greatly.
Not speaking for the Go team, just a personal view.
MIchael
--
Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
650-335-5765
I seem to remember that someone from the Go team said that Go isn't suited for embedded devices.
On 7 March 2012 13:39, Hotei <hote...@gmail.com> wrote:
> "Don't waste another minute on the FreeBSD port."Whomever said this originally doesn't speak for the Go project.
FreeBSD is and will remain fully supported. We are not going to just
throw that work away because of some off hand comment on a mailing
list.The goal is to support more platforms, not less.
Andrew
s/embedded/realtimeAny platform that works with Java should be fine for Go.Realtime is not compatible with garbage collection (soft-realtime might be, but it is not realtime, it is marketing term)
When you add in phones and tablets I think the situation is less clear.
Go is just different (it only depends on 2.6.x+ kernel and libc+libpthread). If you found a system wherethe packaged binary doesn't work, then it is a bug, please report it.
Providing a version for each distribution will fail because there are always distributions you didn'tknow.
I would go as far as claiming that binaries for Linux are even harmful because desktop users tend to try them and risk their niceand consistent package management with it and ask for help half a year later because sth. doesn't work.It is installed in /usr/local, which is supposed to be just the place for 3rdparty software not managed bypackage managers.
s/embedded/realtimeAny platform that works with Java should be fine for Go.Realtime is not compatible with garbage collection (soft-realtime might be, but it is not realtime, it is marketing term)
what is sth?
>
> Best Regards
>
> Ingo
> On Wednesday, March 7, 2012 9:23:54 PM UTC+1, Ian Lance Taylor wrote:
>>
>> Fortunately for me, I don't use a GUI
>> library.
>>
> Well, that's selfish. Millions of developers use a GUI.
I'm not sure "selfish" is the right word. In any case, since I don't
use a GUI library, you should be glad that I am not trying to develop
one.
To be clear, nobody on the Go team is opposed to having a GUI library.
If Go is a good enough language for GUI development, then somebody will
write one. That's the way it works.
Ian
I think your concerns are misplaced. Go is going from strength to
strength, and it is early days yet.
Andrew
OK. What else do you demand for free?
Do you really consider Google as a cost-less vendor of Windows only SW?
Can we please stop feeding the blatant troll? This thread is full of eloquent and wonderful counterpoints to every point. Let's not continue it?
--dho
--
We're not ignoring you. Contrary to some opinions expressed here,
Google doesn't have infinite resources. We're doing the best we can.
Thanks,
Andrew
How can it be the end of the story when we're just about to release
version 1? Go is only now just entering the world, and already you're
condemning it. Such hyperbolic negativity is unnecessary and
unhelpful.
It takes time to go from a base language to a well-designed GUI. You
say you're from a Delphi background - well think about that: it took
many, many years to go from Pascal to Turbo Pascal's bgi, and longer
still to arrive at Delphi. Like Niklaus Wirth we, too, started at the
bottom. Yet I believe we're making good progress.
I'm sorry we have not progressed as far as you might like. It's a
cliche, but patience is a virtue.
Sincerely,
Andrew
It takes time to go from a base language to a well-designed GUI. You
say you're from a Delphi background - well think about that: it took
many, many years to go from Pascal to Turbo Pascal's bgi, and longer
still to arrive at Delphi. Like Niklaus Wirth we, too, started at the
bottom. Yet I believe we're making good progress.
I'm sorry we have not progressed as far as you might like. It's a
cliche, but patience is a virtue.
On any decently managed sytem /usr/local is sth. sysadmins work on getting rid of.
With upstream one-size-fits-all binaries you miss:- dependency handling- deleting old stuff- permission management- extra debug symbol packages (one liner for some distros)- auto upgrade- deferred and checked upgrades on server farms- IT department support for developers- repeatable builds, even for older versions- reactivating software, believed dead (e.g. after conquering new markets, new community, new investor)- fixing old bugs with compiler versions you will not even remember to fullfill old contracts (e.g. extended lifetime for 5x the price deals will be done)- ...
The GUI library and the IDE in Delphi 1 were completely new, and Delphi version 1 was a complete development environment. That was possible because Borland realized the importance of a GUI, while Google doesn't even have it in the roadmap.
I am sorry but you are incredibly rude! Its one thing to want features but not wanting to pitch in yourself and then resorting to this behavior when people dont jump at what you say is just plain rude.
The pace with which we have received a top notch modern new language is nothing less then astonishing and the fact that it is to a large extent community driven only adds to that.
2c
You've somehow missed those 12 (sic!) years it took Borland to get from Turbo Pascal to Delphi.
I am sorry but you are incredibly rude! Its one thing to want features but not wanting to pitch in yourself and then resorting to this behavior when people dont jump at what you say is just plain rude.
The pace with which we have received a top notch modern new language is nothing less then astonishing and the fact that it is to a large extent community driven only adds to that.
Rude with whom? Did I ever say anything bad about the Go team? In case it isn't clear, my criticism is directed at Google the company.
Yes. It took Borland 12 years to create all that new stuff...
Can we now return to doing something productive or at least enjoyable?
PS: I have no professional use for Windows, so I may be misinformed, but I thought there already is some WinAPI binding somewhere out there.
> not a library developed by someone in his spare time because Google doesn't care.
Why don't you use "YOUR" spare time to make it better? In that case
"YOU" could trust on the code "YOU" wrote.
But then you say: It's a lot of work to do everything "BY MY SELF"
Then I say: Yes, that's why people release their code so others can help
But I think that coming from a Microsoft way of thinking you would
consider "free software to be a cancer" or another stupid statement
from Ballmer or Gates.
GUI's are a complex thing and if the Go-lang includes a GUI library in
the stdlib it will need to make it work fore every single platform
that is supported.
Go isn't only for Windows, unlike Borland Delphi. And everybody knows
that Kylix (Delphi for Linux) isn't even close of what Delphi was.
--
André Moraes
http://andredevchannel.blogspot.com/
http://golang.cat-v.org/packages shows the state of affairs for most distributions.
Only Gentoo seems to be missing there.
Best regards
Ingo
Why bother with an extra desktop GUI when your web GUI
is nice, fancy and offers anything anyway?
Your available options for GUI are:
- Use a browser based GUI (Ext JS, GWT, just to name a few).
- Use Go's wingui (code.google.com/p/gowingui) if you earn money
from Windows platform.
- Use one of the Go bindings of cross platform GUI toolkits like
fltk, gtk, lub.
- Write your own (I'd like to see a Blender style toolkit, please
drop
me a note once your done).
- Lament about Google not listening to your (aka the most important)
concerns.
You may choose.
C++ did not fail because its lack of builtin GUI.
Tools which provide
a cross-platform GUI-Toolkit (e.g. python/tcl, Java/Swing) suffer
from the non-native look&feel of their GUIs (which *is* an argument,
especially for the elder). If they support only the common subset of
UI elements the user experience suffers. The holy grail of UI
technology hasn't been found jet. And it got worse with multitouch.
Maybe Go will not become the de facto standard for building
Windows desktop applications in the next two years; but assuming
that this is necessary for a successful language might be a bit
far fetched.
One last point: Go is not a commercial product developed, marketed
and sold by Google. Google enables some really (!) clever guys to
develop Go by paying them and providing resources.
On Wednesday, March 7, 2012 9:23:54 PM UTC+1, Ian Lance Taylor wrote:
Google != Go. The Go team is relatively small.
I know.I agree that if a criteria for a succesful language is having a GUI
library, then Go is failing.And that is sad.
+1,000,000!
On Wednesday, March 7, 2012 12:48:10 PM UTC+10, Andrew Gerrand wrote:On 7 March 2012 13:39, Hotei <hote...@gmail.com> wrote:
> "Don't waste another minute on the FreeBSD port."Whomever said this originally doesn't speak for the Go project.
FreeBSD is and will remain fully supported. We are not going to just
throw that work away because of some off hand comment on a mailing
list.The goal is to support more platforms, not less.
Andrew
for about another year :-)
ron
Actually I believe the less is Go embraced by Windows developers the better it is for Go's success (I know I'm not politically correct now, sorry dev guys).
Many things are successful and don't involve Windows.
--
Aram Hăvărneanu
Many things are successful and don't involve Windows.
Whether it will or it won't, sniping at each other for one's
preferences in and opinions about preferred operating
systems IS NOT HELPING, however cathartic it may be.
Supposing that Google doesn't suddenly produce a Go Gui
project, and further supposing that that doesn't make us all
wimp out of Go and take up knitting instead, what could be
done or done differently to make things better?
Chris
--
Chris "allusive" Dollin
In case you're using GMail and you're not familiar with the "mute"
feature this is a great opportunity to try it out! If you have
keyboard shortcuts enabled you can hit 'm' or you can find the 'Mute'
entry in the 'More' menu.
/me follows his own advice
Thanks,
J.
Go has succeeded without full Windows GUI support. The team has accomplished what they set out to do—produce a great programming language for writing servers.
Succeeding in other fields will require more library support (but not necessarily in the standard library).