windows version?

[pythoniso]

this new language it's only for *nix environment?? no windows version?


actually i'm using windows

[Michael Sync]

I'm asking the same question here
http://groups.google.com/group/golang-nuts/browse_thread/thread/afbbcb9ad68a9a1a
:)

[pythoniso]

=)

well, two persons asking the same, and maybe will be more, what
happend to windows support??



On 10 nov, 23:39, Michael Sync <mchls...@gmail.com> wrote:
> I'm asking the same question herehttp://groups.google.com/group/golang-nuts/browse_thread/thread/afbbc...

[Adam Langley]

On Tue, Nov 10, 2009 at 9:39 PM, Michael Sync <mchl...@gmail.com> wrote:
> I'm asking the same question here
> http://groups.google.com/group/golang-nuts/browse_thread/thread/afbbcb9ad68a9a1a
> :)

There is no Windows port currently, nor any plans for one.

It is, however, open source so patches are welcome :)

AGL

[billyzelsnack]

On Nov 10, 11:46 pm, Adam Langley <a...@golang.org> wrote:
> There is no Windows port currently, nor any plans for one.
>
> It is, however, open source so patches are welcome :)
>
> AGL

So in other words.. It'll be a half-assed second class barely working
implementation for years to come like as with so many other ( open-
source, cough ) projects? I know none of the cool kids would ever
touch Windows ( 0h my g00dn3ss gr4c10us ), but Windows is important
enough platform that it really deserves proper support directly within
the official "plan."

[Stephen Shaw]

I imagine that the mass majority of google's infrastructure is on
linux and many employees using macs I'm not sure I understand why it
would be of huge interest to get a windows version right away.

Cheers,
Stephen

[Russ Cox]

> So in other words.. It'll be a half-assed second class barely working
> implementation for years to come like as with so many other ( open-
> source, cough ) projects? I know none of the cool kids would ever
> touch Windows ( 0h my g00dn3ss gr4c10us ), but Windows is important
> enough platform that it really deserves proper support directly within
> the official "plan."

Go is not like Chrome or Android: it is an experiment, not a product,
and we don't know where the experiment will lead. There is no
"official plan".

We understand that a significant fraction of computers in the world
run Windows, and it would be great if those computers could run
Go programs. Adam's comment was not intended to be dismissive:
we hope Go will run on Windows, but we don't have the resources
to do everything, and there are issues that are more important to us.

I have done low-level Windows programming in the past and have
at least passing familiarity with the Go runtime; I would be very happy
to see Go running on Windows and am more than willing to answer
questions and offer advice.

Russ

[Wilson MacGyver]

While I understand you think windows is very important,
Go has just been open sourced. It started as a 20% project.
I don't think taking such a tone to a group of developers who
owes you nothing is constructive.

--
Omnem crede diem tibi diluxisse supremum.

[atomly]

On Wed, Nov 11, 2009 at 1:34 AM, billyzelsnack <billy.z...@gmail.com> wrote:

So in other words.. It'll be a half-assed second class barely working

implementation for years to come like as with so many other ( open-
source, cough ) projects? I know none of the cool kids would ever
touch Windows ( 0h my g00dn3ss gr4c10us ), but Windows is important
enough platform that it really deserves proper support directly within
the official "plan."

I don't know that being so abrasive is really the best way to prove your point.

Anyway, I think that most open source projects would be more than happy to support Windows, were it a more simple proposal.  Given that toolchains, environment, etc. are so radically different on Windows, though (e.g. lack of C99 support), it generally means that either code tends to be littered with tons of #ifdefs or everything has to be written in a rather restricted manner from the beginning in order to make it happen...

More importantly, I think it's wrongheaded to believe that it's some sort of 1337 h4x0r mentality that prevents Windows support-- generally Linux and MacOS on Intel/AMD are supported because those are what people use...  It's just as hard to find Solaris/Sparc support for a lot of projects as it is to find Windows support.

--
:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.917.442.9450 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

[billyzelsnack]

On Nov 11, 12:55 am, atomly <ato...@atomly.com> wrote:
> Anyway, I think that most open source projects would be more than happy to
> support Windows, were it a more simple proposal.  Given that toolchains,
> environment, etc. are so radically different on Windows, though (e.g. lack
> of C99 support), it generally means that either code tends to be littered
> with tons of #ifdefs or everything has to be written in a rather restricted
> manner from the beginning in order to make it happen...

Which is exactly why it needs to be a first class citizen.

> More importantly, I think it's wrongheaded to believe that it's some sort of
> 1337 h4x0r mentality that prevents Windows support-- generally Linux and
> MacOS on Intel/AMD are supported because those are what people use...  It's
> just as hard to find Solaris/Sparc support for a lot of projects as it is to
> find Windows support.

Actually I think it is a mentality. People get used to one thing and
don't like to use unfamiliar icky things. Kinda like soymilk.

[atomly]

On Wed, Nov 11, 2009 at 2:05 AM, billyzelsnack <billy.z...@gmail.com> wrote:

Actually I think it is a mentality. People get used to one thing and

don't like to use unfamiliar icky things. Kinda like soymilk.

Well, it certainly is *a* mentality, but I was trying to say that it wasn't the mentality that you implied in your previous mail (the we're too leet for Windows mentality) and more a case of "this platform is very different and actually takes a lot of work to support."

memcached, a very widely used and well supported open source project, for example, was total crap on Sun CMT processors running Solaris until Sun actually started paying people to fix it.

[billyzelsnack]

On Nov 11, 1:15 am, atomly <ato...@atomly.com> wrote:
> memcached, a very widely used and well supported open source project, for
> example, was total crap on Sun CMT processors running Solaris until Sun
> actually started paying people to fix it.

So we agree! Google should pay people to make sure it works proper on
Windows. :)

[Andrew Rabon]

It's very disheartening for me that this project is not even possible
on Windows yet. I don't think asking for some kind of basic command
line support for the majority OS is some kind of outlandish
requirement for /any/ Google project when it's initially released. Go
is an interesting project, but I can't help but feel the line about
"adventurous users" trying it is some kind of cruel gag on Windows
users. Are you saying we should be adventurous enough to switch
operating systems just for this? If not, I think this could have used
a little more gestation time.

My two cents, sorry if I came off as prickish. Just, coming from
trying to contribute code to Android using Windows requires a non-
ideal implementation, and that's already in version 2.0. I can easily
see this falling trap to the mentality Billy was talking about and
remaining *nix only for years to come, which would limit not only its
scope but also its open source community support. It's something I
don't want to happen and I feel I need to point this out now while the
project is still very new.

Just, keep it in mind, Go guys, OK?

[Sverre Rabbelier]

Heya,

> Anyway, I think that most open source projects would be more than happy to
> support Windows, were it a more simple proposal.  Given that toolchains,
> environment, etc. are so radically different on Windows, though (e.g. lack
> of C99 support), it generally means that either code tends to be littered
> with tons of #ifdefs or everything has to be written in a rather restricted
> manner from the beginning in order to make it happen...

The Git project faces the same issue, but is slowly improving. We have
a 'blessed' fork that uses MinGW to get things working on Windows and
are slowly incorporating all their patches needed to make Git work on
windows mainline. This works mostly because of the efforts that have
gone into making Git compatible with other OS-es.

What I mean is, if someone were to invest time into a MinGW port of
Go, and would contribute the patches to the project early on, it would
save a lot of pain and trouble later on. So, for those of you who are
on Windows and want to use Go (and do not want to set up a VM/ dual
boot), look into MinGW and try compiling Go. I'm sure the list will be
more than willing to help you overcome any compilation issues if
you're putting forth the effort to do this :).

--
Cheers,

Sverre Rabbelier

[Sverre Rabbelier]

Heya,

On Wed, Nov 11, 2009 at 08:52, Andrew Rabon <emailo...@gmail.com> wrote:
> It's very disheartening for me that this project is not even possible
> on Windows yet. I don't think asking for some kind of basic command
> line support for the majority OS is some kind of outlandish
> requirement for /any/ Google project when it's initially released.

Give Cygwin a try, it might just work :).

--
Cheers,

Sverre Rabbelier

[Ian Lance Taylor]

Andrew Rabon <emailo...@gmail.com> writes:

We are keeping it in mind. It's a question of resources. This is an
experimental language, not a finished product.

Ian

[LS 134]

On 11 Nov., 17:50, Ian Lance Taylor <i...@google.com> wrote:
>
> We are keeping it in mind.  It's a question of resources.  This is an
> experimental language, not a finished product.
>
> Ian

Experimental language - and no windows user can experiment with it.
I'm at the moment learning C++, took some basics of Python aswell. Go
sounded very promising but if there is no windows environment this
will just die for me.

Kind regards

[Anselm R Garbe]

2009/11/12 LS 134 <ljs...@googlemail.com>:

Windows has never been and will never be the primary focus of any open
source project imho.

Kind regards,
Anselm

[Antoine Chavasse]

It's just been released and as I understand it only a few people at google are working on it and probably not even full-time. Basically it means that better platform support etc. will have to come from the go community, and said community will indeed build up slowly at first until windows platform support, bindings to interesting C/C++ libraries and such start being contributed.

The language is definitely in a "need X? you have to do it yourself" stage at the moment but hopefully there are enough people interested in it that will be willing to make library bindings etc.

[Cameron Braid]

2009/11/12 LS 134 <ljs...@googlemail.com>

On 11 Nov., 17:50, Ian Lance Taylor <i...@google.com> wrote:
>
> We are keeping it in mind.  It's a question of resources.  This is an
> experimental language, not a finished product.
>
> Ian

Experimental language - and no windows user can experiment with it.

Every windows user can experiment with it by simply downloading VirtualBox and install Ubuntu

There are plenty of resources to show you how to do that.  Here's one  http://www.reclaimyourgame.com/index.php?option=com_content&view=article&id=230&Itemid=85

Cheers

Cameron

[billyzelsnack]

My take on what experimental means is..

Throw it at the wall and see if it sticks. Just a lot less committal
than Google's typical "beta" usage.

I'd like to see Go stick if nothing more than a well funded competing
language for C++ is very much needed. Go is just not going to stick
without proper Windows support. And no. Proper Windows support is not
MinGW. It is Visual Studio project builds ( going back a couple of
versions. )

Yeah I have an abrasive email tone, that's how I am, but just read it
as passion ( or some crap ) and that I've run across WAY too many
interesting opensource projects with HORRIBLE Windows support. The
longer a project waits, the more difficult and unlikely a proper
Windows implementation will exist. Git is a perfect example ( which is
why I use Hg. )

[Sean]

I'm programming go on Windows right now. Get vmware player and
download Ubuntu.

On Nov 12, 9:04 am, billyzelsnack <billy.zelsn...@gmail.com> wrote:

> I've run across WAY too many
> interesting opensource projects with HORRIBLE Windows support. The
> longer a project waits, the more difficult and unlikely a proper Windows implementation will exist. Git is a perfect example ( which is
> why I use Hg. )

If so many things you're interested in aren't supported by your OS of
choice, why not switch?

Stop damning people for lack of support on something for which you pay
nothing... And start *contributing* instead of complaining.

As Louis CK put it, "Everything's awesome, and nobody's happy."

[Santidhammo]

What I find lacking in this approach is that it appears through the
whole conversation that Windows programmers appear to be disheartened
by the idea to be sidelined. I disagree, in the current stage I am
using both GNU/Linux as well as Windows environments. There is a clear
cut difference between Windows and "the others". This difference is
unfortunate but simple:

Posix/UNIX/Linux environments are build in such a way that fast
development is much easier to take place. This is in disbelieve by
many Windows programmers because of the lack of something like Visual
Studio. But it is the need of such a product which only stipulates
that Windows has never been targeted towards programmers. It is
targeted towards a general-purpose community.

This is not a mistake and is not wrong, but it indicates that initial
development of a language similar to Go-lang needs to use a reliable,
compliant environment. Only Posix/System V systems have this. Even C++
(for those disbelievers) has started from Posix/System V, and not from
Windows.

Of course it needs to be ported, and it needs to be ported A.S.A.P. If
you, as a Windows programmer see the need for this, why don't you make
an attempt yourself? I don't hope you have a fear for Linux or Mac.

I think Google did a fantastic job to make this language. I've been
monitoring the D community for a long time and I know how difficult it
is to do this.

In your e-mail you claim that there are many failing Open Source
projects. Indeed, there are. But there are as many good ones that work
out well, also on Windows.

[Joseph Stewart]

Does anyone remember LINE (http://sourceforge.net/projects/line/)?

Perhaps this is an alternative route to getting Go to work on win32.

Just a thought... (perhaps a bad one).

-joe

[Noah Evans]

The Inferno compilers runs on Windows, Charles Forsyth is probably
your man if you want to know what you need to do to get a windows
version of go running.

Noah

[Jim Rueschhoff]

To me, there appears to be a lot of different assumptions being made concerning what a Windows version of Go would be like. 

Does the community expect program portability between different OSes?  This is not implied by porting a language to another OS.  A Windows C++ program interacting with .NET is not expected to run on Linux or OS X.  Porting a language means porting the compiler and any standard libraries that are defined by the language standard document.  Things like GUI interaction are not necessarily part of this. 

Some members of the group are talking about implementing the language on Windows.  Others are clearly talking about implementing a complete development environment on Windows that will support cross platform portability.  Many are somewhere in the middle.

I believe that a fine goal at this stage is just to port only the language and standard libraries and/or runtime package to Windows.  A worthy extension of the goal would be to support .NET in a Windows environment.  Except for Java, cross platform implementations of languages do not imply portability of programs.  In Java's case this was the goal but as anyone who has worked on implementing Java applications across various OSes knows, it was only somewhat successful.  

Before we start working on a Windows port let's first decide what it is that we are trying to port.

--
Jim Rueschhoff
Glendale Arizona
jrues...@gmail.com
jru...@rueschhoff.com

[Steve]

I am fairly sure that the Windows port of Inferno is built using VC++,
there is neither a back end to the 8l to generate Windows
PE executables, nor a front end to read windows object files.

Even with these fixed there are calling convention issues
and debugging symbols to sort out.

Though you can build Linux and plan9 executables using
the plan9 compiler executables on windows.

I wish it where not the case.

-Steve


On Nov 17, 4:27 pm, Noah Evans <noah.ev...@gmail.com> wrote:
> The Inferno compilers runs onWindows, Charles Forsyth is probably

[Ben Tilly]

On Tue, Nov 17, 2009 at 9:47 AM, Jim Rueschhoff <jrues...@gmail.com> wrote:
> To me, there appears to be a lot of different assumptions being made
> concerning what a Windows version of Go would be like.

[...]

> I believe that a fine goal at this stage is just to port only the language
> and standard libraries and/or runtime package to Windows.  A worthy
> extension of the goal would be to support .NET in a Windows environment.

One question comes up if anyone is seriously considering a Windows
port. The Go spec says that data should be UTF-8. Windows typically
uses UTF-16. Should a Windows port support the UTF-16 that Windows
tools are likely to generate? Should the Go spec be modified to allow
different Unicode encodings?

> Except for Java, cross platform implementations of languages do not imply
> portability of programs.  In Java's case this was the goal but as anyone who
> has worked on implementing Java applications across various OSes knows, it
> was only somewhat successful.

Except for Java? Really?

The exact same portability promise has been made many times before.
As far as I know it was first made for COBOL. As a practical matter
I've found that reasonably well written applications in scripting
languages (like Perl, Ruby, and Python) tend to work across different
operating systems without issues.

> Before we start working on a Windows port let's first decide what it is that
> we are trying to port.

It generally helps to know what you are trying to do before you do it. :-)

In this case I really think that it is important to ask whether
multiple encodings should be supported. And if it is supported in the
Windows version, should the spec be changed to support that.

Cheers,
Ben

[atomly]

On Tue, Nov 17, 2009 at 12:47 PM, Jim Rueschhoff <jrues...@gmail.com> wrote:
> I believe that a fine goal at this stage is just to port only the language
> and standard libraries and/or runtime package to Windows.  A worthy
> extension of the goal would be to support .NET in a Windows environment.
> Except for Java, cross platform implementations of languages do not imply
> portability of programs.  In Java's case this was the goal but as anyone who
> has worked on implementing Java applications across various OSes knows, it
> was only somewhat successful.

I think "somewhat" isn't giving it quite enough credit. There are a
few pain points, to be sure, but in general it works quite well. I
guess I might be writing different types of programs, though.

I think it's quite funny that Windows users are so up in arms that
there isn't support for their OS yet. Linux users (and other
platforms, to different degrees) have been dealing with this exact
situation for years and years...

[Russ Cox]

> One question comes up if anyone is seriously considering a Windows
> port.  The Go spec says that data should be UTF-8.  Windows typically
> uses UTF-16.  Should a Windows port support the UTF-16 that Windows
> tools are likely to generate?  Should the Go spec be modified to allow
> different Unicode encodings?

UTF-8 was an explicit simplifying design decision and is unlikely
to change. UTF-16 is certainly required in the internal system call
interfaces on Windows, but that's a library issue. I've seen very
few tools that can write UTF-16 but refuse to write UTF-8, especially
with the widespread popularity of UTF-8 as an exchange format on
the internet.

Russ

[Jim Rueschhoff]

ff Go is going to be a niche language used mainly in North America on Desktop and x86 servers than limiting it to supporting UTF-8 may be sufficient but to become a globally used mainline language support of other encodings is a must.  However during the early development stage limiting it to UTF-8 is not only acceptable but probably wise.  Care must be taken not to define tjhings like string handling in such a way to not exclude UTF-2, UTF-16 and UTF-32.

[Jim Rueschhoff]

My experience in potability of Java apps is based on a project I worked on a few years ago porting a rather large B2B suite to run on Windows, Linux, AIX, OpenVMS and HPUX.  There were a lot of issues to work out.  Surprisingly while Linux was a very easy port from Windows, AIX turned out to be one of the most difficult.    Only the Windows to Linux port was close to what I would consider truly portable code. 

[Ian Lance Taylor]

Ben Tilly <bti...@gmail.com> writes:

> One question comes up if anyone is seriously considering a Windows
> port. The Go spec says that data should be UTF-8. Windows typically
> uses UTF-16. Should a Windows port support the UTF-16 that Windows
> tools are likely to generate? Should the Go spec be modified to allow
> different Unicode encodings?

Go says that source code, notably including string literals, should be
written in UTF-8. I certainly don't think that that should change to
UTF-16. If it did, it would be painful to copy a .go file from a Unix
system to a Windows system or vice-versa.

Go doesn't say much about data files. It provides some library
support for UTF-8 in data files, and support for UTF-16 could be
provided as well. Similarly the library could functions to convert
strings and byte sequences from UTF-8 to UTF-16.

Ian

[Noah Evans]

Ouch, thanks for the correction.

Noah

[Tal]

don't worry. I'm sure microsoft has plans for go#

On Nov 10, 10:34 pm, billyzelsnack <billy.zelsn...@gmail.com> wrote:
> On Nov 10, 11:46 pm, Adam Langley <a...@golang.org> wrote:
>
> > There is no Windows port currently, nor any plans for one.
>
> > It is, however, open source so patches are welcome :)
>
> > AGL
>
> So in other words.. It'll be a half-assed second class barely working
> implementation for years to come like as with so many other ( open-
> source, cough ) projects? I know none of the cool kids would ever
> touch Windows ( 0h my g00dn3ss gr4c10us ), but Windows is important
> enough platform that it really deserves proper support directly within
> the official "plan."

[Juztin]

Windows may be an important platform, but this language was created by
Google for potential internal use. Google doesn't use much Windows, if
any, so it was probably more important for them to get it up and going
on the platforms they currently use with a basic core functionality.

I'm sure the Windows port will come, just as new/missing features. But
it's a new language and we can't have it all at once.

[Russ Cox]

On Mon, Nov 23, 2009 at 13:44, Juztin <jus...@redyetis.com> wrote:
> Windows may be an important platform, but this language was created by
> Google for potential internal use. Google doesn't use much Windows, if
> any, so it was probably more important for them to get it up and going
> on the platforms they currently use with a basic core functionality.
>
> I'm sure the Windows port will come, just as new/missing features. But
> it's a new language and we can't have it all at once.

Please read the rest of the mailing list before replying
to 6 day old posts. This was discussed quite a bit
last week, is now in the FAQ, and earlier today someone
posted about a preliminary Windows port working.

Russ