Anyone else take a look at Go yet?The syntax is pretty similar to C, it has garbage collection, no header files (yay!), no automatic type conversion, and some pretty nifty interface stuff (basically it looks like if you give a type all the methods in an interface, it'll implicitly satisfy that interface. Meaning *anything* that has get(int) and set(int) methods would satisfy any interface with just those two function definitions).And it appears to play pretty nice with UTF-8 characters.It seems fast and small enough, my netbook was able to compile it from source in a few minutes.

I fiddled around with it awhile, looks like the standard library is fairly large given the age of the language, but not large enough to satisfy my rougelike game programming needs! Interfacing with C code is quite tricky, with just an example and a makefile to guide you, but I've got a good start in figuring it out.

Documentation is minimal at best, be prepared for lots of dumpster diving.

I browsed quickly through their Effective Go guide, and it looks like iterating over a string will get you the byte position for each character, whether it's Unicode-extended or not. So iterating over "nihongo" (in Japanese) would net you 0, 3, 6 for the byte positions of the three characters.

It's interesting, but not enough for me to turn away from C++. I've invested too much time in trying to decipher C++ to leave it now

The Unofficial "Making xkcd Slightly Worse" Archive [Incomplete]: xkcdsw.comArticles that fall out of my head about once a month: imrannazar.com

I couldn't get it to compile, even after installing Mercurial (wtf), downloading the source code (wtf why do I need Mercurial to do that?!), installing all the other shit (bison??) and calling all.bash.

It gave me a few dozen "No rule to make $GO_ROOT/Make." and shit itself.I deleted everything and I'll try again in a few hours / days.

Edit: Apparently there was a part of the install doc that I missed where you have to set a bunch of environment variables. This is very strange and I do not like it.

Part of me wants to say it's just new syntax for an old paradigm, but another part wants it to be the new C. Heavy on the operational semantics, nice and clean core. The concurrency primitives are nice (Squeak certainly had a good point), but I have to wonder if they couldn't refactor parts of it into a library and only retain a smaller, more generic subset of the primitives in the language. Type inference is nice, but lack of sexy types detracts a bit. The interfaces make for a nice subtyping model.

It's a bit too punny though.

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

It gave me a few dozen "No rule to make $GO_ROOT/Make." and shit itself.I deleted everything and I'll try again in a few hours / days.

Edit: Apparently there was a part of the install doc that I missed where you have to set a bunch of environment variables. This is very strange and I do not like it.

Well, it compiled out of the box for me after setting the env vars, so that's not their fault. Keeping in mind that you're compiling the first release of this software from source, the install process is pretty easy. Though admittedly, they could be making it easier by using configure. That'd tell them the architecture, and you could just use the --prefix option.

I've been taking it for a spin on some of the easy Euler problems. The syntax is fairly intuitive, as long as you ignore the tutorial when it tells you the statement-separating semicolon is optional in some cases. It's really easier to just put it everywhere.

I feel a bit ambivalent about the way type declarations are post-fixed:

var number uint64 = 42

func calculate(number int) int {

}

The := declaration+assignment operator is kind of neat, too.

I haven't had a chance to mess around with slices yet, which could prove pretty cool. It'd be a bit like having Python's arrays in C.

Or, this could be political. Now that Oracle technically owns Java, this could be Google's shot across Oracle's bow; saying "If you try to privatize Java or mess with it, we'll convince everyone to leave and jump on board Go instead". Maybe not, because this language is fairly significantly different from Java, but it was probably considered. Related, I don't really see corporate-developed (even by Google) languages as really the way to go; I think that Java was a step in the wrong direction, and that it could have been so much more if it had been completely open from the start. But who knows?

Cue wrote:So why exactly do we need another language to add to the long list we already have?

Because most languages we have now suck. So we try to fix those problems we know by making a new one, then discovering the problems the new one has, and so on.

Then, +1 Berengal, and +1 fazzone. I like corporate research languages (Fortress, FI), because they tend to do things that most people don't yet want, but really have needed for the last 10 years , but the organically grown ones that implement those things should reign, in the end.

DSenette: (...) on the whole, even a trained killer cow is kind of stupid.

Cue wrote:So why exactly do we need another language to add to the long list we already have?

Because there actually seems to be a lack of compiled languages. The only ones I'm aware of are C++ and ancestors, and maybe D. (I don't know anything about D).

I need to read through the tutorials some more before I can figure out what to do with it.

Um?

Quite a lot of languages are compiled. In fact, almost every 'serious' language is. Hell, even *javascript* is compiled (JITed, but still…).

I do not considered JIT compiled as a compiled language.. err, static compiled. There is a lack of statically compiled languages.. The only ones I can name off are C, C++, D, Delphi/Pascal, and um... thats it. I'm sure theres some stuff like a statically compiled LISP or Haskell and other niche languages that a significant amount of people use.. but this is all of the statically compiled languages used by a significant amount of industry. Oh wait, I think COBOL still counts as significant in some evil way

I dispute this claim in general, but it is especially false in the domain of systems programming, at which go is ostensibly targeted.

Compiled languages relevant that are to my job as an OS programmer: C, C++, Objective-C, Fortran, D.Interpreted languages relevant to my job: Shell scripting. Sometimes I use python as a calculator.Language in which I do most of my programming: Assembly

Whatever the penetration of the flavor-of-the-month interpreted language (and non-fotm languages) into non-systems tasks, system programming will continue to be dominated by compiled languages for the foreseeable future.

GENERATION -16 + 31i: The first time you see this, copy it into your sig on any forum. Square it, and then add i to the generation.

I dispute this claim in general, but it is especially false in the domain of systems programming, at which go is ostensibly targeted.

Compiled languages relevant that are to my job as an OS programmer: C, C++, Objective-C, Fortran, D.Interpreted languages relevant to my job: Shell scripting. Sometimes I use python as a calculator.Language in which I do most of my programming: Assembly

Whatever the penetration of the flavor-of-the-month interpreted language (and non-fotm languages) into non-systems tasks, system programming will continue to be dominated by compiled languages for the foreseeable future.

Yes. In engineering, mathematics, and high performance computing fortran is still commonly used. There is a massive amount of code written for it which supplies the basic (and not so basic) algorithms the practitioners in these fields require. Code that has been examined, debugged and optimized over years, in some cases decades.

Well, you could call every script language "compiled" because the interpreter builds an internal representation rather than parsing every line every time that line is executed. (And a compiler doesn't have to produce machine code either, it's just a translator from one language into another, usually simpler).

Arancaytar wrote:Well, you could call every script language "compiled" because the interpreter builds an internal representation rather than parsing every line every time that line is executed. (And a compiler doesn't have to produce machine code either, it's just a translator from one language into another, usually simpler).

I think perl might disagree with you, especially considering it's possible to write perl programs that are only syntactically valid on tuesdays.

(As an aside, except for the typo, Java is a perfect example of a statically compiled language. And a JITed language. And an interpreted language. It has all the flexibility and succinctness of manifestly typed static languages combined with the safety of dynamically interpreted languages. Go Java!)

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

And Lua is also compiled, but not to native code. I was definitely thinking of "compiled to native code right away with no bullshit" languages, and I seem to have derailed the thread by asking everyone to define where compiling stops and interpretation starts.

So yeah, I heard Go has concurrency built in or something? Is that working out well?

Anyone else think their variable declaration syntax looks a little Pascal-ish? I wonder if that's for compilation speed - IIRC Pascal compilers have often been faster than their C counterparts simply because the language is easier to parse.

considering it's possible to write perl programs that are only syntactically valid on tuesdays.

Syntactically? I really would like to see that level of awesome. Got an example?

I'm not sure how much easier it is to parse "var something uint = 0" than it is to parse "uint something = 0". Though on second thought, you could have a stricter initial match, not having to look for all type keywords at the start of a line. So I guess it might become a bit faster.

This seems to be part of the make test target, which shouldn't be essential, really. It should be possible to run make install even if the self-test fails. However, the build structure seems a bit unfamiliar, with the central Make file replaced by a bash script...

This seems to be part of the make test target, which shouldn't be essential, really. It should be possible to run make install even if the self-test fails. However, the build structure seems a bit unfamiliar, with the central Make file replaced by a bash script...

There's no makefile, so that doesn't work.

http://internetometer.com/give/4279No one can agree how to count how many types of people there are. You could ask two people and get 10 different answers.

This seems to be part of the make test target, which shouldn't be essential, really. It should be possible to run make install even if the self-test fails. However, the build structure seems a bit unfamiliar, with the central Make file replaced by a bash script...

Hmm... There's a Make file in /src/libcgo, but it keeps saying nothing needs to be done.

There are also .o files and a file called "libcgo.so". It's clearly compiled, but "make install" doesn't work. Just to see what would happen, I tried running it just to see what would happen, and it segfaults (just as a .so should, right?). Does this use some nonstandard method for installing?

http://internetometer.com/give/4279No one can agree how to count how many types of people there are. You could ask two people and get 10 different answers.

TheChewanater wrote:Hmm... There's a Make file in /src/libcgo, but it keeps saying nothing needs to be done.

There are also .o files and a file called "libcgo.so". It's clearly compiled, but "make install" doesn't work. Just to see what would happen, I tried running it just to see what would happen, and it segfaults (just as a .so should, right?). Does this use some nonstandard method for installing?

Though it may also be temporarily generated by some script, I guess. You could write a script to override "make" that copies all makefiles in the current working directory to some safe place, and then simply passes on it's arguments to the real make, and exits like it does.

I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

Grep didn't find anything I wasn't aware of, but I ran anything it found anyway. ./Make.bash seems to work (it doesn't give any errors), and it appears to make everything, but now what? Make install does nothing. All I'm left with is some binary files.

I just went ahead and chmod +x'd everything and ran them. The '8g' command is there, so I guess it's installed.

http://internetometer.com/give/4279No one can agree how to count how many types of people there are. You could ask two people and get 10 different answers.