Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is amazing, period.

poincare101.blogspot.com

Post reply on HN
Print view View original

121–130 of 241 posts

Re: Go is amazing, period.

#121

Post by [deleted] »

lusr wrote: post #99
j45 wrote: post #8

A lot of great and capable languages are overlooked. The question is how do they overcome the opinion, hearsay and preferences that are louder than the truth? Too few devs: - truly give something 5 minutes before jumping to their foregone conclusion. - admit that most languages with a decent capable and decent programmer are all, pretty equally equipped. - every language + framework has it's pros and cons.

5 minutes isn't fair. I took a look at http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... first. OK so Go is about on par with Mono's C# performance and uses up to a 1/3 of the memory with code that is more concise. That's cool because it means I'm not sacrificing anything over the platform I specialize in (C#; although the last time I looked at the Alioth C# code I thought I saw some obvious improvement…

[deleted]

Re: Go is amazing, period.

#122

Post by canop_fr »

ootachi wrote: post #91
enneff wrote: post #77

Earlier quoted context omitted.

> send a map over a channel, access it concurrently, and it will segfault Not exactly. Go's maps may safely be read from multiple threads simultaneously, but writing at the same time as reading or writing will yield undefined behavior. Go programs don't segfault like C programs. They typically panic, providing a descriptive stack trace of where the problem arose. As I mentioned in my other thread, what you're describ…

"Undefined behavior" is the problem here. In Java, you can create data races, but you can't cause memory errors.

What do you mean ? I you don't use synchronization protection when you access your structures from different threads, you'll have the same inconsistency in your data. Using the explicit Mutex of Go doesn't seem so different than creating an object on which synchronizing your blocks as you do in Java.

Or do I miss something in your comment ?

EDIT : In my opinion, a program that doesn't crash and goes on running with inconsistent data structures is mainly hiding a failure which will appear in a worse way later (for example when those data will be used). To fail fast is often more secure. But my opinion may be based on the fact that I see too many java programs which seem to work but that nobody can touch because they're just in the lucky state where bugs don't surface too much.

Re: Go is amazing, period.

#123

Post by kinghajj »

karterk wrote: post #113
amattn wrote: post #85

Earlier quoted context omitted.

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…

What about using two characters for assignment? a := 1 vs a = 1

":=" is type-inferred variable declaration and assignment, while "=" is just assignment.

Re: Go is amazing, period.

#124

Post by canop_fr »

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…

I concur about arrays. Each time I make computations in java and I have to either pass offsets and lengths or make arraycopy I regret not to code in Go.

Re: Go is amazing, period.

#125

Post by ajb »

enneff wrote: post #111
ootachi wrote: post #110

Earlier quoted context omitted.

"There are few real world programs that are improved by code generation micro-optimizations" I don't know how to convince you of the fact that this statement just isn't true. Consider the rasterization software you're using right now in your web browser. Micro-optimizations hugely matter for blitting and tessellation. Consider video decoding (or encoding!). Using SSE instructions instead of going word-by-word or byte…

Your examples are good, but they are still minority examples. > Systems programmers need a compiler that knows about these micro-optimizations. And they have gccgo! Yay! :-)

Code your pc spends 90% of its time running, will always be a minority :-)

Re: Go is amazing, period.

#126

Post by ootachi »

canop_fr wrote: post #122
ootachi wrote: post #91

Earlier quoted context omitted.

"Undefined behavior" is the problem here. In Java, you can create data races, but you can't cause memory errors.

What do you mean ? I you don't use synchronization protection when you access your structures from different threads, you'll have the same inconsistency in your data. Using the explicit Mutex of Go doesn't seem so different than creating an object on which synchronizing your blocks as you do in Java. Or do I miss something in your comment ? EDIT : In my opinion, a program that doesn't crash and goes on running with i…

Mutating a hash map in Java while another thread reads it won't cause bad things like:

(a) memory you don't have access to to be read;

(b) other threads to crash;

(c) the VM state to be corrupted;

(d) the GC to crash;

and so on. The Java world is still in a consistent state. In a security-oriented world, this is important.

To the reply: It's a bit pedantic for me to say this, I know, but that's still "a consistent state". Basically, a Java program can't do anything it wouldn't otherwise be able to do by modifying a hashmap concurrently. Java programs can go into infinite loops. They can't access uninitialized memory.

Re: Go is amazing, period.

#127

Post by 0x0 »

ootachi wrote: post #126
canop_fr wrote: post #122

Earlier quoted context omitted.

What do you mean ? I you don't use synchronization protection when you access your structures from different threads, you'll have the same inconsistency in your data. Using the explicit Mutex of Go doesn't seem so different than creating an object on which synchronizing your blocks as you do in Java. Or do I miss something in your comment ? EDIT : In my opinion, a program that doesn't crash and goes on running with i…

Mutating a hash map in Java while another thread reads it won't cause bad things like: (a) memory you don't have access to to be read; (b) other threads to crash; (c) the VM state to be corrupted; (d) the GC to crash; and so on. The Java world is still in a consistent state. In a security-oriented world, this is important. To the reply: It's a bit pedantic for me to say this, I know, but that's still "a consistent st…

Not entirely true. It's possible to have threads enter infinite loops if you don't synchronize properly: http://stackoverflow.com/questions/1003026/hashmap-concurren...

Re: Go is amazing, period.

#128

Post by stiff »

tpsreport wrote: post #17

Here's a summary of the article: * author cannot write portable C sockets code * author cannot handle C/C++ * author believes his app would be too slow in Python, later abandons App, but retains his bias against Python * Go has no parens for if/for * Go has unicode support * Go has closures "like salt shakers" * Go is cohesively designed * Go has nice libraries Go may or may not be a good language, but this kind of a…

It's hard to expect a really detailed analysis from someone still in high school. On the other hand, it is good to see how the various languages look like from a fresh perspective of someone with relatively little preconceptions from years of using C/C++/Python/whatever. After all, if he has lots of problems with writing something in C++, but much less when writing it in Go, it probably means lots of us had at some point to internalize lots of knowledge that's not directly relevant to the problem being solved, but to the intricacies of C++ or whatever. If the next generation of programmers can avoid this, that's a huge step ahead in what problems we will be able to solve.

Re: Go is amazing, period.

#129

Post by ootachi »

ajb wrote: post #125
enneff wrote: post #111

Earlier quoted context omitted.

Your examples are good, but they are still minority examples. > Systems programmers need a compiler that knows about these micro-optimizations. And they have gccgo! Yay! :-)

Code your pc spends 90% of its time running, will always be a minority :-)

Replace "PC" with "program". That's the key here.

Most of the code in any program is not performance critical. Yet the reason that this is the case is that most of the time of any program is spent in tight loops. Those tight loops are what must be optimized. And that is why performance-minded systems programmers use top-notch optimizing compilers.

The popular dynamic languages have gotten away with being relatively slow because programs written in them are either not CPU bound or spend most of their CPU time in C libraries. This works great for them -- dynamic languages are awesome! But the calculus changes when you're programming in a language that defines the entire stack. When there's no C-compiled code to fall back on, micro-optimizations start to matter.

Re: Go is amazing, period.

#130

Post by tzury »

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.

    void func() {

    }
Is my natural choice anyway, so I guess, this will not stand in my way. Let's go!
Post reply on HN