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

91–100 of 241 posts

Re: Go is amazing, period.

#91

Post by ootachi »

enneff wrote: post #77
ootachi wrote: post #55

Earlier quoted context omitted.

Depends what you mean by type safety. If by type safety you mean free from segfaults, Go is very much type-unsafe (send a map over a channel, access it concurrently, and it will segfault).

> 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.

Re: Go is amazing, period.

#92

Post by [deleted] »

enneff wrote: post #70
tedunangst wrote: post #65

Earlier quoted context omitted.

Thanks. If I was somehow supposed to know about the weekly site, I failed.

Nope, there's no way you could have known. We've been working on Go 1 for about six months now, but have resisted pushing people toward the weekly (unstable) snapshots until the most recent one, as the documentation story was incomplete and we didn't want to leave newbies out in the cold. We're nearly ready on all fronts now, and hope to pull the pin on Go 1 before the end of the month.

[deleted]

Re: Go is amazing, period.

#93

Post by ootachi »

enneff wrote: post #80
ootachi wrote: post #62

Earlier quoted context omitted.

PyPy is an optimizing JIT compiler; 6g/8g is not an optimizing compiler. I'm pretty sure one could construct examples in which PyPy beats Go for this reason (try something that relies on loop-invariant code motion, for example). Additionally, PyPy has many garbage collection algorithms, while Go has a stop-the-world mark-and-sweep collector.

PyPy is an amazing project, but it is my understanding that the Python language makes certain guarantees (particularly around thread safety) that will hamper the speed of any implementation for a long time. Go is still really young, yet it's plenty fast. There's plenty of room for it to get much faster.

You don't say exactly what you're referring to, but I assume it's the GIL. The GIL exists because Python threads share a single global namespace, and synchronizing atomically on hash tables for module lookup would be way too slow. If you create isolated contexts (like goroutines, but without shared state), the GIL won't bite you (edit: the degenerate cases that folks like David Beazley has described notwithstanding, but those aren't part of the language semantics and have more to do with unfortunate edge cases arising from the way Python's runtime interacts with the OS scheduler).

The problems with making Python fast mostly have to do with its complicated semantics, particularly around things like name lookup; the GIL doesn't have much to do with it.

Interestingly, I predict Go will have a much tougher time here, unless a form of goroutine is created that can't share any state at all. PyPy has been able to do a lot of garbage collection work precisely because it doesn't have to do concurrent GC. Unfortunately, Go crossed that bridge and can't really go back at this point.

Re: Go is amazing, period.

#94

Post by ootachi »

enneff wrote: post #86
ootachi wrote: post #60

Earlier quoted context omitted.

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.

I'm referring to the Plan 9-based compilers, which do not perform the optimizations necessary to make it competitive with modern C and C++ compilers. Here I'm referring to stuff like SSA-based global value numbering, scalar replacement of aggregates, loop-invariant code motion, etc., as well as lower-level stuff like instruction scheduling. gccgo is better here, of course. Unfortunately, the Plan 9-based compilers are the ones most people use...

Re: Go is amazing, period.

#95

Post by ootachi »

dsymonds wrote: post #79
ootachi wrote: post #60

Earlier quoted context omitted.

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

Have you found the GC to be an actual problem? Or are you assuming it is? It's a very different situation to other GC-based languages.

Why is it so different? I'd be curious to know.

In my experience, a stop-the-world collector that must be threadsafe ends up being a disaster. You hit a brick wall in terms of real-time performance quickly (look at iOS versus Android for an easy example, and Dalvik's GC is much more sophisticated than that of Go these days).

I predict that Go is going to have to put a lot of effort into making the GC fast in order to compete with C++ and Java. They're going to need a concurrent, generational garbage collector much like Java's, probably with a server mode and a client mode. It'll have to be heavily tuned and will require man-years of work.

Re: Go is amazing, period.

#96

Post by ootachi »

enneff wrote: post #82
ootachi wrote: post #7

Earlier quoted context omitted.

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…

"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."

Not true with ES6 modules.

Besides, Python and Ruby have open modules, and that hasn't hurt their usefulness in the real world. Quite the opposite, actually; one of the great pragmatic strengths of Rails was that it monkey patched Ruby's standard libraries. It's hurt optimization, but that's a different story.

Re: Go is amazing, period.

#97

Post by smanek »

ootachi wrote: post #89
enneff wrote: post #76

Earlier quoted context omitted.

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 un…

Incidentally, I've seen unsynchronized access to a Java HashMap cause an infinite loop on .get()s which is (allowably) undefined behavior, and pretty unexpected (see: http://mailinator.blogspot.com/2009/06/beautiful-race-condit...)

Re: Go is amazing, period.

#98

Post by pjmlp »

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…

Not to mention that his remark regarding Unicode support in Go reveals a total lack of knowledge in programming languages.

Re: Go is amazing, period.

#99

Post by lusr »

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 improvements). I see there is a Go STOMP client for Apache Apollo, which means I can supplement the existing code in my current project without having to rewrite everything.

So next I looked at:

* http://golang.org/doc/go_tutorial.html

* http://golang.org/doc/effective_go.html

Way more than 5 minutes. Where are generics or do I have to learn some new construct? Wait a minute, is this thing object oriented or what? If not, why not? Do I have to learn some new philosophy? Already feeling a sense of dread having been through this game 10s of times before with other languages.

I decided to research a bit to see if anybody else with a C# background had looked into Go. I found this, which confirmed my feelings that Go is for people who probably haven't given C# or Java a fair chance: http://www.jondavis.net/techblog/?tag=/c%23+vs+go . That's when I also discovered searching for 'Go' on Google is impossible because of the poor choice of name and decided I wasn't going to spend any more time on it, already being aware that aside from what looks like a total philosophy change (without it being clear whether it'll be worth it), I'm going to lose out on my awesome set of development tools (Visual Studio), years of C# experience and the HUGE .NET ecosystem, in exchange for what? Relatively unimportant performance advantages?

At the end of the day, if performance/memory are issues I can just add more EC2 nodes to my architecture. At some point I'll hopefully make enough money to pay other people to worry about the technology. That being said I realize that as a developer who wants to be a manager/owner I'm probably in the minority of readers here.

Re: Go is amazing, period.

#100

Post by chmike »

ek wrote: post #84

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…

Unions is a problem for garbage collectors. It is difficult to know if it contains a reference or a value. Though Go should have a solution for your use case. The only one I see is polymorphism. Thus a stack of references to different instances of the same class.
Post reply on HN