Google introduces new programming language called "Go"

[blankthemuffin]

Really have no idea what this semicolon chat is all about. How is it an issue at all that you don't need to end your lines with semicolons?

[efeX]

i honestly don't see it as an issue, but it would be nice if you could still have them (can you?)

[Ortzinator]

[url]http://golang.org/doc/go_for_cpp_programmers.html[/url]

[quote]Go treats semicolons as separators, not terminators. Moreover, semicolons may be omitted after the closing parenthesis of a declaration block or after a closing brace that is not part of an expression (e.g., var s struct {} or { x++ }). Semicolons are never required at the top level of a file (between global declarations). However, they are always permitted at the end of a statement, so you can continue using them as in C++.[/quote]

[blankthemuffin]

You can use them as you do in C, but you don't have to.

[url]http://golang.org/doc/effective_go.html#semicolons[/url]

[Cathbadh]

Looks not unlike Python. Which is a good thing. Installing now.

[editline]02:04AM[/editline]

[QUOTE=Eleventeen;18329633]why no go for windows?[/QUOTE]
Because Google developers very commonly use Linux. Most of their development and operation involves Linux, and from a standards viewpoint, Linux and Mac OS are almost identical. (In fact, Windows is like the outlier. Programs have to be made special for Windows from the viewpoint of a google engineer, not the other way around)

I'm not pulling this outta my ass. I have 3 good friends I went to college with who are now Google software engineers, and 2 of them are on the core dev tools team. Linux is always the first to be supported for their code development projects, and Macintosh at almost the same time. The Android SDK is the same way. Theres a kinda half-assed port for Windows floating around I think.

Long story short, if you are writing code using Google's tools, then you'd do best to run Linux.

[ZeekyHBomb]

[QUOTE=nullsquared;18326135]Actually a C++ Hello World that uses the SC++L will be of similar size.[/QUOTE]
[cpp]#include <iostream>
int main() {
std::cout << "Hello, World!" << std::endl;
return 0;
}[/cpp]
In VS2010 Beta with statically linked runtime lib (/MT compiler-flag) and optimizations turned on (/O2, ...) compiles to ~95KB.

I don't wanna argue about Go being bad nor compare Go to C++ with this though. Just saying that it doesn't compile to the same size.. although Gos fmt.PrintF is using some formatted output, which std::cout does not. But Hello World with the C-function printf compiles to ~44KB.

[nullsquared]

[QUOTE=ZeekyHBomb;18332278][cpp]#include <iostream>
int main() {
std::cout << "Hello, World!" << std::endl;
return 0;
}[/cpp]
In VS2010 Beta with statically linked runtime lib (/MT compiler-flag) and optimizations turned on (/O2, ...) compiles to ~95KB.

I don't wanna argue about Go being bad nor compare Go to C++ with this though. Just saying that it doesn't compile to the same size.. although Gos fmt.PrintF is using some formatted output, which std::cout does not. But Hello World with the C-function printf compiles to ~44KB.[/QUOTE]

Yup, you're right. Still, 500kb isn't a major issue, and there probably aren't any size optimizations, yet.

[blankthemuffin]

Neither C nor C++ bundle a garbage collector and associated goodies. That size is probably going to be a fixed one, as in the overhead is constant no matter how massive your application gets.

[Eleventeen]

Stop being shitheads about the size. If the whole Go library can fit inside ~500KB in the executable, saving you assholes time from downloading the whole API like you need to do with Python, then good. If you don't want to make applications with Go, don't. Just be happy that you don't have to download an API for a Go app.

[compwhiziitothe]

[QUOTE=Eleventeen;18332824]Stop being shitheads about the size. If the whole Go library can fit inside ~500KB in the executable, saving you assholes time from downloading the whole API like you need to do with Python, then good. If you don't want to make applications with Go, don't. Just be happy that you don't have to download an API for a Go app.[/QUOTE]

I guess you missed the part where we agree that it's not really a problem and we're just talking about it.

[Eleventeen]

Well, I give up. I just spent what seems like an hour searching for a way to get user's input like a simple std::cin function.

[RedSponge]

Do you prounounce it Gou like with to Goo's or just Go?

[jA_cOp]

[QUOTE=Eleventeen;18333668]Well, I give up. I just spent what seems like an hour searching for a way to get user's input like a simple std::cin function.[/QUOTE]

There's an os.Stdout, so I bet there's an os.Stdin implementing the os.Reader interface.

[QUOTE=RedSponge;18333680]Do you prounounce it Gou like with to Goo's or just Go?[/QUOTE]

Uhm... sounds like the imperative form of the verb "go" if you ask me.

[Eleventeen]

[QUOTE=jA_cOp;18333692]There's an os.Stdout, so I bet there's an os.Stdin implementing the os.Reader[/QUOTE]

Example?

[jA_cOp]

[QUOTE=Eleventeen;18333759]Example?[/QUOTE]

I've yet to install the compiler, and I couldn't find a function to read a line. But I did find that there is indeed an os.Stdin, and it does implement the io.Reader interface (it's an os.File). You should've just looked at the package documentation.

Anyway, something like this?

buffer := make([]byte, 10)
os.Stdin.Read(buffer) //reads 10 bytes from stdin and writes them to our buffer
Print(buffer)

Only serves as an example of what I'm talking about, I really haven't written a single Go program yet.

[ZeekyHBomb]

[url]http://golang.org/pkg/os/#tmp_34[/url]
[url]http://golang.org/pkg/os/#tmp_352[/url]
:)

[Eleventeen]

[QUOTE=jA_cOp;18333802]You should've just looked at the package documentation.[/QUOTE]

I did. Multiple times.

[jA_cOp]

Got 8g installed now. Looks like the Read function on Stdin is equivalent of C's gets, although much safer.

In C:
[cpp]
#include <stdio.h>

int main()
{
char b[128];
gets(b);
printf("Hello, %s\n", b);
return 0;
}
[/cpp]
Equivalent in Go (tested):

package main

import "fmt"
import "os"

func main()
{
    b := make([]byte, 128); //Creates a slice of a new implicitly allocated array with 128 bytes
    os.Stdin.Read(b);
    fmt.Printf("Hello, %s\n", b); //Note that %v would not work, as it would print b in its array representation
}

os.Stdin.Read only breaks the input prompt when you input a newline. If you enter more data than the size of the buffer you passed to it, it seems to move the entire buffer down, replacing your first input. Not sure if I like that way of handling it, but it sure is a lot better than gets.

[ZeekyHBomb]

If you want to read a string, like std::cin >> somestring, without specifying the size before, you can use a buffered reader:

package main

import "bufio"
import "os"

func main() {
  bufin := NewReader(os.Stdin)
  s := bufin.ReadString('\n')
  os.Stdout.WriteString(s)
}

Might not work, I'm on Windows atm, but something like this should do.

[subenji]

A lot of people seem to be missing the point Google are going for here.
I watched the hour long intro, and 2 main goals they've achieved were apparent to me:
Fast Compiling
Easy Threading for multicore processing/networking (goroutines(sic, Google named them this))

He gave a quick server demonstration of a server hosting being a separate thread from its initialization and processing, that's listening 100%, never missing (or delaying) an incoming request while its busy processing.

The language has been designed from the ground up for concurrent code execution.

[jA_cOp]

[QUOTE=subenji99;18334584]A lot of people seem to be missing the point Google are going for here.
I watched the hour long intro, and 2 main goals they've achieved were apparent to me:
Fast Compiling
Easy Threading for multicore processing/networking (goroutines)

He gave a quick server demonstration of a server hosting being a separate thread from it's initialization and processing, that's listening 100%, never missing (or delaying) an incoming request while it's busy processing.

The language has been designed from the ground up for concurrent code execution.[/QUOTE]

The focus in this thread so far has been on syntax and slightly on the type system. I don't see how we're missing the point just because we haven't talked about concurrent programming yet.

[editline]01:50AM[/editline]

[QUOTE=ZeekyHBomb;18334583]If you want to read a string, like std::cin >> somestring, without specifying the size before, you can use a buffered reader:

package main

import "bufio"
import "os"

func main() {
  bufin := NewReader(os.Stdin)
  s := bufin.ReadString('\n')
  os.Stdout.WriteString(s)
}

Might not work, I'm on Windows atm, but something like this should do.[/QUOTE]

Ah, bufio works great!

Working version:

package main

import "bufio"
import "os"

func main() 
{
    bufin := NewReader(os.Stdin);
    s, ok := bufin.ReadString('\n');
    if ok != nil {
        os.Exit(1)
    }  
    os.Stdout.WriteString(s)
}

(edit: note that I only use semi-colons where they are mandatory)

[subenji]

[QUOTE=jA_cOp;18334595]The focus in this thread so far has been on syntax and slightly on the type system. I don't see how we're missing the point just because we haven't talked about concurrent programming yet.[/QUOTE]
A few people have asked "what's the point in using this instead of C?" - I was answering that question.

Basically, my post was late - it belonged as a reply to the responses on mostly the first page, not stuck here where the discussion got to some actual code. :v:

[kcumpiW]

It needs to be on xp.

[jA_cOp]

[QUOTE=subenji99;18339051]A few people have asked "what's the point in using this instead of C?" - I was answering that question.[/QUOTE]

I wouldn't say that concurrent programming features is the only thing they're going for. They're clearly trying to make big projects more maintainable with this much simpler object system, and it's a LOT safer (thus, less error-prone and easier to debug) than older languages like C and C++.

All in all, it's a very modern language, and considering that it's coming from Google, it'll have plenty of time to mature. Could become something big.

[blankthemuffin]

And who cares if you don't like it, in a few years when google controls the planet you'll be forced to use it anyway.

[subenji]

Agreed, but I never used the word "only". :P
As mentioned, I was posting 2 quick, obvious arguments for go over C, not a be-all, end-all list.
Just enough for the skeptics to see a purpose for the language existing.

Non-heirarchial OOP may take a little getting used to. (Though don't mis-interpret here, these are possible, but discouraged, favouring dynamically-typed methods instead - example given was only one Len method was required, but any compatible data type (int,float,string,array,slice,map,etc) can use it)

[jA_cOp]

[QUOTE=subenji99;18341118]Agreed, but I never used the word "only". :P
As mentioned, I was posting 2 quick, obvious arguments for go over C, not a be-all, end-all list.
Just enough for the skeptics to see a purpose for the language existing.

Non-heirarchial OOP may take a little getting used to. (Though don't mis-interpret here, these are possible, but discouraged, favouring dynamically-typed methods instead - example given was only one Len method was required, but any compatible data type (int,float,string,array,slice,map,etc) can use it)[/QUOTE]

Yeah I know, I just wanted to put my main arguments against older languages out there :)

[efeX]

Go supremacy

[-[ Fizzadar ]-]

haha, windows sucks dick.

Must give this a go tomorrow :)

[Elspin]

Lack of windows: 90% of user base on release lost. If they want this to be used seriously, that was a major fail.