Go is amazing, period. • Hacker News Board

Re: Go is amazing, period.

#81

Post by FreakLegion » Mon, Mar 19, 2012, 5:49 AM UTC

CamperBob wrote: post #78

georgemcbay wrote: post #36

As someone who is 38, and has programmed in everything from 6510/68k/MIPS/ARM assembler to C/C++ to ActionScript/haxe/JavaScript to D to Python, et al, I also think Go is pretty great. In addition to the cool things in the language, I really love what they are doing with the build system. The Go programming I've been doing has been on Windows but targeting an ARM CPU (the PXA168 in the Chumby 8 device) and cross-comp…

I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me Wait, what?

    void func()
    {
    }

vs.

    void func() {
    }

Does Go really enforce the latter? That would be incredibly silly.

Re: Go is amazing, period.

#82

Post by enneff » Mon, Mar 19, 2012, 5:51 AM UTC

ootachi wrote: post #7

Radzell wrote: post #3

I like go. As a guy who really doesn't like javascript I like the structure of GO. I like really structured languages. For anyone who like the mobile/desktop type of programming this seems like a refreshing change.

Er, JavaScript is a structured language (meaning it doesn't mandate labels and goto for control flow).

I think what your parent is referring to is that, compared to JavaScript, Go provides a fairly rigid structure in which to write programs. You write packages that consist of type, function, and variable declarations, and link them together with import statements. Its rich standard library supports a range of useful, omnipresent interfaces, which make it easy to do things in an obviously correct, interoperable way.

By comparison, JavaScript lets you structure your code in however you like, and there is a very tiny standard library and no real uniformity across implementations, frameworks, and so on. This can be a strength, but I think on balance it is a real weakness in JS. node.js has done a lot to improve this, though the language itself still lets you define anything, anywhere, at any time, and change that state from anywhere else.

Re: Go is amazing, period.

#83

Post by enneff » Mon, Mar 19, 2012, 5:56 AM UTC

FreakLegion wrote: post #81

CamperBob wrote: post #78

Earlier quoted context omitted.

I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me Wait, what?

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

It does, but for a good reason. Its so the parser can find the line endings without needing complicated rules and look-ahead.

Go style is enforced mechanically with gofmt (http://weekly.golang.org/cmd/gofmt/), anyway, so one typically drops the pretension of these kinds of style quibbles. It is more important to have one consistent style than to make everyone happy. The gofmt style forced me to change several of my own habits, but it was definitely worth it for my code to look like everyone else's. I've never encountered a Go programmer who hasn't become grateful for gofmt, in the end.

Re: Go is amazing, period.

#84

Post by ek » Mon, Mar 19, 2012, 5:56 AM UTC

I really like most things about Go, and was even going to use it for a bytecode interpreter project I was working on. A problem that I ran into, however, was that in interpreting a dynamic language with a stack machine, we needed a way to be able to store arbitrary data in stack values, which in C/C++ would be done using a struct with a type flag and then a union of various types.

Go doesn't have unions, though, and so this means that we would have ended up using a struct and using about 3x the memory on average, per stack value. You can see this limitation exposed as well in goyacc, the port of Yacc to Go (as the name suggests). Where Bison uses a union for yylval, Go is forced to use a struct.

I think this has been discussed on the golang-nuts mailing list a couple times and dismissed, for reasons of which I'm not fully aware.

Re: Go is amazing, period.

#85

Post by amattn » Mon, Mar 19, 2012, 5:59 AM UTC

FreakLegion wrote: post #81

CamperBob wrote: post #78

Earlier quoted context omitted.

I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me Wait, what?

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

Nothing in go is silly. There are multiple reasons why it's required.

The answer usually given is faster compile times and the removal of semicolons from the language. I don't know the details, but someone new complains about it on the mailing list fairly frequently.

Also having a tool enforced brace style is just plain practical. Less silly arguments/bikeshedding.

I was also a brace on its own line kinda guy, but between javascript and go, I've gotten over it.

Re: Go is amazing, period.

#86

Post by enneff » Mon, Mar 19, 2012, 5:59 AM UTC

ootachi wrote: post #60

srean wrote: post #34

I have'nt managed enough time yet to familiarize myself with Go, but the little that I have glanced at, it seems a nice enough language for scientific computation. The syntax and semantics of arrays are nice and binding to C is purportedly simple. Ease of binding with Fortran would have been nice too. So I find it a bit strange that I never hear of Go in the context of array based computation, that is the stuff peopl…

The concurrent stop-the-world garbage collector is a performance issue. Additionally, the Plan 9-based compiler is not an optimizing compiler.

"...not an optimizing compiler." ?

The gc compiler does perform some optimizations, including inlining across package boundaries. There is also the gccgo compiler which takes full advantage of gcc's many optimizations. Both compilers will be equally supported in Go 1.

Re: Go is amazing, period.

#87

Post by jbarham » Mon, Mar 19, 2012, 6:01 AM UTC

FreakLegion wrote: post #81

CamperBob wrote: post #78

Earlier quoted context omitted.

I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me Wait, what?

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

It's a FAQ: http://weekly.golang.org/doc/go_faq.html#semicolons

Re: Go is amazing, period.

#88

Post by mbreese » Mon, Mar 19, 2012, 6:09 AM UTC

amattn wrote: post #85

FreakLegion wrote: post #81

Earlier quoted context omitted.

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

Nothing in go is silly. There are multiple reasons why it's required. The answer usually given is faster compile times and the removal of semicolons from the language. I don't know the details, but someone new complains about it on the mailing list fairly frequently. Also having a tool enforced brace style is just plain practical. Less silly arguments/bikeshedding. I was also a brace on its own line kinda guy, but be…

Perhaps this will be Go's version of Python's whitespace issue. People will balk at the seemingly arbitrary nature of the syntax and avoid trying the language. However, after time, the rest of the language's advantages will lead people to get over their syntax aversion and try the language. Then after 6 months they'll look back and wonder what the big fuss was before.

Not that I have any experience with that...

Re: Go is amazing, period.

#89

Post by ootachi » Mon, Mar 19, 2012, 6:11 AM UTC

enneff wrote: post #76

ootachi wrote: post #66

Earlier quoted context omitted.

There's no one definition of type safety. It ultimately depends on what your type system is trying to enforce. I strongly suspect, however, that most programmers expect "type-safe" languages to enforce memory safety, and that Go's lack of memory safety is surprising in this context.

That is a very unusual definition of "type safety." What you're describing is more commonly known as "thread safety," in my experience. By your definition, is Java type safe? You still need to guard against concurrent mutation of shared data in Java and in most other languages that support shared mutable state. We typically describe Go as "memory safe," in that you can't address uninitialized memory (unless you impor…

Java is type safe, because the language defines clear semantics for what happens when you mutate two memory locations simultaneously (you get one result or the other). Under no circumstances does the program have truly undefined behavior. Java HashMaps aren't thread-safe, but they will just do the wrong thing when you try to access them concurrently. Under no circumstances will the program be able to read or write undefined memory.

By contrast, your Go program's behavior becomes undefined when you mutate and read a hashmap concurrently among multiple threads. Anything can happen.

Edit (addressing the reply below): That's fascinating, thanks. It really speaks to the wisdom of writing hash maps in the library, on top of the language, rather than unsafely in the runtime as Go does. (This would unfortunately require generics, so it's not an option for Go.)

It's very difficult to predict all that can go wrong with unsynchronized access to data structures that aren't designed to be thread safe. The beauty of Java here is that the core primitives can never lead to accessing undefined memory, and therefore hash tables, however badly they mess up, will never lead to that core principle being violated. This is critical for security, for example.

Re: Go is amazing, period.

#90

Post by FreakLegion » Mon, Mar 19, 2012, 6:11 AM UTC

enneff wrote: post #83

FreakLegion wrote: post #81

Earlier quoted context omitted.

void func() { } vs. void func() { } Does Go really enforce the latter? That would be incredibly silly.

It does, but for a good reason. Its so the parser can find the line endings without needing complicated rules and look-ahead. Go style is enforced mechanically with gofmt ( http://weekly.golang.org/cmd/gofmt/ ), anyway, so one typically drops the pretension of these kinds of style quibbles. It is more important to have one consistent style than to make everyone happy. The gofmt style forced me to change several of my…

Thanks for answering! I have no idea why someone downvoted your reply. People: downvoting is for mean and/or stupid comments, not things you disagree with.

Anyway, in that case I imagine we'll see a Go preprocessor that takes all the line-initial braces and moves them up a break before sending code to the compiler. People get pretty worked up about this stuff.