Go Programming Language
Robbert Haarman
I just stumbled across the Go programming language that Google is
developing: http://golang.org/
It seems really interesting. Some features to whet your appetite:
- Fast compilation
- Fast generated code
- Type and memory safety
- Lightweight concurrency
- Interface inference (i.e. you don't have to declare that your type
has a certain interface; if the right methods are provided, it works)
For a minute, I was afraid that I could as well halt my great plans for
my Mana programming language, but, luckily, Go still seems different
enough.
Anyway, I just wanted to bring Go to your attention. What do you all think
about it?
Regards,
Bob
--
67.7234597% of statistics are made up.
Dmitry A. Kazakov
Looking at its hello-world:
* curly brackets;
* parenthesis in parameterless subprograms;
* escape sequences in (Unicode?) string literals;
* function meaning a procedure ("func");
* plain identifiers to name a package (main) and a quoted string to import
another ("fmt")
It should have taken a lot of work to make so many things wrong in just 7
lines of source... (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Mike Austin
Dmitry, I agree with you about some of these, but do you mind going into more
detail? Are you just tired of curly braces? Are they positioned oddly on your
keyboard? Were you traumatized as a child by them? :)
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> [39 quoted lines suppressed]
>
> Dmitry, I agree with you about some of these, but do you mind going into more
> detail?
If you want.
> Are you just tired of curly braces? Are they positioned oddly on your
> keyboard? Were you traumatized as a child by them? :)
Yes, I was, when in my first book about C (that was K&R C, so you can guess
how young I was then (:-)), I read
#define BEGIN {
#define END }
But there are lots of languages, which do the job of obfuscation much
better. Consider J, a program in J looks like a disk boot sector dump. For
example:
perm =: ! A.&i. ] NB. all permutations of integers 0 to y
comb2 =: (, #: I.@,@(</)&i.)~ NB. all size 2 combinations of integers 0 to
y
mask =: [ */@:~:&(|@-/) {
queenst=: comb2 (] #"1~ mask)&.|: perm
(I have no idea what this code does, allegedly it solves 8-Queens. Who
knows, maybe it indeed does... You cannot compete with THIS. It is just
about perfect! (:-))
Then Unicode opens so many new opportunities! Curly brackets, huh, authors
of Go could take Klingon letters to encrypt the keywords "if", "while",
"package" etc. Why just "begin" and "end"? (:-))
The recent Ada (2005) standard also introduced Unicode. Lo, now you can
declare three variables:
declare
A : Integer;
οΏ½ : Integer;
οΏ½ : Integer;
begin
A := 1; -- Guess, which one gets assigned?
(1st A is Latin, 2nd is Greek capital alpha, 3d is Cyrillic A)
bartc
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:1pg22n5w1d7df$.1szi5wcp3lbm1.dlg@40tude.net...
> On Wed, 11 Nov 2009 19:52:22 -0800, Mike Austin wrote:
>> Dmitry, I agree with you about some of these, but do you mind going into
>> more
>> detail?
...
> The recent Ada (2005) standard also introduced Unicode. Lo, now you can
> declare three variables:
>
> declare
> A : Integer;
> οΏ½ : Integer;
> οΏ½ : Integer;
> begin
> A := 1; -- Guess, which one gets assigned?
Obviously the first one..
>
> (1st A is Latin, 2nd is Greek capital alpha, 3d is Cyrillic A)
This actually makes sense. Of course it would be bad programming practice,
as would using names such as I and l, or IO, IO, l0 and lO. (On my sans
serif font, all these I's and l's look the same.)
It would be slightly better in a font using distinct character glyphs for
the 3 A's.
--
Bartc
Dmitry A. Kazakov
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
> news:1pg22n5w1d7df$.1szi5wcp3lbm1.dlg@40tude.net...
>> On Wed, 11 Nov 2009 19:52:22 -0800, Mike Austin wrote:
>
>>> Dmitry, I agree with you about some of these, but do you mind going into
>>> more detail?
> ...
>> The recent Ada (2005) standard also introduced Unicode. Lo, now you can
>> declare three variables:
>>
>> declare
>> A : Integer;
>> 嚙瘩 : Integer;
>> 嚙瘩 : Integer;
>> begin
>> A := 1; -- Guess, which one gets assigned?
>
> Obviously the first one..
Hmm, actually I typed the third one (the code point 0410 hex). It would be
fun to debug such code...
>> (1st A is Latin, 2nd is Greek capital alpha, 3d is Cyrillic A)
>
> This actually makes sense. Of course it would be bad programming practice,
Why to encourage bad practices? BTW, in Ada, for example, "and" is a
reserved keyword, not because that is syntactically required, but because
it would be a bad practice to use it as an identifier. Isn't Cyrillic A a
far worse practice? Anyway with Unicode you can have all dear reserved
words back! Just type Cyrillic '嚙踝蕭' or Cyrillic '嚙踝蕭' in "and", here you are.
I think that Unicode identifiers is a bad idea. I don't want to read
programs with identifiers in Russian (though it is my mother tongue), even
less in the Cretan Linear A script...
bartc
> On Thu, 12 Nov 2009 12:30:47 GMT, bartc wrote:
>
>> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
>> news:1pg22n5w1d7df$.1szi5wcp3lbm1.dlg@40tude.net...
>>> On Wed, 11 Nov 2009 19:52:22 -0800, Mike Austin wrote:
>>
>>>> Dmitry, I agree with you about some of these, but do you mind going
>>>> into
>>>> more detail?
>> ...
>>> The recent Ada (2005) standard also introduced Unicode. Lo, now you can
>>> declare three variables:
>>>
>>> declare
>>> 嚙瘩[2] : Integer;
>>> 嚙瘩[3] : Integer;
>>> begin
>>> A[4] := 1; -- Guess, which one gets assigned?
>>
>> Obviously the first one..
>
> Hmm, actually I typed the third one (the code point 0410 hex). It would be
> fun to debug such code...
I used Notepad to search for the text A[1] and it found A[4]. Pasting it
into Wordpad, both A[2] and A[3] had accents, but not A[1] or A[4].
Looking at a dump (from pasting it into Wordpad and saving as Unicode text),
A[1] and A[4] both had code 41 hex (ie the usual Ascii A), while A[2] and
A[3] both seemed to be code C1 hex.
Maybe you missed a zero off the 0410 hex... Either that or the message got
mangled along the way.
>>> (1st A is Latin, 2nd is Greek capital alpha, 3d is Cyrillic A)
>>
>> This actually makes sense. Of course it would be bad programming
>> practice,
>
> Why to encourage bad practices? BTW, in Ada, for example, "and" is a
> reserved keyword, not because that is syntactically required, but because
> it would be a bad practice to use it as an identifier. Isn't Cyrillic A a
> far worse practice? Anyway with Unicode you can have all dear reserved
> words back! Just type Cyrillic '嚙踝蕭' or Cyrillic '嚙踝蕭' in "and", here you
> are.
>
> I think that Unicode identifiers is a bad idea. I don't want to read
> programs with identifiers in Russian (though it is my mother tongue), even
> less in the Cretan Linear A script...
I used to allow some European characters (such as accented versions of the
vowels) in identifiers in my script languages; my users were in Europe so
why not?
It's the choice of a programmer whether or not to use English for
identifiers. And certainly he'd want to use Unicode for string literals and
comments, although this was probably already allowed.
--
Bartc
Dmitry A. Kazakov
> I used to allow some European characters (such as accented versions of the
> vowels) in identifiers in my script languages; my users were in Europe so
> why not?
Because then your language should consider
Str�me
Stroeme
same identifier, since in German � = oe. The compiler cannot know much
about the natural languages, so the idea to support identifiers in all
possible languages is wrong. What would you do if your users were from
Cambodia? Can you tell if two identifiers in the Khmer script are same? I
could not even tell if they are in that script.
I think that identifiers should be taken from some dialect English,
carefully restricted, understandable to any potential reader of the
program.
If we compared it with other disciplines, in mathematics, physics,
chemistry, biology, even astrology there are certain naming conventions,
which are not localized. But we, the programmers, not only invented more
languages than there programmers exist. We also want to multiply that
number by the number of natural languages and even fictional ones.
> It's the choice of a programmer whether or not to use English for
> identifiers.
Yes, therefore it is better not to give him that choice!
> And certainly he'd want to use Unicode for string literals and
> comments, although this was probably already allowed.
I would require comments in English. I am not so certain about literals.
Probably localized literals should never appear in the code, rather in some
resource file.
Richard Harter
>Hey everyone,
>
>I just stumbled across the Go programming language that Google is
>developing: http://golang.org/
As a followup there is a bit of scandal about the name. It seems
that there already is a language named Go. The chaps at Google
didn't do much research when they picked the name. See
http://www.informationweek.com/news/software/web_services/showArticle.jhtml?articleID=221601351
for a news story.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.
bartc
> On Thu, 12 Nov 2009 14:32:14 GMT, bartc wrote:
>
>> I used to allow some European characters (such as accented versions of
>> the
>> vowels) in identifiers in my script languages; my users were in Europe so
>> why not?
>
> Because then your language should consider
>
> Str�me
> Stroeme
>
> same identifier, since in German � = oe. The compiler cannot know much
> about the natural languages, so the idea to support identifiers in all
> possible languages is wrong.
Many languages like to distinguish case. So SIZE is distinct from Size (or
from SiZe or any of the 16 combinations).
If that's acceptable, then treating Str�me and Stroeme differently certainly
should be.
Why are they written differently in the first place? And if oe is
acceptable, then might as well go with that.
> What would you do if your users were from
> Cambodia? Can you tell if two identifiers in the Khmer script are same? I
> could not even tell if they are in that script.
You look at the character codes one-by-one. If two names match in every way,
then they are the same name (and the same identifier, subject to
name-resolution rules of the language).
However, if possible, it's best to avoid characters which are too weird as
there are still a few problems in storing and transmitting this stuff.
> I think that identifiers should be taken from some dialect English,
> carefully restricted, understandable to any potential reader of the
> program.
>
> If we compared it with other disciplines, in mathematics, physics,
> chemistry, biology, even astrology there are certain naming conventions,
> which are not localized. But we, the programmers, not only invented more
> languages than there programmers exist. We also want to multiply that
> number by the number of natural languages and even fictional ones.
>
>> It's the choice of a programmer whether or not to use English for
>> identifiers.
>
> Yes, therefore it is better not to give him that choice!
>
>> And certainly he'd want to use Unicode for string literals and
>> comments, although this was probably already allowed.
>
> I would require comments in English. I am not so certain about literals.
> Probably localized literals should never appear in the code, rather in
> some
> resource file.
It seems understandable for airline pilots, for example, to use English in
their work, but I don't see the same need in programming, unless the local
coding standards specify it.
And why restrict programming to those who only know English? Other than
having to know a few dozen keywords, operators and some library function
names, I don't see English as an essential requirement.
--
Bartc
Richard Harter
<comp.la...@inglorion.net> wrote:
I have been looking at their documentation and admit to mixed
feelings. I shan't argue with their syntax choices - those are
so often vehemently expressed matters of opinion.
More seriously, either the designers didn't do much research into
existing languages and concepts, or they did and decided for good
reasons to go ahead anyway. What those good reasons are is not
immediately evident.
One of the things that is novel is their treatment of channels,
senders, and receivers. A simple model of connectivity is that a
single sender sends information through a channel to a single
receiver. In Google Go a channel can be used by multiple
receivers. As I read their documentation, information sent on a
channel will be picked up by which ever receiver gets to it the
channel first. This is a recipe for indeterminancy and race
conditions. Worse, it appears that different senders can share a
channel. The combination is incredibly dangerous, so much so,
that there must be something I am missing.
bartc
"Richard Harter" <c...@tiac.net> wrote in message
news:4afc2fde...@text.giganews.com...
> On Wed, 11 Nov 2009 12:02:55 +0100, Robbert Haarman
> <comp.la...@inglorion.net> wrote:
>
>>Hey everyone,
>>
>>I just stumbled across the Go programming language that Google is
>>developing: http://golang.org/
>
> As a followup there is a bit of scandal about the name. It seems
> that there already is a language named Go. The chaps at Google
> didn't do much research when they picked the name. See
>
> http://www.informationweek.com/news/software/web_services/showArticle.jhtml?articleID=221601351
>
> for a news story.
The other language is called Go! not Go. I did like this comment #89
however:
#77: Why not start a company called "Google!" ?
But, what's the problem with naming programming languages, I thought you can
call a language whatever you like.
--
Bartc
Rugxulo
On Nov 12, 11:44 am, "bartc" <ba...@freeuk.com> wrote:
> "Richard Harter" <c...@tiac.net> wrote in message
>
> news:4afc2fde...@text.giganews.com...
>
> >>I just stumbled across the Go programming language
>
> > As a followup there is a bit of scandal about the name.
> > It seems that there already is a language named Go.
>
> The other language is called Go! not Go.
LOL ... I don't think such a minor difference will stop them from
bickering. Forget swine flu/H1N1, "trolling" is an epidemic (man, I
hate that term, too).
> But, what's the problem with naming programming
> languages, I thought you can call a language whatever
> you like.
How about these alternatives?
NotGo (abbreviated !Go)
Go2 (aka, Goto)
Yeah, smart ideas, eh? I'm sure the world will accept either of those
will open arms (not). ;-)
P.S. My pet peeve is when common language words (esp. when only one or
two) are often trademarked, e.g. "fair and balanced" and you aren't
expected to use them in conjunction anymore. The nerve! "I found it
first" is a lame excuse to deny the rest of 6.5 billion people the use
of it. (But let's be honest, most people have horrible names anyways.
Syfy? Wii? XBox 360? Win7? D? iPod? Ugh.)
Rugxulo
On Nov 12, 3:07 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 11 Nov 2009 19:52:22 -0800, Mike Austin wrote:
> > Dmitry A. Kazakov wrote:
>
> But there are lots of languages, which do the job of
> obfuscation much better. Consider J, a program in J
> looks like a disk boot sector dump.
>
> (snip line noise)
>
> (I have no idea what this code does, allegedly it
> solves 8-Queens. Who knows, maybe it indeed does...
> You cannot compete with THIS. It is just about perfect! (:-))
APL? False? Befunge? Brainf***? GNU Autoconf? ;-)
> Then Unicode opens so many new opportunities! Curly
> brackets, huh, authors of Go could take Klingon letters
> to encrypt the keywords "if", "while",
> "package" etc. Why just "begin" and "end"? (:-))
*shudder* Don't tempt them. And besides, Klingon is
copyrighted. ;-) :-P
Dmitry A. Kazakov
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
> news:1ojpe56xz09lb$.q1u9gnka2t20$.dlg@40tude.net...
>> On Thu, 12 Nov 2009 14:32:14 GMT, bartc wrote:
>>
>>> I used to allow some European characters (such as accented versions of
>>> the
>>> vowels) in identifiers in my script languages; my users were in Europe so
>>> why not?
>>
>> Because then your language should consider
>>
>> Strï¿œme
>> Stroeme
>>
>> same identifier, since in German ￜ = oe. The compiler cannot know much
>> about the natural languages, so the idea to support identifiers in all
>> possible languages is wrong.
>
> Many languages like to distinguish case. So SIZE is distinct from Size (or
> from SiZe or any of the 16 combinations).
>
> If that's acceptable,
In my opinion it is not.
> then treating Strï¿œme and Stroeme differently certainly
> should be.
If we ignored the native language issue, we could also do the existence of
accented letters.
The point is, if we know in advance that we cannot adapt to the natural
languages, why should we even try? There are languages where spelling is
incredibly inflectional. Some languages heavily use ligatures, others vary
glyphs of the same letter depending of the context. There are ones which
aren't left to right, or not even linear. It is impossible to deal with all
that mess. Leave that to a word processor.
> Why are they written differently in the first place?
Because the Latin alphabet didn't have a letter for this sound. Facing this
problem some European languages took the approach of using several letters
(English "sh") and inventing new letters (v->u, v+v->w). Others used
accents (sh in Czech is ￜ). Third did ligatures (ￜ, ￜ, etc). German took
use of all of them and sometimes simultaneously for the same sound.
> And if oe is
> acceptable, then might as well go with that.
>
>> What would you do if your users were from
>> Cambodia? Can you tell if two identifiers in the Khmer script are same? I
>> could not even tell if they are in that script.
>
> You look at the character codes one-by-one. If two names match in every way,
> then they are the same name (and the same identifier, subject to
> name-resolution rules of the language).
This algorithm is based on a presumption, which does not hold. E.g. in
Russian e and ￜ are sometimes strictly same, sometimes they aren't. You
cannot compare words by their code points.
> However, if possible, it's best to avoid characters which are too weird as
> there are still a few problems in storing and transmitting this stuff.
Exactly. My definition of "weird" is anything beyond ASCII. (:-))
>> I would require comments in English. I am not so certain about literals.
>> Probably localized literals should never appear in the code, rather in
>> some resource file.
>
> It seems understandable for airline pilots, for example, to use English in
> their work, but I don't see the same need in programming, unless the local
> coding standards specify it.
We are using coding standards, where the language is too lax.
> And why restrict programming to those who only know English?
Because otherwise you could not outsource.
Why physicians have to learn Latin and programmers should not do English?
> Other than
> having to know a few dozen keywords, operators and some library function
> names, I don't see English as an essential requirement.
It would be only a small subset of English.
Rod Pemberton
>
> But there are lots of languages, which do the job of obfuscation much
> better. Consider J, a program in J looks like a disk boot sector dump. For
> example:
>
> perm =: ! A.&i. ] NB. all permutations of integers 0 to y
> comb2 =: (, #: I.@,@(</)&i.)~ NB. all size 2 combinations of integers 0
to
> y
> mask =: [ */@:~:&(|@-/) {
> queenst=: comb2 (] #"1~ mask)&.|: perm
>
> (I have no idea what this code does, allegedly it solves 8-Queens. Who
> knows, maybe it indeed does... You cannot compete with THIS. It is just
> about perfect! (:-))
Well, "io_x" aka "rio" aka numerous etc., who posts to alt.lang.asm with his
own assembly language for x86 does a good job:
align 4
Fopen_m:
<b,i,j,k
s-=16
j=[s+36]|i=[s+40]|j==0#.e|B*j==0#.e|a^=a|k^=k|i#.1
.e: a^=a|stc|##.f
.0: ++i
.1: al=*i
a=='r'!#.2|k|= 1|#.0
.2: a=='w'!#.3|k|= 2|#.0
.3: a=='a'!#.4|k|= 4|#.0
Etc. (it gets worse... ".9: c=[a]|c&3!#.a|a+=20|a<r#.9|##.ee" )
You can see the complete sample of that one program at the following link.
He's posted many such programs. At the request of other a.l.a readers, he's
started posting x86 code translations as well. His earlier version of his
language was even more cryptic. He's slowly made it more understandable...
http://groups.google.com/group/alt.lang.asm/msg/e0acb561ca9cd9dd?hl=en
Of course, languages with very little syntax, e.g., FORTH or Brainfuck, or
cryptic operators with a preprocessor, like C, can be made unreadable also.
Rod Pemberton
Rod Pemberton
news:AZWKm.4327$Ym4...@text.news.virginmedia.com...
>
> Many languages like to distinguish case. So SIZE is distinct from Size (or
> from SiZe or any of the 16 combinations).
>
IMO, a poor design choice... Oh, how I hate that. You search for "size"
thinking you've found all instances of "size", only to find more variables
with the identical _name_ - but _different variables_ due to capitalization.
Which "size" am I looking for now?
> It seems understandable for airline pilots, for example, to use English in
> their work, but I don't see the same need in programming, unless the local
> coding standards specify it.
>
> And why restrict programming to those who only know English? Other than
> having to know a few dozen keywords, operators and some library function
> names, I don't see English as an essential requirement.
>
There is much meaning conveyed in the names and abbreviations used. E.g.,
if you're a C programmer, and if you see "sts" in a C program, and you speak
English, you probably know or can guess that "sts" means "status". So, you
know it's a variable used as a "flag" to indicate the results of what just
happened. It gets far more advanced than that. Now, if a C programmer, who
only or primarily speaks English goes to read code in Spanish or Italian, he
could look at a variable all day and have no understanding of what it means.
Most of the time, that's not a problem. I.e., English speakers use code
written in English, Spanish speakers in Spanish, etc. But, one could guess
that a big international company would have problems with code from their
programmers in many countries if the code is in different languages.
Rod Pemberton
Rod Pemberton
news:36bba919-0a31-4cf2...@l13g2000yqb.googlegroups.com...
> P.S. My pet peeve is when common language words (esp. when only one or
> two) are often trademarked, e.g. "fair and balanced" and you aren't
> expected to use them in conjunction anymore.
That's not true. In the US, you have right to free speech, but it's
non-commercial free speech. It's guaranteed by our constitution. If you
use those words in a commercial speech, e.g., to promote a product or
service, then you've got a legal problem. They just had a video on the
"Let's get ready to rumble!" guy, where he discussed this issue. He
trademarked the phrase. Made millions. Yes, the *nix for Unix persists in
newsgroups anyway. But, don't forget that while the right to free speech is
protected - you have the right to say it - that implied actions or resulting
negative consequences of the free speech can be outlawed: slander, libel,
threats, intimidation, inciting violence or riots, intentionally deceiving
to defraud, lying to certain authorities, etc. etc. If speech causes harm
to someone directly or indirectly, or intereferes with authorities, then
you'll want to be careful not to phrase things as a threat or challenge, but
as a statement of fact.
Rod Pemberton
Mike Austin
> On Wed, 11 Nov 2009 12:02:55 +0100, Robbert Haarman
> <comp.la...@inglorion.net> wrote:
>
>> Hey everyone,
>>
>> I just stumbled across the Go programming language that Google is
>> developing: http://golang.org/
>>
>> It seems really interesting. Some features to whet your appetite:
>>
>> - Fast compilation
>>
>> - Fast generated code
>>
>> - Type and memory safety
>>
>> - Lightweight concurrency
>>
>> - Interface inference (i.e. you don't have to declare that your type
>> has a certain interface; if the right methods are provided, it works)
>>
>> For a minute, I was afraid that I could as well halt my great plans for
>> my Mana programming language, but, luckily, Go still seems different
>> enough.
>>
>> Anyway, I just wanted to bring Go to your attention. What do you all think
>> about it?
>
>
> I have been looking at their documentation and admit to mixed
> feelings. I shan't argue with their syntax choices - those are
> so often vehemently expressed matters of opinion.
Oh god, I have a headache now. What where they thinking?
func (file *File) Read(b []byte) (ret int, err os.Error) {
...
}
I understood what's going on after reading the description, but it just seems
like there's no cohesion or something to tie the pieces together. The three
parenthesized clusters all look the same. And do we really need to name the
explicit "this"?
Kind of a mix of different languages, but my first attempt would be:
function File.Read(b : byte[]) => (ret : int, err : os.Error) {
....
}
> More seriously, either the designers didn't do much research into
> existing languages and concepts, or they did and decided for good
> reasons to go ahead anyway. What those good reasons are is not
> immediately evident.
>
> One of the things that is novel is their treatment of channels,
> senders, and receivers. A simple model of connectivity is that a
> single sender sends information through a channel to a single
> receiver. In Google Go a channel can be used by multiple
> receivers. As I read their documentation, information sent on a
> channel will be picked up by which ever receiver gets to it the
> channel first. This is a recipe for indeterminancy and race
> conditions. Worse, it appears that different senders can share a
> channel. The combination is incredibly dangerous, so much so,
> that there must be something I am missing.
Hopefully they did some, like, testing?? :)
> Richard Harter, c...@tiac.net
> http://home.tiac.net/~cri, http://www.varinoma.com
> Infinity is one of those things that keep philosophers busy when they
> could be more profitably spending their time weeding their garden.
Mike
bartc
"Mike Austin" <mi...@mike-nospam-austin.com> wrote in message
news:LrCdnRsgD7EwQmHX...@giganews.com...
> Richard Harter wrote:
>> On Wed, 11 Nov 2009 12:02:55 +0100, Robbert Haarman
>> <comp.la...@inglorion.net> wrote:
>> I have been looking at their documentation and admit to mixed
>> feelings. I shan't argue with their syntax choices - those are
>> so often vehemently expressed matters of opinion.
>
> Oh god, I have a headache now. What where they thinking?
>
> func (file *File) Read(b []byte) (ret int, err os.Error) {
> ...
> }
>
> I understood what's going on after reading the description, but it just
> seems like there's no cohesion or something to tie the pieces together.
> The three parenthesized clusters all look the same. And do we really need
> to name the explicit "this"?
>
> Kind of a mix of different languages, but my first attempt would be:
>
> function File.Read(b : byte[]) => (ret : int, err : os.Error) {
> ....
> }
I've been looking at this:
http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php
According to that, that (file *File) bit is used for methods. Even so, it
looks clunky. Why not just:
method Read(file *File, b byte[]) => (ret int, err os.Error) ...
At least they do use a keyword to introduce function definitions, which is a
huge improvement over C where function declarations become invisible amongst
all the clutter. Although it seemed too big deal to type those extra 4
characters...
--
Bartc
Marco
> Exactly. My definition of "weird" is anything beyond ASCII. (:-))
allow non-ascii characters only in comments not identifiers
Mike Austin
> "Mike Austin" <m...@mike-nospam-austin.com> wrote in message
>
> news:LrCdnRsgD7EwQmHX...@giganews.com...
>
>
>
> > Richard Harter wrote:
> >> On Wed, 11 Nov 2009 12:02:55 +0100, Robbert Haarman
> >> <comp.lang.m...@inglorion.net> wrote:
> >> I have been looking at their documentation and admit to mixed
> >> feelings. I shan't argue with their syntax choices - those are
> >> so often vehemently expressed matters of opinion.
>
> > Oh god, I have a headache now. What where they thinking?
>
> > func (file *File) Read(b []byte) (ret int, err os.Error) {
> > ...
> > }
>
> > I understood what's going on after reading the description, but it just
> > seems like there's no cohesion or something to tie the pieces together.
> > The three parenthesized clusters all look the same. And do we really need
> > to name the explicit "this"?
>
> > Kind of a mix of different languages, but my first attempt would be:
>
> > function File.Read(b : byte[]) => (ret : int, err : os.Error) {
> > ....
> > }
>
> I've been looking at this:
>
> http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php
>
> According to that, that (file *File) bit is used for methods. Even so, it
> looks clunky. Why not just:
>
> method Read(file *File, b byte[]) => (ret int, err os.Error) ...
Looks good to me, Google are you listening? :)
> At least they do use a keyword to introduce function definitions, which is a
> huge improvement over C where function declarations become invisible amongst
> all the clutter. Although it seemed too big deal to type those extra 4
> characters...
Yep, I like the keyword also. On another note, what do you think of
the use of "x := 10"? From what I can tell, it's equivalent to "var x
= 10". I don't see much of an advantage...
Mike
> --
> Bartc
bartc
I don't like it. It looks like an Algol/Pascal/Ada assignment operator, then
you look further and they're using the normal = assignment.
(Maybe it would have worked better if they'd used the colon for
declarations, as you suggested. So if:
var a int = 100;
is written as: var a : int = 100, the ":" can be left out to leave: a :=
100;)
Anyway, it just doesn't look right in a C-style syntax.
--
Bartc
llothar
> receiver. In Google Go a channel can be used by multiple
> receivers. As I read their documentation, information sent on a
> channel will be picked up by which ever receiver gets to it the
> channel first. This is a recipe for indeterminancy and race
> conditions.
It works if you assume that all receivers are just similar enough
to handle all messages. Look at it as some kind of load balancer
between sender and receivers. It's the internet oh sorry i mean
its google so i guess it was there intention to do it this way.
But i don't like it either.
Richard Harter
<scholz...@gmail.com> wrote:
>On 12 Nov., 18:14, c...@tiac.net (Richard Harter) wrote:
>
>
>> receiver. =A0In Google Go a channel can be used by multiple
>> receivers. =A0As I read their documentation, information sent on a
>> channel will be picked up by which ever receiver gets to it the
>> channel first. =A0This is a recipe for indeterminancy and race
>> conditions. =A0
>
>It works if you assume that all receivers are just similar enough
>to handle all messages. Look at it as some kind of load balancer
>between sender and receivers. It's the internet oh sorry i mean
>its google so i guess it was there intention to do it this way.
>
>But i don't like it either.
The multiple receivers, one message packet, first responder
services scenario has its points, but it can be done in a
disciplined manner. The language spec isn't all that it might
be, but as far as I can tell the only constraint on channels is
that the type they pass is fixed for each channel. Other than
that they can be passed around like party favors.