[go-nuts] What is (or could be) GO's killer application?

[Xiance SI(司宪策)]

Hi, calling for casual discussion :)

IMO, a killer application plays an important role in the success (or just
the survival) of a language: C has *NIX,  Ruby has ROR, and Objective-C
has iPhone, you could name more examples. After the success of the
killer application, the language may attract more coders, and grow into a
widely used one (like C/C++), or just stick to its niche application (like Ruby).

What would be GO's killer application, that is hungry for a (better) solution,
has great impact, and fits in GO's profile?

wishes,
Xiance

PS: The topic may have already been discussed,  but I cannot read the
history archives, since Google Groups' Web access is blocked here. If it had
been discussed, I'm sorry and please just ignore my post.
 

[Johann Höchtl]

On Apr 17, 1:06 pm, Xiance SI(司宪策) <adam...@gmail.com> wrote:
> Hi, calling for casual discussion :)
>
>

> What would be GO's killer application, that is hungry for a (better)
> solution,
> has great impact, and fits in GO's profile?
>

* An XMPP-Service (hosted by Google like FB using Erlang)
* Outperforming most other implementations in an 100k parallel request
contest
* (fast) HTML5 server service on websockets

> wishes,
> Xiance
>


--
Subscription settings: http://groups.google.com/group/golang-nuts/subscribe?hl=en

[Beoran]

Game programming, if Go gets ported to windows and to the game
consoles like the playstation, xbox and wii,
and to the smart phones. It's parallell structure, simplicity and
garbage collection will make game programming
much simpler than with C++ without losing performance.

Too bad Google is an Internet company. I think they could hit gold
very easily with Go in the game programming market if only they'd
allocate some more resources to developing it.

[Sebastian Nowicki]

On Apr 18, 1:40 am, Beoran <beo...@gmail.com> wrote:
> Game programming, if Go gets ported to windows and to the game
> consoles like the playstation, xbox and wii,
> and to the smart phones. It's parallell structure, simplicity and
> garbage collection will make game programming
> much simpler than with C++ without losing performance.
>
> Too bad Google is an Internet company. I think they could hit gold
> very easily with Go in the game programming market if only they'd
> allocate some more resources to developing it.

Game development is already possible with Go on the Linux and Mac OS
platforms (what a refreshing change), all you need are bindings to
OpenGL and and other media libraries you might use (there are already
OpenGL and SDL bindings). I'm sure the Go compilers will be ported to
other platforms soon, but it's still a very young language and it will
take time.

I agree that this would be very fitting for the language. The
concurrent nature of goroutines and the message passing paradigm would
definitely make development easier.

[Joan Miller]

On 17 abr, 11:06, Xiance SI(司宪策) <adam...@gmail.com> wrote:
> Hi, calling for casual discussion :)

> What would be GO's killer application, that is hungry for a (better)
> solution,
> has great impact, and fits in GO's profile?

A web framework since that it attracts to so many developers.

No doubt about using Ruby --outside Japan-- thanks to RoR.
Django (in Python) also has attracted to many developers from Java/PHP
world.

[Beoran]

Yes, it's true that you can already write games with Go, that's why
I'm currenty
wrapping SDL, etc myself for my fungo project.

However, I still think that Google should allocate more resources to
porting Go to non server platforms, and also to cgo to make go a
truly
viable commercial option for game development. They have resources
enough
to take this from a 20% project on the side to something more serious,
so I think they should.

Now it's just a nice alternative for open source games.

Kind Regards,

B.

[Andrew Gerrand]

On 18 April 2010 22:59, Beoran <beo...@gmail.com> wrote:
> Yes, it's true that you can already write games with Go, that's why
> I'm currenty
> wrapping SDL, etc myself for my fungo project.

Does the project have a website? I'd like to check out what you've done.

> However, I still think that Google should allocate more resources to
> porting Go to non server platforms, and also to cgo to make go a
> truly
> viable commercial option for game development. They have resources
> enough
> to take this from a 20% project on the side to something more serious,
> so I think they should.

Do you mean Windows, specifically? The support for Windows is coming
along very well. In fact, it would be awesome if interested people
(like yourself, if you're so inclined) could test out stuff like SDL
under Windows.

At the moment the main priorities are improving the runtime and the
language tools (debugger, etc). These are platform independent and
should benefit almost any endeavour. SWIG support should make
accessing game-related stuff libraries easier, too.

See http://golang.org/doc/devel/roadmap.html for more.

How much of C++'s development process specifically addressed gaming? I
can't think of anything. It seems to be mostly library support that
matters.

Besides Windows support, what else should the Go team be doing to make
it better for gaming?

Andrew

> Now it's just a nice alternative for open source games.
>
> Kind Regards,
>
> B.

[Beoran]

Andrew Gerrand wrote:
> Does the project have a website? I'd like to check out what you've done.
>

http://github.com/beoran/fungo

It's still very messy and unfinished. For now I'm focusing on 2D games,
like Pygame does. It has some rudiments of a tile map and gui
as well.

> Do you mean Windows, specifically? The support for Windows is coming
> along very well. In fact, it would be awesome if interested people
> (like yourself, if you're so inclined) could test out stuff like SDL
> under Windows.
>

Well it may sound contradictory, but I don't use Windows myself.
But I guess I could test by using Wine. As of lately, the PC seems
to be not such a commercially viable platform for gaming anyway.

What I was talking about was more general non-server and non-desktop
platform support. With the advent of casual gaming and smart phones,
the focus is now more on on these platform, at least, it seems to me.
If you look at what programing languages are widely supported on most
any platform, then it's usually only the short list of assembler, C and C++,
and perhaps Java.

Ports of go to say, Android mobile phones, and to game consoles would be
awesome IMO, not to mention very profitable to Google, and make the life
of game progammers everywhere easier. I imagine think like Google
developing Go runtime libraries for the Wii 2 , or the Playstation 4.

> At the moment the main priorities are improving the runtime and the
> language tools (debugger, etc). These are platform independent and
> should benefit almost any endeavour. SWIG support should make
> accessing game-related stuff libraries easier, too.
>

Yes, that's all very nice, I agree. Although in the future, ideally,
everything but the OS could possibly be written in Go. I'm not sure what
could help her, but for games very low level support, possibly with easy
access to the assembler is sometimes useful. Maybe allow inline assembly
in Go?

> How much of C++'s development process specifically addressed gaming? I
> can't think of anything. It seems to be mostly library support that
> matters.
>

Well, library support is important, yes, but C++ had the great advantage
that it built upon the C legacy directly. So, it could be ported to many
hardware platforms rapidly.

Cgo and Swig are nice, but it's still a bit at an arm's length. I feel
many game libraries could be reimplemented in Go, which is what I'm also
doing with Chipmunk 2D game physics. http://github.com/beoran/tamias
Again, I'm advancing slowly here. :)

> Besides Windows support, what else should the Go team be doing to make
> it better for gaming?
>

Id say:
1) Port to as many hardware/software platforms as possible.
2) Make linking to C libraries, and exporting for use in C and C++ as
easy as possible.
3) Make it easy to do very low level stuff. I already mentioned inline
assembly. Go has no conditional compilation, which is a bit of a hassle
for writing portable graphics libraries. Perhaps the go compiler could
automatically select the file to compile based on the filename? For
example if you have gfx_wii.go, gfx_ps3.go, gfx_386_linux.go,
gfx_amd64_windows.go, etc. only the gfx_... for the current target
platform will be compiled.

Anyway, just some of my ideas. Thanks for your consideration.


Kind Regards,

Bjorn.

[befelemepeseveze]

On 18 dub, 18:35, Beoran <beo...@gmail.com> wrote:
> 3) Make it easy to do very low level stuff. I already mentioned inline
> assembly.

http://golang.org/doc/go_spec.html#Function_declarations

"A function declaration may omit the body. Such a declaration provides
the signature for a function implemented outside Go, such as an
assembly routine."

Examples:
http://golang.org/src/pkg/math/

> Go has no conditional compilation, which is a bit of a hassle
> for writing portable graphics libraries. Perhaps the go compiler could
> automatically select the file to compile based on the filename? For
> example if you have gfx_wii.go, gfx_ps3.go, gfx_386_linux.go,
> gfx_amd64_windows.go, etc. only the gfx_... for the current target
> platform will be compiled.

See e.g.:

sqrt.go
sqrt_386.s
sqrt_amd64.s

and how the math package selects generic vs arch specific versions.

-bflm

[Beoran]

Thanks for reminding me of this, however it's not completely the same
as inline assembly.
It seems to me that it requires some makefile magic to get this to
work. It works, but feels
slightly clumsy. Why not give the compiler that knowledge?

[Uriel]

On Sun, Apr 18, 2010 at 10:38 PM, Beoran <beo...@gmail.com> wrote:
> Thanks for reminding me of this, however it's not completely the same
> as inline assembly.

It is not the same, it is much better.

> It seems to me that it requires some makefile magic to get this to
> work. It works, but feels
> slightly clumsy. Why not give the compiler that knowledge?

Because mixing Go and asm would be *really* clumsy.

Standard C has no inline asm, and when non-standard extensions are
used to mix asm with C code the result is without fail a huge hideous
unportable mess.

Inline asm, like the C preprocessor have turned out to be huge
mistakes that have encouraged countless abuse, that Go lacks those
'features' is a very good thing.

uriel

[Beoran]

Well, Uriel, I can see your point, although the saying goes that abuse
does not
mean that good use should be made impossible. There is a lot of C code
that
does use preprocessing and assembly to good effect.

But I guess I should not be talking in the abstract and in stead try
to write libraries
that rely on the low level features I talked about and see if this way
of working
discussed above is easy to use or not. As always, I'm basically just
throwing around ideas.
I don't think I have the right solutions, but I do think I'm asking
the right kind of
questions.

Kind Regards,

B.

[Michael Hoisie]

Go is a great language to write website backends, but I wouldn't call
this a killer app because there are tons of other languages that can
do this very well.

I can see it being used by existing companies to build services that
need to scale very quickly. For instance, Facebook built their chat
system in Erlang because they needed it to scale to massive numbers on
the first day.

[teleforce]

Hi,

I envisions Go to be well suited for experimental physics or
engineering provided it can support most of the scientific computation
needs like multi-dimensional arrays effectively. There is a post
regarding experimentation software issues in Slashdot:

http://tech.slashdot.org/tech/09/01/30/1443203.shtml

I've used Labview/LabWindows CVI, Igor and Matlab to some extent but
they all have their own limitations. The killer feature is that to
support fast compilation and thus being interactive at the same time.
My former university is re-doing their own measurement system software
from scratch using .Net because the existing Igor based software is
not stable enough being a scripting language. Igor, however, is quite
powerful for doing experimentation and computation at the same time.

Experimental physics or engineering software is MORE than just
scientific computing software because you need hardware interfacing,
real time processing, controller and powerful computing framework.
Additional it may be required to do hardware-in-the-loop type of
postulation that requires simulation software to interface with
experimentation hardware.

On top of that, being open source, typed, parallel and easier to
program, IMHO it probably can take the industry by storm.

Regards,
Shaiful

[Carl]

Killer Applications in GO. My take:

1. Lightweight highly scalable Servers that exploit Multi-core
Processors.
basically anything that has to be highly scalable using minimal
resources,


A. Load & Stress testing. What likely is already possible are
lightweight Servers(Load Injectors) that could be used for load-
testing & Stress-Testing of Web-Application Infrastructures
Simulating the behavior of hundreds of thousands of Users. Answering
questions like: how high can I scale (number of Users...) this
Application?

B. A very serious killer Application (in my opinion) would be: Peer-
to-Peer (802.11n) Wireless-Lan Networking for Android Handsets. What I
mean is that the Android Handsets talk directly to each other without
the mandatory requirement for a central INTERNET connection or
provider. The Idea is to create spontaneous decentralized 802.11n
P2P Networks at Airports, on Buses, Trains, Library's between Mobile
Android handsets that are in range. This could be used for any form
Mesh-Network, Social Networking (Workgroup) and/or Filesharing that
is conceivable. This would open up an entire new category of of
Mobile applications. GO would be good for this because it is designed
for C oriented Systems-Programming of concurrent technologies.

C. Distributed operating system functions. It seems to me that GO-
Language lends itself rather well to that kind of thing.

2. Maybe GO-Language could be used on the Client side. I am not 100%
sure about this but I think at some point it may compile so fast that
it could be used for Client-Side Programming (instead of Javascript
for example). That is probably still a ways down the road and
contingent on implementing the GO compiler in GO-Language itself with
concurrent compilation. I am not sure if that is possible, but maybe
its foreseen in the design.

[Carl]

[Beoran]

Other killer applications for Go that just sprang to my mind: PLC's,
and embedded software. Much of this is programmed either in C or in
ladder logic and related arcane languages. Go would make developing
for such platforms easier, whilst also allowing parallelism. For that
we will need Go to be ported to a whole host of platforms (just like
for gaming).

And it would be even nicer if it was possible to port Go to a bare
platform (without any OS). Goroutines could then be used to implement
light weight processes, and the garbage collector handles memory
allocation.

My conclusion is this: I'd like the developers of Go to make the go
compiler Go as easy to port and as easy to retarget to a new
architecture / platform as possible, perhaps even easier than C, if
that is possible. A bit like how lcc is a retargetable C compiler. And
I'd like Google to invest a bit more resources in getting these ports
off the ground. If Go is to become a widely popular system programming
language, we need it to become usable on all sorts of platforms.

Kind Regards,

B.

[Ian Lance Taylor]

Beoran <beo...@gmail.com> writes:

> And it would be even nicer if it was possible to port Go to a bare
> platform (without any OS). Goroutines could then be used to implement
> light weight processes, and the garbage collector handles memory
> allocation.

A sample implementation of this has been done. See
src/pkg/runtime/tiny/README.

> My conclusion is this: I'd like the developers of Go to make the go
> compiler Go as easy to port and as easy to retarget to a new
> architecture / platform as possible, perhaps even easier than C, if
> that is possible. A bit like how lcc is a retargetable C compiler. And
> I'd like Google to invest a bit more resources in getting these ports
> off the ground. If Go is to become a widely popular system programming
> language, we need it to become usable on all sorts of platforms.

A Summer of Code student is working to port the gccgo compiler to
RTEMS, an embedded operating system (http://rtems.org/). I hope that
efforts like this will continue.

Ian

[⚛]

Well ... all responses to your post have hitherto been, well, overly
idealistic. In the sense that the world revolves around purely
technological merits.

So, let me concentrate on a very different aspect of language
adoption. In that spirit, the answer to your question is the
following:

The killer application for Go would be to become the language of
choice for people who have power (economic power, political power,
charisma, etc).

On a similar note, do you think that we would be having this
discussion about Go if it wasn't for the fact that it is associated
with Google? Imagine this: your neighbor one day shouts to you that he/
she has a new experimental language identical to Go. What would you do
about it, what would people around the world do about it, would
journalists be writing about it?

In short, if you think that Go needs a killer application, I am afraid
you don't quite understand what is going on here. The *fact* is that
Go already has a killer feature: its of Google origin. That *is* Go's
killer feature - any other potential killer application I can think of
only pales in comparison to the fact about its origin. Instead of
asking the question about what Go's killer application would be, one
should first ask the question: doesn't it already have one?

... if you are now wondering what I personally think about Go, here is
my answer: I think Go is an *average* programming language. In other
words, there's nothing special about it. It does not solve those
problems that I really want a programming language to solve. But that
is just my opinion, you don't have to agree with it.

On Apr 17, 1:06 pm, Xiance SI(司宪策) <adam...@gmail.com> wrote:

[Corey Thomasson]

I'd have to say you're pretty off base here.

The fact that Go gets its backing from Google's pockets means little.
It's not as if Rob, Ken, Russ, etc. etc. weren't already rather
"famous" computer scientists. I was already using Go before I realized
it was funded by Google.

Conversely, the "Google Stamp" still can't make a bad product
successful, only a good product more successful. (Buzz for example,
seems to be nearly DOA). Go is an excellent language created by (IMO)
some of the best minds in the field. The fact that it's sponsored by
Google just helps speed things up.

[Johann Höchtl]

On Apr 20, 4:42 pm, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:

>
> In short, if you think that Go needs a killer application, I am afraid
> you don't quite understand what is going on here. The *fact* is that
> Go already has a killer feature: its of Google origin. That *is* Go's
> killer feature - any other potential killer application I can think of
> only pales in comparison to the fact about its origin. Instead of
> asking the question about what Go's killer application would be, one
> should first ask the question: doesn't it already have one?
>

I mostly agree. But I am under the impression that it is not fully
endorsed by Google yet. It's not like the .NET ecosystem which was
pushed by imense forces.Is anybody employed by Google working full-
time or at least 80% on it?
If people will pick it up, Google will cherry-pick too.

> ... if you are now wondering what I personally think about Go, here is
> my answer: I think Go is an *average* programming language. In other
> words, there's nothing special about it. It does not solve those
> problems that I really want a programming language to solve. But that
> is just my opinion, you don't have to agree with it.
>

Worse is better is ... unfortunately true. After spending a lot of
time experimenting with different languages and paradigms I still come
back to imperative languages to get the job done. If you compare it to
other langauges like ruby or python, Go need not hide in the back. As
it stands today it is the first language which syntactically support
parallelism and has the potential to see widespread adoption. (Occam
probably next). The others are from the FP-league, but are simply to
bewildering for the vast majority of programmers and hackers to help
them to get the (a) job done.

>> It does not solve those
> problems that I really want a programming language to solve. But that
> is just my opinion, you don't have to agree with it.

What problems do you have in mind?

[Ian Lance Taylor]

Johann Höchtl <johann....@gmail.com> writes:

> Is anybody employed by Google working full-
> time or at least 80% on it?

Yes, there is a small team at Google full-time on Go.

Ian

[Beoran]

Thanks Ian for telling me about this. This all looks very promising.
This also means that it would even be feasible to write an OS in Go
combined with some assembly. I agree that Google should continue to
support such efforts. As an aside, is the assembler well documented?
Does it support macros? Does it uise intel or at&t syntax?

Mr. 0xe2.0x9a.0x9b, it's true that politics and other external factors
apart from the quality of the language can play an important role in
whether or not a language becomes popular or not. For example, Ruby
only became popular after Rails made it famous. However, with Golang,
there will probably be no problem there, as long as Google keeps
backing it. By the way, that's also why what we're doing with Go is
important: by using Go we demonstrate it's usefulness and give the
bosses of Google a reason to keep backing it.

As for the qualities of Go itself, I think that it's a language that
has many features that are unremarkable by themselves, but which I
have never seen brought together in one language. For systems
programming, we need something better than C. Neither Objective C nor C
++ nor D are the answer. The first one has a hideous syntax, the
second one is a hideous overcomplicated beast, and the latter tries to
solve C++'s problems by adding even more complexity. Go tries to keep
things simple and safe, whilst adding several very useful features
(garbage collection, slices, maps, channels, goroutines and
interfaces, automatic generation of exports from packages)

And the people behind Go are, as said before, exceptionally skilled
programmers. There's even someone who helped invent Unix and C's
predecessor B. So, I feel that if all goes well, go will be here to
stay for the foreseeable future.

Kind Regards,

B.

[Uriel]

On Wed, Apr 21, 2010 at 9:24 AM, Beoran <beo...@gmail.com> wrote:
> Thanks Ian for telling me about this. This all looks very promising.
> This also means that it would even be feasible to write an OS in Go
> combined with some assembly. I agree that Google should continue to
> support such efforts. As an aside, is the assembler well documented?
> Does it support macros? Does it uise intel or at&t syntax?

The assembler syntax is the same used in the Plan 9's toolchain by ken, see:

http://doc.cat-v.org/plan_9/4th_edition/papers/asm

and

http://man.cat-v.org/plan_9/1/2a

uriel

[Beoran]

OK, thanks for that info.

On Apr 21, 9:37 am, Uriel <ur...@berlinblue.org> wrote:
> The assembler syntax is the same used in the Plan 9's toolchain by ken, see:
>
> http://doc.cat-v.org/plan_9/4th_edition/papers/asm
>
> and
>
> http://man.cat-v.org/plan_9/1/2a
>
> uriel
>

[Joan Miller]

On 21 abr, 07:24, Beoran <beo...@gmail.com> wrote:
> Thanks Ian for telling me about this. This all looks very promising.
> This also means that it would even be feasible to write an OS in Go
> combined with some assembly. I agree that Google should continue to
> support such efforts. As an aside, is the assembler well documented?
> Does it support macros? Does it uise intel or at&t syntax?

An OS is formed by the kernel (with its drivers) and the userland
tools (the basic).

Go is not a language to develop a kernel (because you need full
controll about memory so you cann't use a language with GC).

I'm not sure about if Go would be well to build kernel drivers. I'm
supposed that would be better a language without GC (at least for
drivers related to audio/video/crypto.)

In change, the userland tools could be built with Go, and if people is
going to develop them I hope that been licender under dual license
(BSD and GNU GPL) for that the same tool can be used by both
communities. Today is a problem when you're going to use a BSD system
and the options of userland-tools are not the same. In addition it's a
waste of time that both communities are working in the same but
without share the code source.

[⚛]

I will use an example to show a programming language problem that Go
isn't solving: support for constants/immutability in the type system.

In C/C++, it was around GCC version 4.3 (or 4.2?) that introduced the
idea that "const char*" cannot be converted into "char*". Previous
versions of GCC had no problems compiling code which contained such a
conversion, they probably emitted a warning only. But from a language
design point-of-view, this is *not* the main problem. The main problem
is that the type-system of C/C++ contains a hole. The newer GCC did
not patch the hole in the type system, instead, it just blindly
decided to disallow such conversions. Consider the following C/C++
code:

<code>
??? fn(bool cond, char *a, const char *b)
{
if(cond) return a;
else return b;
}
</code>

The problem is, what do you put there instead of ???. If you put there
"char*", you will get a compile error. If you put there "const char*",
you will also get a compile error.

But is this code objectively incorrect? No, the code does make perfect
sense, it is only that the C/C++ type system is incapable of enabling
one to write such code.

Now back to Go:
Q: How does Go deal with this?
A: It does not have any support for immutability in the type system.

Go "solves" this problem by forbidding you to express "const char*",
or generally any idea about immutability, in the language. In my
opinion, that is not a solution at all.

The Go way of solving problems:
Q: How do you solve an OBJECTIVE problem X?
A: Make the language pretend X does not exist.

But I am not saying that Go does not have any nice features. It does
have some nice features.

[Beoran]

Dear Joan,

Oops, did I say OS, I meant kernel.

Actually, it is a widely held misconception that you can't write an
kernel in a garbage collected language. If you think about it, kernels
have to do a kind of garbage collection anyway, because they have to
manage their processes' memory. So, it's perfectly possible to write
a kernel in a language that has garbage collection, as long as you
write some parts of the the language run time in assembly. Then the
kernel could actually use the language's run time to do it's memory
management. To write an kernel, you normally need a bit of assembly
for the low level functionality anyway, so it doesn't make things
really that much more difficult.

To demonstrate my point, there are already about 5 kernels written in
Java and assembly, even though Java does have garbage collection. See:
http://en.wikipedia.org/wiki/JavaOS, and the list at the bottom.

And unlike Java, in Go we have the most useful unsafe package and
uintptr, which are very fine for accessing memory directly. In fact,
in my fungo library, I use the unsafe package to implement drawing
functions that draw directly to an SDL surface, which is basically a
block of memory allocated in C. So I think this would make writing
kernel drivers just as easy as it is in C.

As for the userland utilities and the politics, I don' t want to get
too much into that, but I can agree with your sentiment.

Kind Regards,

B.

[Xiance SI(司宪策)]

The garbage collected kernel is interesting, heard of them for the first time.

Thanks Beoran for the eye-opening introduction :)

Xiance

[Daniel Smith]

On Wed, Apr 21, 2010 at 5:25 AM, ⚛ <0xe2.0x...@gmail.com> wrote:

<code>
??? fn(bool cond, char *a, const char *b)
{
   if(cond) return a;
   else return b;
}
</code>

The problem is, what do you put there instead of ???. If you put there
"char*", you will get a compile error. If you put there "const char*",
you will also get a compile error.

If you replace ??? with "const char *" it works just fine (http://ideone.com/xn8H8). It's fine to add a const specifier, just not remove one. It's my understanding that that is in fact why the go authors left out such a specifier-- I think most people who've written much in C++ have had the experience of adding one const and having that require more consts all over the place as it cascades through the code. Arguably, that's a problem with having forgotten to put the consts in in the first place and not really a defect in the language.


--
Daniel Smith
http://www.schaumburggoclub.org/

[Ian Lance Taylor]

⚛ <0xe2.0x...@gmail.com> writes:

> Q: How does Go deal with this?
> A: It does not have any support for immutability in the type system.

In my opinion, the type system is not the right place to express
immutability. Immutability is a characteristic of an object, not a
type.

Go does permit you to provide "immutable access to a mutable object"
by letting you provide access to the object only via an interface.
It's true that there is no way to express in the language that the
interface only provides immutable access, but I think that is OK.
That would be the equivalent of the "const" method qualifer in C++,
which leads you inexorably to the "mutable" member qualifier. I don't
think Go needs to go there.

One small area where Go could perhaps be improved is to permit
immutable arrays, struct literals, and maps. That would be more for
performance than for safety, though.

Ian

[Beoran]

On Apr 21, 3:53 pm, Ian Lance Taylor <i...@google.com> wrote:
> One small area where Go could perhaps be improved is to permit
> immutable arrays, struct literals, and maps.  That would be more for
> performance than for safety, though.
>
> Ian

Such constant arrays, maps and structs would would also be highly
useful for developing for embedded ROM-only systems, or for
read only data structures in a kernel, for example.

Kind Regards ,

B.

[⚛]

On Apr 21, 2:07 pm, Daniel Smith <lukenin...@gmail.com> wrote:

> On Wed, Apr 21, 2010 at 5:25 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> > <code>
> > ??? fn(bool cond, char *a, const char *b)
> > {
> >    if(cond) return a;
> >    else return b;
> > }
> > </code>
>
> > The problem is, what do you put there instead of ???. If you put there
> > "char*", you will get a compile error. If you put there "const char*",
> > you will also get a compile error.
>
> If you replace ??? with "const char *" it works just fine (http://ideone.com/xn8H8). It's fine to add a const specifier, just not
> remove one.

You are right. I should have tested it before posting. My apologies
for the confusion.

"const char *x" stands for: I know (*x) is either mutable or
immutable.
"char *x" stands for: I know (*x) is mutable.

Problem: how to express in C/C++ that (*x) is immutable. That is, to
express the knowledge that (*x) will always return the same value
(until the end of lifetime of data referred to by 'x'). Ideally, the
example I had in mind would look like:

char* fn(bool cond, mutable char *a, immutable char *b)

{
   if(cond) return a;
   else return b;
}

[⚛]

On Apr 21, 3:53 pm, Ian Lance Taylor <i...@google.com> wrote:

> ⚛ <0xe2.0x9a.0...@gmail.com> writes:
> > Q: How does Go deal with this?
> > A: It does not have any support for immutability in the type system.
>
> In my opinion, the type system is not the right place to express
> immutability.  Immutability is a characteristic of an object, not a
> type.

Yes, that is a plausible explanation. But it shows that the main issue
here seems to be the meaning of the term "type" and of the term "type
system". It is probable that my understanding is completely different
from your understanding.

In my opinion, the "type of an object X" is equivalent to "compile-
time knowledge about the nature of X".

Therefore, I simply cannot agree with you that <cite>"immutability is
a characteristic of an object, not a type"</cite>. Because "type" is
equivalent to "knowledge", if you know that "X is immutable" then such
knowledge is by definition part of the concept "type of X". The issue
in respect to programming language design is whether the type system
is designed to handle this kind of knowledge or not.

By the way, in my mind, the term "type system" is equivalent to "body
of methods for manipulating knowledge".

> One small area where Go could perhaps be improved is to permit
> immutable arrays, struct literals, and maps.  That would be more for
> performance than for safety, though.

Yes, that is possible, but I don't think it solves much - at least not
in the sense in which I understand immutability. For example, a
language should allow the programmer to express that "I am now passing
reference to X here via this function call, and I want to ensure that
when the called function returns, X will have the same value as before
the call".

So, I treat the whole mutability-immutability problem in the sense of
what you *know* about certain objects at certain time-points in
certain places/contexts. One aspect of a type-system is that one
should be able to lessen the amount of knowledge about X when sending
X somewhere else.

[Beoran]

Dear ⚛,

As far a I can see, I think you and the designers of many other
programming languages are mixing up two related but not quite same
concepts:
that of constancy and that of immutability.

To me, a constant is, said in short, and object of which both the
binary representation of the value
and the address is fully defined and fully determined at compile time.
If you look at the
assembly output, constant objects compile down to a label and set
of .db (define byte)
.dw, .l, or .string pseudo-instructions, usually in the .data section
of the binary.

An immutable object is an object that cannot be modified once it has
been created,
until it is destroyed. Stated otherwise, operations on an immutable
object are guaranteed to
have no side effects. An immutable object may however live in the heap
or on the stack, unlike
true constant objects. For example, IIRC, in Haskell all types are
essentially immutable,
because side effects are disallowed, however, most types are not true
constants as they live
on the stack or heap)

Any constant object is trivially immutable. However, an immutable
object may not be constant.
This is a crucial difference. The const modifier in C /C is a huge
misnomer, and a result of
this confusing immutability with constancy. Not to mention that I
think it's an attempt at
avoiding certain common errors in accessing pointers in C/C++. Errors
which are not possible
in Go, unless you use unsafe.

So I feel like I'm not convinced that having an immutable keyword
would do any good in Go.
Could you perhaps think of an example in Go (not C or C++) that would
benefit from it? Go is still young,
so if you make a convincing case, I think your proposal may be
considered. Perhaps it would be better
to start a new thread on this subject as we're hijacking this one.

Kind Regards,

B.

[Hans Stimer]

What problems does Go solve? Just an average language?

Apparently we have very different needs. From my perspective, Go is unique because of the set of things it does well. It has areas for improvement, but for my needs it is the best match I've found when compared to: C, C++, Erlang, Python, Ruby, C#, D, Java, and Scala.

At the end of the day what is most important to me is performance; but I love the convenience of modern language features. Unfortunately, I'm constantly having to go back to C/C++ to get the performance I need. However, if Ruby was <1.2xC I would use it. Go isn't <1.2xC yet, but given the language design choices that Go makes, it is reasonable to expect that level of performance can be achieved in the near future. So with near C performance and a bevy of modern elements, Go is very unique.

A+

---

* Fast turnaround - blinding fast compile/link/run cycle

* Concurrency - I've had to create many state machines and queues to manage large scale concurrency in other languages. Go gives it to me for almost no effort.

* Support - bright people give you great answers in a very short time

B+

---

* Keeps you from inadvertently shooting your foot off - not perfect but given that C and C++ are at about a D, this is pretty good

* Implementations - good implementations on the platforms I care about

B

---

* Fast executable assuming conscientious programming - could become an A if Go gets under 1.2xC and provides some memory allocation control

* Clear and concisely expressible - these are kind of at odds with each other but Go makes a good balance between the two

B-

---

* Connectivity with foreign libraries - assuming SWIG and CGO are complete. Could be smoother and more convenient

* Standard library - has a very good basic set

* Docs - respectable

C

---

* Building - building is better than C but thats about it. Gobuild and others are moving things along but not all the way there yet.

C-

---

* Editor - pretty basic support so far

F

---

* Debugger - ???

[Henrik Johansson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I don't really know much of the nitty gritty details but isn't
(explicit?) immutability something that can be exploited by the runtime
to increase performance? (Memory caches etc can be shared or what not...)

If there is a distinct technical advantage to having a keyword for
immutability then I'm all for it otherwise "less is more".

There must be other similar things that falls into the same category i
guess for example 'volatile'? Personally i am all for skipping these
things unless they bring something exceptional to the table.

/ Hank

"Dabbling with a whirlpool hash and loves the test framework"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkvPQQwACgkQ/tACVN8hOxFg4gD+JP2rXDFo/dTz3g5/kuQSZ3Jb
8Ga7rvMuUvvY8B3MopsBAJG74QaJvawFuAZcBF4cCkrW9T2UeCR5jv1R0l79iEAv
=dmiG
-----END PGP SIGNATURE-----

[⚛]

On Apr 21, 6:54 pm, Beoran <beo...@gmail.com> wrote:
> Dear ⚛,
>
> As far a I can see, I think you and the designers of many other
> programming languages are mixing up two related but not quite same
> concepts:
> that of constancy and that of immutability.

I think I disagree with such a statement. Because there is only *one*
kind of immutability. Whether you/me/someone calls it constant-ness or
immutability does not really matter that much. Every immutability is
just temporary - it is like a tag that says a certain region of
computer memory cannot be modified during the time that the
"immutability tag" applies to that region. Maybe the previous sentence
is a little rough and imprecise, but if you don't generally agree with
it, then I am afraid we cannot reach a mutual understanding here.

> To me, a constant is, said in short, and object of which both the
> binary representation of the value
> and the address is fully defined and fully determined at compile time.

Address fully determined at compile time? What about constants in a
dynamic library?

> If you look at the
> assembly output, constant objects compile down to a label and set
> of .db (define byte)
> .dw, .l, or .string pseudo-instructions, usually in the .data section
> of the binary.

So, you are saying that e.g. C-style string constants cannot be
implemented in any different way? Why not? For example, it is possible
to dump all string constants during compilation into a separate file,
then read-only map the file into the address space of the program at
startup and fix all the pointers pointing to those strings.

In other words, if you are trying to imply that .string pseudo-
instructions are the "only true way" to define string constants, then
I don't buy it.

> An immutable object is an object that cannot be modified once it has
> been created,
> until it is destroyed. Stated otherwise, operations on an immutable
> object are guaranteed to
> have no side effects. An immutable object may however live in the heap
> or on the stack, unlike
> true constant objects.

I don't agree there exist such "true" constant objects.

If there was a C compiler which decides to place some string constant
onto the stack (assuming the compiled program will run correctly, of
course), then such a string is not a "true" constant? Why not? The
program has the same semantics, why do you care so much about how the
compiler implements the constant?

> For example, IIRC, in Haskell all types are
> essentially immutable,
> because side effects are disallowed, however, most types are not true
> constants as they live
> on the stack or heap)

I guess I am not a true follower of your religious teachings about
"true" constants ...

> Any constant object is trivially immutable. However, an immutable
> object may not be constant.
> This is a crucial difference. The const modifier in C /C is a huge
> misnomer, and a result of

In C/C++, "const char*" actually means that the string is either
mutable or immutable (you can read from it). Whereas "char*" means
that the string is known to be mutable (you can both read from it and
write to it).

Yes, it is totally confusing.

> this confusing immutability with constancy. Not to mention that I
> think it's an attempt at
> avoiding certain common errors in accessing pointers in C/C++. Errors
> which are not possible
> in Go, unless you use unsafe.

What "common errors in accessing pointers" do you mean?

> So I feel like I'm not convinced that having an immutable keyword
> would do any good in Go.

No problem. I am *not* forcing you to accept my viewpoint.

> Could you perhaps think of an example in Go (not C or C++) that would
> benefit from it? Go is still young,
> so if you make a convincing case, I think your proposal may be
> considered.

1. I am afraid I am not there quite yet. In other words, I am
incapable of providing a consistent proposal.

2. It is probable that many people wouldn't like it. (That's *not*
because I am a notorious pessimist or anything like that. The hunch I
am using here is that many people don't like complex programming
languages.)

> Perhaps it would be better
> to start a new thread on this subject as we're hijacking this one.

[Esko Luontola]

On Apr 21, 7:54 pm, Beoran <beo...@gmail.com> wrote:
> So I feel like I'm not convinced that having an immutable keyword
> would do any good in Go.
> Could you perhaps think of an example in Go (not C or C++) that would
> benefit from it? Go is still young,
> so if you make a convincing case, I think your proposal may be
> considered. Perhaps it would be better
> to start a new thread on this subject as we're hijacking this one.

Immutability makes concurrency much easier, because you can freely
pass immutable objects to other threads without risk of concurrency
bugs. No need to worry about synchronization and which thread
currently "owns" the object, because access to immutable objects is
trivially synchronized. Since Go is meant for concurrency programming,
immutability would be very useful.

Immutability also makes it easier to reason about the state of an
object, because the state will not change after it has been created.
It would make Go code easier to read and understand.

[⚛]

On Apr 21, 8:16 pm, Henrik Johansson <dahankz...@gmail.com> wrote:
>
> If there is a distinct technical advantage to having a keyword for
> immutability then I'm all for it otherwise "less is more".

I am afraid, the truth is there is no such technical advantage here.
The only advantage is that you would be able to express, directly in
the language, some ideas that you were unable to express before. That
is all there is. Just like support for inheritance in object-oriented
languages enables you to express the idea that "Square is a Rectangle,
Rectangle is a Polygon, Polygon is a Shape".

[Ian Lance Taylor]

⚛ <0xe2.0x...@gmail.com> writes:

> On Apr 21, 3:53 pm, Ian Lance Taylor <i...@google.com> wrote:
>> ⚛ <0xe2.0x9a.0...@gmail.com> writes:
>> > Q: How does Go deal with this?
>> > A: It does not have any support for immutability in the type system.
>>
>> In my opinion, the type system is not the right place to express
>> immutability.  Immutability is a characteristic of an object, not a
>> type.
>
> Yes, that is a plausible explanation. But it shows that the main issue
> here seems to be the meaning of the term "type" and of the term "type
> system". It is probable that my understanding is completely different
> from your understanding.
>
> In my opinion, the "type of an object X" is equivalent to "compile-
> time knowledge about the nature of X".

I would say that in a type-safe language like Go, a type is something
that can be explicitly expressed in the language. The compiler can
know many things about an object which are not expressed in the
language; I would not call those part of the object's type.

Ian

[Eleanor McHugh]

And even were that the case, a definition of type based exclusively on compile-time knowledge misses the fact that runtime behaviour of a type may be sufficiently complex that no practicable set of compile-time rules can determine its correctness.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason

[Beoran]

Dear ⚛,

I understand your points very well, I guess we're just arguing
semantics,
mostly. I don't hold any opinions religiously, I love to be proven
wrong,
so I 'm sorry if you felt I was coming on a bit strongly

I concede that I was making several mistakes in my reply. So I won't
argue them father. My main goal was to show that C/C++ const keyword
is
not very helpful in implementing immutability.

As for your hesitation making your own proposal, please don' t let
that stop you.
It will be useful for yourself to formulate what you want in language
to help with
immutablity. As for ease of use, const in C++ is indeed a bother what
with const
correctness, but D has an immutable keyword that seems to be easier in
use.

Kind Regards,

B.

[⚛]

On Apr 22, 1:00 am, Ian Lance Taylor <i...@google.com> wrote:
> ⚛ <0xe2.0x9a.0...@gmail.com> writes:
> > In my opinion, the "type of an object X" is equivalent to "compile-
> > time knowledge about the nature of X".
>
> I would say that in a type-safe language like Go, a type is something
> that can be explicitly expressed in the language.  The compiler can
> know many things about an object which are not expressed in the
> language; I would not call those part of the object's type.

May I ask you to give a concrete example (presumably, in the context
of Go)? One of the "many things about an object which are not
expressed in the language".

[Beoran]

Dear ⚛,

Just a quibble, but by using inheritance, it's not possible to
correctly say that a Square is a Rectangle and a Rectangle is a
Polygon. Refer to the circle-ellipse problem to see why:
http://en.wikipedia.org/wiki/Circle-ellipse_problem.

To put it in short: a Rectangle is a restricted kind of Polygon, since
a Rectangle has less capabilities than a Polygon, hence it can do less
than a polygon. Likewise a square is a restricted kind of rectangle.
When using inheritance, a subtype must be able to do more that the
supertype due to the Liskov substitution principle. This makes
inheritance actually less useful for modeling such problems.

Kind Regards,

B.

[⚛]

On Apr 22, 1:40 am, Eleanor McHugh <elea...@games-with-brains.com>
wrote:

> On 22 Apr 2010, at 00:00, Ian Lance Taylor wrote:
> > I would say that in a type-safe language like Go, a type is something
> > that can be explicitly expressed in the language.  The compiler can
> > know many things about an object which are not expressed in the
> > language; I would not call those part of the object's type.
>
> And even were that the case, a definition of type based exclusively on compile-time knowledge misses the fact that runtime behaviour of a type may be sufficiently complex that no practicable set of compile-time rules can determine its correctness.

I think this is a misunderstanding. The "compile-time knowledge" does
*not* imply that the type system is incapable of dealing with
knowledge obtainable only at run-time. There exists an obvious (and
the only one, I think) method enabling one to tap into the run-time-
only knowledge, at compile-time. Many (most?) programming languages
are *not* build around this principle, which perhaps makes people
(you) think it is non-sense and cannot be done.

It would be best if you provide a concrete example of, as you say,
"runtime behaviour of a type sufficiently complex that no practicable

set of compile-time rules can determine its correctness".

[⚛]

On Apr 22, 9:34 am, Beoran <beo...@gmail.com> wrote:
> Dear ⚛,
>
> Just a quibble, but by using inheritance, it's not possible to
> correctly say that a Square is a Rectangle and a Rectangle is a
> Polygon. Refer to the circle-ellipse problem to see why:http://en.wikipedia.org/wiki/Circle-ellipse_problem.

Well, actually, the Wikipedia article is totally wrong. You may ask,
what makes me say that? Well, I can safely make such a statement
because I designed a programming language with support for inheritance
which does *not* suffer from the Circle-Ellipse problem. I am *not*
saying the solution is earthshaking or something, in fact one of the
main principles on which my version of inheritance is based was
mentioned by at least one other person, and if I searched the Internet
I would possibly find other people who proposed the same thing. But in
respect to most mainstream object-oriented languages, I can safely
assert that their model of inheritance is inferior.

In programming language design, you can do basically two things:

(1) Design the language around truths.

(2) Design the language in a more arbitrary way, without the goal of
attaining an understanding what the truths are.

It is (1) I am striving for. All languages, including C++/etc, try to
have some model of the world, that is OK - but many of them fall into
the 2nd category. It is about whether you have an alarm in your head
preventing you from crossing the line between adherence to facts and
ignorance to facts.

As for Go, I think its position is closer to (2) more than I would
like.

> To put it in short: a Rectangle is a restricted kind of Polygon, since
> a Rectangle has less capabilities than a Polygon, hence it can do less
> than a polygon. Likewise a square is a restricted kind of rectangle.
> When using inheritance, a subtype must be able to do more that the
> supertype due to the Liskov substitution principle. This makes
> inheritance actually less useful for modeling such problems.

I think your mind is in a state of deep confusion ...

[Beoran]

Well, first of all, I'd love to see the solution used in the
programming language you designed, so could you please give me a link
or some explanation how it works? I tried to Google for it but didn't
find it.

I don't know why you disagree with that article. The circle/ellipse
problem does apply for all languages that use "classic style"
inheritance, like C++ or Java do. The fact that you designed a
language that does inheritance in a different way doesn't disprove
that. It only shows that a different approach than classic inheritance
is needed.

I agree that it would be nice to have a programming language that
makes it easy to model reality. So I'd love to see a language that
follows your option 1) in design. However, this is not so trivial to
design. This is because, in general, reality is really difficult to
model, as it is generally non-hierarchical. That's why most
programming languages are content with giving you tools that make it
easier to use the hardware in a somewhat abstracted way in stead,
which leads to your option 2).

As for my "confusion", I think it's more likely we are
misunderstanding each other. Sorry, English is not my native language,
sometimes it's hard for me to express something correctly.

Kind Regards ,

B.

[Ian Lance Taylor]

⚛ <0xe2.0x...@gmail.com> writes:

> On Apr 22, 1:00 am, Ian Lance Taylor <i...@google.com> wrote:
>> ⚛ <0xe2.0x9a.0...@gmail.com> writes:
>> > In my opinion, the "type of an object X" is equivalent to "compile-
>> > time knowledge about the nature of X".
>>
>> I would say that in a type-safe language like Go, a type is something
>> that can be explicitly expressed in the language.  The compiler can
>> know many things about an object which are not expressed in the
>> language; I would not call those part of the object's type.
>
> May I ask you to give a concrete example (presumably, in the context
> of Go)? One of the "many things about an object which are not
> expressed in the language".

The compiler can infer facts about an object from the way that it is
used. A simple example:

func local(i int) int {
return i + 1
}
func Public() int {
return local(1)
}

Suppose the only call to local in the package is the one in Public.
In that case, the compiler knows that the value i in local is always
1. gccgo is able to rewrite local accordingly, eliminating i
entirely. This will happen even in more complex cases where local can
not be inlined for some reason. It does not follow that the type of i
is the constant 1. The way that I use the word, the type of i is
still int.

Ian

[Peter Froehlich]

On Thu, Apr 22, 2010 at 5:35 AM, ⚛ <0xe2.0x...@gmail.com> wrote:
> Well, actually, the Wikipedia article is totally wrong. You may ask,
> what makes me say that? Well, I can safely make such a statement
> because I designed a programming language with support for inheritance
> which does *not* suffer from the Circle-Ellipse problem.

Show us the language. Or stop wasting our time anonymously.
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

[Carl]

On 22 Apr., 11:35, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:

> Well, actually, the Wikipedia article is totally wrong.

I think Wikipedia is always happy to listen your criticisms, so with
your expertise on Programming Languages I think you might just be the
right kind of person to go to Wikipedia and rewrite that article, they
will be very happy to have you I am sure.

> You may ask,
> what makes me say that? Well, I can safely make such a statement
> because I designed a programming language with support for inheritance
> which does *not* suffer from the Circle-Ellipse problem. I am *not*
> saying the solution is earthshaking or something, in fact one of the
> main principles on which my version of inheritance is based was
> mentioned by at least one other person, and if I searched the Internet
> I would possibly find other people who proposed the same thing. But in
> respect to most mainstream object-oriented languages, I can safely
> assert that their model of inheritance is inferior.

Thats fantastic, can you please provide a Link to where everybody can
have a look at the Language that you designed?

Are you running a forum somewhere about that language that you have
designed? Maybe some folks here would give it a test run and then
write l you their feedback about it in the corresponding language
forum for it.

> In programming language design, you can do basically two things:
>
> (1) Design the language around truths.
>

Nope, from my experience languages are designed around concise
Requirements, usually business requirements or at least scientific.
Truth has nothing to do with it, that idea in fact seems rather a
"Religious" notion to me.

> I think your mind is in a state of deep confusion ...

Actually I appreciate this forum for its very positive tone and high
level of professionalism and I for one would like it to stay that
way.

By the way, why do you use such a cryptic name?

[⚛]

On Apr 21, 6:55 pm, Hans Stimer <hans.sti...@gmail.com> wrote:
> A+
> ---
> * Fast turnaround - blinding fast compile/link/run cycle

I just tried to compile GZIP with Tiny C Compiler 0.9.25. The "only"
problem is that the resulting binary segfaults. But, just for fun,
here are the timings:

tcc 0.9.25:
real 0m0.145s
user 0m0.127s
sys 0m0.038s

gcc-4.5.0 -O2:
real 0m1.682s
user 0m2.619s
sys 0m0.238s

gcc-4.5.0 -O0:
real 0m0.767s
user 0m0.991s
sys 0m0.173s

2.619 / 0.127 = 20.62
0.991 / 0.127 = 7.8

So, it is possible for the translation of C code into binary x86 code
to be 8-20x faster.

I am not mentioning this because the Go compiler is slow - I am
mentioning it because people seem to be *unjustly* inclined to think
that C cannot be compiled any faster.

In fact, a seemingly insane claim such as "C can be compiled 100x
faster than what GCC does" has to be taken quite seriously. The
resulting code would not be optimized, of course, since optimization
takes time.

[Beoran]

I found something:

https://c2.com/cgi/wiki?CecilLanguage

This language solves the circle ellipse problem by allowing
PredicateTyps, that is,
dynamically changing the predicate class(es) of the object at runtime.
It's interesting, but
can't be done at compile time for obvious reasons.

⚛, did you design something like this this?

Kind Regards,

B.

[Uriel]

On Thu, Apr 22, 2010 at 8:12 PM, ⚛ <0xe2.0x...@gmail.com> wrote:
[snip]

> So, it is possible for the translation of C code into binary x86 code
> to be 8-20x faster.
>
> I am not mentioning this because the Go compiler is slow - I am
> mentioning it because people seem to be *unjustly* inclined to think
> that C cannot be compiled any faster.
>
> In fact, a seemingly insane claim such as "C can be compiled 100x
> faster than what GCC does" has to be taken quite seriously. The
> resulting code would not be optimized, of course, since optimization
> takes time.

Nothing of this is news to the developers of Go: ken's C compilers for Plan 9[1]
which have been used for over two decades and on which the gc Go compilers
are based are magnitude orders faster than g cc, they don't do as many
'optimizations', but they don't produce broken code as often as gcc
does either.

But the real comparison should be with c++, and while some c++
compilers might be a bit faster than g++, they are all still
incredibly slow compared to the Go compilers.

uriel

[1]: http://doc.cat-v.org/bell_labs/new_c_compilers/

[soren renner]

> Go is not a language to develop a kernel (because you need full
> control about memory so you can't use a language with GC).

Native Oberon and AOS/Bluebottle/A2 (ETHZ keeps changing the name) are
two operating systems written in languages with garbage collection:
Oberon and Active Oberon respectively. There is a pseudomodule SYSTEM
(actually implemented in the compiler and not as a module) which
provides unsafe memory access and pointer arithmetic. This unsafe
module is needed for parts of the OS, notably the garbage collector
itself. Yet one may be perfectly confident that no code breaks pointer
safety -- provided that it does not import SYSTEM.

[⚛]

On Apr 22, 4:36 pm, Peter Froehlich <peter.hans.froehl...@gmail.com>
wrote:

> On Thu, Apr 22, 2010 at 5:35 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> > Well, actually, the Wikipedia article is totally wrong. You may ask,
> > what makes me say that? Well, I can safely make such a statement
> > because I designed a programming language with support for inheritance
> > which does *not* suffer from the Circle-Ellipse problem.
>
> Show us the language. Or stop wasting our time anonymously.

I choose to stop wasting your time.

[⚛]

On Apr 23, 1:43 am, Uriel <ur...@berlinblue.org> wrote:
> Nothing of this is news to the developers of Go: ken's C compilers for Plan 9[1]
> which have been used for over two decades and on which the gc Go compilers
> are based are magnitude orders faster than g cc, they don't do as many
> 'optimizations', but they don't produce broken code as often as gcc
> does either.

When you open the title page http://golang.org/ the first thing you
will notice is the text "Slow compiles? Watch this". If it isn't news
to the developers of Go that C can be compiled substantially faster,
then why would they put "Slow compiles" on the front page. It does not
make any sense, unless:

- I assume Go developers *believe* C/C++/whatever *cannot* be compiled
substantially faster, or

- I assume Go developers *know* C/C++/whatever *can* be compiled
substantially faster, in which case the front page is there to deceive
on purpose.

Or is there a 3rd option?

[⚖ Alexander "Surma" Surma]

> Or is there a 3rd option?

They (i.e. the other languages) *can* be compiled faster, but no one
provides a compiler which actually *is* faster.

Surma

[chris dollin]

On 23 April 2010 09:27, ⚛ <0xe2.0x...@gmail.com> wrote:

When you open the title page http://golang.org/ the first thing you
will notice is the text "Slow compiles? Watch this". If it isn't news
to the developers of Go that C can be compiled substantially faster,
then why would they put "Slow compiles" on the front page. It does not
make any sense, unless:

- I assume Go developers *believe* C/C++/whatever *cannot* be compiled
substantially faster, or

- I assume Go developers *know* C/C++/whatever *can* be compiled
substantially faster, in which case the front page is there to deceive
on purpose.

Or is there a 3rd option?

At least one more: that C and C++ /can/ be compiled faster, but
typically /are not/.

(I suspect that it's C++ rather than C that's the target of the "build
time" comments, though).

Chris

--
Chris "allusive" Dollin

[Gabriel Diaz]

Hello

May be that phrase is only there to the ones which are suffering slow compiles. If you don't, then that's not for you.

slds.

gabi

[Xiance SI(司宪策)]

In my humble opinion, C and C++ are different cases.

C compilation could be substantially faster than C++, yes, totally agreed. I've switched a whole
project from C++ to C, just because the slow compiling problem. But C also lacks
certain object-oriented features (classes, abstract classes and constructor/desctructor,
 stl, ....), making development less efficient.

Go has the same (even more than..) handy features as C++, while compiles as fast (or
even faster) than C. I think this point make sense quite obviously, at least to me.

Especially, it makes sense when your project takes minutes to build while the only thing
you can do is reading group emails or Google Reader. :)

wishes,
Xiance

[Joseph Poirier]

Actually, the first thing I notice when I open the title page is the big "GO" toward the top. The second thing I notice is the little mascot at the top left. The third thing I notice is the last update date/time. The fourth thing I notice is the "expressive, concurrent, garbage-collected" text. The fifth thing I notice is the blue code snippet. The sixth thing I notice is the "Getting Started" text. The seventh thing I notice is the picture of Russ. The eight thing I notice is the "From the Go Blog" box. The ninth thing I notice is "...simple." The tenth thing I notice is "...fast." The eleventh thing I notice is "...safe."  The twelfth thing I notice is "...concurrent." The thirteenth thing I notice is "...fun." The fourteenth thing I notice is "...open source." The fifteenth thing I notice is the documents listing. Sorry but one of the last things I notice is what you mentioned. 

Either your projecting http://tinyurl.com/a7a2r, or trolling? There is _no_ 3rd option. 

-joe 

[⚛]

On Apr 23, 11:33 am, Joseph Poirier <jdpoir...@gmail.com> wrote:
>
> Actually, the first thing I notice when I open the title page is the big
> "GO" toward the top. The second thing I notice is the little mascot at the
> top left. The third thing I notice is the last update date/time. The fourth
> thing I notice is the "expressive, concurrent, garbage-collected" text. The
> fifth thing I notice is the blue code snippet. The sixth thing I notice is
> the "Getting Started" text. The seventh thing I notice is the picture of
> Russ. The eight thing I notice is the "From the Go Blog" box. The ninth
> thing I notice is "...simple." The tenth thing I notice is "...fast." The
> eleventh thing I notice is "...safe."  The twelfth thing I notice is
> "...concurrent." The thirteenth thing I notice is "...fun." The fourteenth
> thing I notice is "...open source." The fifteenth thing I notice is the
> documents listing. Sorry but one of the last things I notice is what you
> mentioned.

You forgot to mention that the picture of Russ used to have the habit
of changing over time (video preview or something). If you don't know
what that means, I will make it explicit: it means that *whatever* you
were paying attention to at the moment the image changed, your
peripheral vision notified you about the change. This made your
subconscious mind begin to wonder what is happening - since the page
was otherwise static - the visual change has to have some meaning, at
least that's what your brain thought. Therefore, in a matter of
milliseconds your eye ball started to move and landed on the picture
of Russ. After this, you began to consciously analyse what has
happened, by examining the picture and its surrounding context. The
surrounding context contains a text displayed in a large font, and the
text itself reads: "Slow compiles? Watch this".

(I was being disturbed by this, so I used AdBlockPlus to remove the
distracting picture.)

> Either your projecting http://tinyurl.com/a7a2r, or trolling? There is _no_
> 3rd option.

That is nice. Now, how in the world are you going to persuade me that
it is not you who, or even the entire society, that is "projecting"?
It's like trying to disprove solipsism - it is obvious that it is
impossible to disprove.

[Eleanor McHugh]

Dear *,

My statement was a colloquial rephrasing of Rice's Theorem, itself an application of Gödel's theorems, and as such it expresses a fundamental principle of computability in Turing machines. Where exactly the boundary of non-trivial complexity appears will depend on which language happens to be used to implement a given program and the nature of the problem it solves, but there is no magic bullet which can obviate this limitation when that degree of complexity is reached.

If you believe you do have such a magic bullet then you should consult a good mathematician - a theorem which overturned Gödel's work would certainly be welcome news in some quarters.

Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason

[Beoran]

Dear ⚛,

I said it before, if you designed a language that solves the circle
ellipse problem, I'd love to hear from it as this is quite
extraordinary. You seem to be someone who likes the truth, so I hope
you will provide evidence of the of the truth of your rather
extraordinary claims.

Kind Regards,

B.

[⚛]

On Apr 23, 2:15 pm, Eleanor McHugh <elea...@games-with-brains.com>

wrote:
> On 22 Apr 2010, at 08:56, ⚛ wrote:
>
> > On Apr 22, 1:40 am, Eleanor McHugh <elea...@games-with-brains.com>
> > wrote:
> >> On 22 Apr 2010, at 00:00, Ian Lance Taylor wrote:
> >>> I would say that in a type-safe language like Go, a type is something
> >>> that can be explicitly expressed in the language.  The compiler can
> >>> know many things about an object which are not expressed in the
> >>> language; I would not call those part of the object's type.
>
> >> And even were that the case, a definition of type based exclusively on compile-time knowledge misses the fact that runtime behaviour of a type may be sufficiently complex that no practicable set of compile-time rules can determine its correctness.
>
> > I think this is a misunderstanding. The "compile-time knowledge" does
> > *not* imply that the type system is incapable of dealing with
> > knowledge obtainable only at run-time. There exists an obvious (and
> > the only one, I think) method enabling one to tap into the run-time-
> > only knowledge, at compile-time. Many (most?) programming languages
> > are *not* build around this principle, which perhaps makes people
> > (you) think it is non-sense and cannot be done.
>
> > It would be best if you provide a concrete example of, as you say,
> > "runtime behaviour of a type sufficiently complex that no practicable
> > set of compile-time rules can determine its correctness".
>
> Dear *,
>
> My statement was a colloquial rephrasing of Rice's Theorem, itself an application of Gödel's theorems, and as such it expresses a fundamental principle of computability in Turing machines. Where exactly the boundary of non-trivial complexity appears will depend on which language happens to be used to implement a given program and the nature of the problem it solves, but there is no magic bullet which can obviate this limitation when that degree of complexity is reached.

Seems like the problem, again, lies in the meaning of the word "type".
To different groups of people it seems to mean very different things.
Let me describe two of them, one is the view of a programmer and the
other of a mathematician.

1. Programmer's view: Type is something that is *engineered*. It is
something that is created on purpose, deliberately, the types are
"nominal". Programmer decrees that such a type shall exist. For
example, the type/class "Window" is created to represent things which
resemble the shape of a real-world window, with operations such as
"moveBy(X,Y)", "getTitle()", etc. Instances of the type "Window" exist
because they were allowed to exist, and the type "Window" always
exists *prior* to any instance of that type. However that does not
mean a new type cannot be created ex-post, when the programmer
recognizes that there is a need for it.

2. Mathematician's view: Type is something that is *derived*. It is
something that already exists, irrespective of whether the
mathematician wanted it to exist or not. For example, the type/class/
set "TerminatingPrograms" is the set of programs which are guaranteed
to terminate (i.e: halt). Given a particular computer program P, the
mathematician will ask the question: is the program P of type
"TerminatingPrograms"? Contrary to a programmer, who simply decreed
that e.g. "w" shall be the name of a concrete instance of type
"Window" simply by writing "w := new Window()", a mathematician cannot
simply at will decree that P is of type "TerminatingPrograms". The
type "TerminatingPrograms" and any of its instances exist
*simulatenously*.

In my previous posts, the word "type" was used in the sense of (1).

[⚛]

Correction: simultaneously.

[Jessta]

Do you realise that your two meaning are actually the same?
The programmer decrees that there is a type "Window" with certain attributes.
The mathematician decrees that there is a type "Terminating Programs"
with certain attributes.

A mathematician may start with something and attempt to find the type
of that thing.
A programmer usually starts by stating the assumption that the thing
is of a certain type, describes the thing and has the compiler tell
them if the thing isn't of that type.

The concept of 'type' is the same for both.


- jessta
--
=====================
http://jessta.id.au

[Carl]

On 23 Apr., 10:27, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> On Apr 23, 1:43 am, Uriel <ur...@berlinblue.org> wrote:
>
> > Nothing of this is news to the developers of Go: ken's C compilers for Plan 9[1]
> > which have been used for over two decades and on which the gc Go compilers
> > are based are magnitude orders faster than g cc, they don't do as many
> > 'optimizations', but they don't produce broken code as often as gcc
> > does either.
>

> When you open the title pagehttp://golang.org/the first thing you

> will notice is the text "Slow compiles? Watch this". If it isn't news
> to the developers of Go that C can be compiled substantially faster,
> then why would they put "Slow compiles" on the front page. It does not
> make any sense, unless:
>
> - I assume Go developers *believe* C/C++/whatever *cannot* be compiled
> substantially faster, or
>
> - I assume Go developers *know* C/C++/whatever *can* be compiled
> substantially faster, in which case the front page is there to deceive
> on purpose.
>
> Or is there a 3rd option?

Dear ⚛ <0xe2.0x9a.0...

the third and ... options

The Golang project is quite clear about the fact that their Project is
still experimental stages, that means compile speeds can change
anytime, for the better or for worse.

I came across Golang because I read about it in the news, then I
watched the approximately 1 hour video on youtube.com by Rob Pike
about Golang, which was very dense ( a lot of material packed in very
short time). Then I did research on some of the team members working
on the project and discovered that they have made a name for
themselves in this industry. I don't remember it exactly, but somehow
along the way I researched that Ken Thompson was working on that
project too. I got interested because I knew about their previous work
and its direction.

What interests me most about Golang is its concurrency functions, I
have hopes that it may solve some hardware economics problems in the
area of Multi-core Processors.

In the beginning I did not not care much about compile speeds, its
nice if its fast, but my expectations are pretty realistic. If it has
to do serious optimizing for various hardware architectures, things
will have to get slower, as in heavily optimizing deployment
compilers. On the other hand if concurrent compilation is a
possibility and it is implemented in a concurrent language - like
golang - then you may see increases of compile speeds by orders of
magnitude, depending on how many cores you have on your computer, but
that is likely still a research topic, as the whole language still
is.

What I appreciate about Golang is its very high level of activity, and
short release intervals, it is moving along very fast from a
development perspective.

I also find it very respectable that key developers of Golang are very
active in this forum and they are very open about what they are doing
and actively supporting anyone that has questions and wants to try out
the language. I find that very honorable and there is nothing
deceptive going on whatsoever.

If you have a language that compiles faster and gets the job done for
you, then good for you! Computer programming languages are not
somekind of dogma, they are tools to solve specific problems. So if
you already have a Programming Language that solves your problem, then
be happy.

kind Regards,

[Andrew Francis]

Hi :

I am new to Go. However I use Stackless Python which as a similar
concurrency model to Go. Stackless is used in MMORPGs like EVE. Also
the I believe that Ironport uses a variation of Stackless. What both
systems have in common is mass concurrency. I guess Go could be used
for those sorts of systems as well. Myself. I use Stackless Python to
prototype stuff dealing with business/process orchestration. This is
associated with Long Running Transactions and Complex Event
Processing. I can see Go being successful in this area.

Cheers,
Andrew

On Apr 17, 7:06 am, Xiance SI(司宪策) <adam...@gmail.com> wrote:
> Hi, calling for casual discussion :)
>
> IMO, a killer application plays an important role in the success (or just
> the survival) of a language: C has *NIX,  Ruby has ROR, and Objective-C
> has iPhone, you could name more examples. After the success of the
> killer application, the language may attract more coders, and grow into a
> widely used one (like C/C++), or just stick to its niche application (like
> Ruby).
>
> What would be GO's killer application, that is hungry for a (better)
> solution,
> has great impact, and fits in GO's profile?
>
> wishes,
> Xiance
>
> PS: The topic may have already been discussed,  but I cannot read the
> history archives, since Google Groups' Web access is blocked here. If it had
> been discussed, I'm sorry and please just ignore my post.

[TerryP]

Personally, I think the killer application for Go, is the PROGRAMMER.
Get more people interested in using this language, rather than
something else. Decreasing the barrier to utilising it on new projects
by building up libraries and bindings is probably the best lurch
forward at this point (next to a native windows port). The more coders
like Go and the less issues they have to do it, the more inclined they
will be to use it on projects: perhaps Go should infect the open
source world? Arguably after hitting critical mass, it would be better
posed for a wider adoption on commerical projects.


Go could fit very elegantly in places that I see C, C++, C#, Objective-
C, and Java falling into place -- and with much less annoyance! But Go
just doesn't fit the business or logistical issues well enough in
every spot.


Unless someone writes the next sold for multi-million dollar web app
in Go, I just don't see a big enough market. PHP (barf) dwarfs most
job openings I've seen for web development, along side more
enterprising Java and .NET related setups that also comprise a big
chunk. Whose Go got to compete with in the web arena, Python? lol.


The mention of gaming programming in this thread was rather
interesting, but IMHO, I think C# is better suited (at present) for it
then Go. Consoles are the big shiznit in the market place but *true*
gamers prefer PCs, which amounts to a large amount of Windows boxes.
That makes CLI/.NET stuff a viable possibility. The number of C++
libraries and 'kits out there just make C++ the most commercially
viable language, unless you're using something built on top of it,
such as how UnrealScript comprises the majority of code needed for an
Unreal Engine game. I still remember when it was Assembly. Whatever
some people say about C#, it has a better chance for impacting C++
usage than Go does in game development, at least on the serious level.
You can also adapt it for scripting much more readily than Go. There
are already commercial grade solutions available in C#, that would put
mere OpenGL or SDL bindings to dust, on any list of pro's for adapting
language XYZ for game projects. Of course, save the, "I want to do it
in Go!" factor ;).


If one could do very sexy Android development in Go, that might be
worth while.


I'm not even going to mention how much cursing I hear from friends
about coding for Android and the iPhone.

--
TerryP.
Just Another Computer Geek.