Why Go is doomed to succeed • Hacker News Board

Re: Why Go is doomed to succeed

#151

Post by pron » Sat, Jun 13, 2015, 8:24 PM UTC

vorklerta wrote: post #109

pron wrote: post #73

Earlier quoted context omitted.

> Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. That's not true. All JVM libraries expose a ton of monitoring information through the standard JMX interface at every level of the stack, from deep inside the JVM, through logging framework, DB drivers, schedulers etc., and all the way through the application. And I can only guess that you've yet to encounter Go'…

> A new Java project is as pristine as a new Go project The problem is that most Java developers have become so familiar with and attached to bloated frameworks that they simply aren't interested in trying any other way. They have a lot of time and effort invested into mastering these frameworks. "Let's use Spring for that", and endless talk of the "persistence layer" for even the most basic apps.

The same developers who would be willing to try Go would also gladly use new Java libraries, and they will be able to preserve much of their hard-earned expertise.

You're implying that the mere switch -- all things being equal -- has an inherent advantage, while I say the opposite: all things being equal, switching languages is always a net loss, other than a possible advantage in recruiting in some regions where HN is popular. Of course, all things are never equal, so there are many other considerations.

Re: Why Go is doomed to succeed

#152

Post by pron » Sat, Jun 13, 2015, 8:24 PM UTC

pcwalton wrote: post #63

tptacek wrote: post #49

Earlier quoted context omitted.

I feel like "bringing CSP into a modern language" gave Pike's team social permission to launch Golang, but the parent comment is closer to the truth than this summary. According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.

> According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++. You and I disagree in regards to a lot about Golang, but I think you're spot-on here. I've thought for years that it was interesting how yosefk's criticisms of C++ in the "Frequently Que…

Why do exceptions interact badly with RAII?

Re: Why Go is doomed to succeed

#153

Post by andyidsinga » Sat, Jun 13, 2015, 8:25 PM UTC

this:

  > Go won’t let you abstract yourself in the foot.

aside from being amusing -- I like this, but can anyone confirm its true in practice with Go?

Re: Why Go is doomed to succeed

#154

Post by Animats » Sat, Jun 13, 2015, 8:29 PM UTC

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.")

Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interface{}" tend to be needed too often. Other than that, there are few killer problems with the language when doing server-side stuff.

The libraries for doing web server type stuff are available and well debugged. When you use a Go library that came from Google, you're probably using code that's executing a few million times a second on Google servers. (As I mentioned on here a few months back, I recently ported a medium-sized production Python program from Python 2 to Python 3. I found library bugs which would have been found long ago were the code heavily used.)

So yes, Go is doomed to succeed. That's not a bad thing.

As for Rust, while I like Rust personally, it may be too complex. The borrow checker concept is brilliant, and a huge advance in understanding how to avoid a big class of bugs. We'll see that again in future languages. The type and generic system, though, pick up where C++ left off, and seem to lead library developers to develop very complex interfaces.

Rust is for people who debate language semantics on Lambda the Ultimate and program in Haskell for fun. Go is for people who have a job to do.

Re: Why Go is doomed to succeed

#155

Post by pron » Sat, Jun 13, 2015, 8:32 PM UTC

pcwalton wrote: post #138

pron wrote: post #75

Earlier quoted context omitted.

> It has fewer GC issues compared to Java No, it has more GC issues. It's just that there aren't yet enough libraries and big applications to make that apparent. It hasn't been stressed enough just yet.

I think it's likely that Golang apps won't stress the GC as much as Java does, because of the simple fact that you can't realistically use j.u.c-style concurrent data structures, since you don't have generics. Where the JVM GC really shines is when you're using shared-memory concurrent data structures, which are really great things—however, without generics, programmers just won't use them in the first place. (I'm no…

Why do you think generics are more relevant for concurrent data structures?

Re: Why Go is doomed to succeed

#156

Post by okasaki » Sat, Jun 13, 2015, 8:35 PM UTC

Elrac wrote: post #142

okasaki wrote: post #129

Earlier quoted context omitted.

Well, C++ has all of that.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

It has garbage collection through shared_ptr.

Re: Why Go is doomed to succeed

#157

Post by pcwalton » Sat, Jun 13, 2015, 8:36 PM UTC

pron wrote: post #152

pcwalton wrote: post #63

Earlier quoted context omitted.

> According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++. You and I disagree in regards to a lot about Golang, but I think you're spot-on here. I've thought for years that it was interesting how yosefk's criticisms of C++ in the "Frequently Que…

Why do exceptions interact badly with RAII?

You have to think carefully about how to clean up your object if something throws during its constructor, and throwing an exception in a destructor can lead to your program aborting if that destructor was called as a result of another exception being thrown.

Note that I don't think banning exceptions is really the answer; in particular, the destructor issue is just a specific case of "handling errors during finalization is really hard", and you can't get away from finalization in general. Exceptions really put those issues front and center, though.

Re: Why Go is doomed to succeed

#158

Post by pcwalton » Sat, Jun 13, 2015, 8:39 PM UTC

pron wrote: post #155

pcwalton wrote: post #138

Earlier quoted context omitted.

I think it's likely that Golang apps won't stress the GC as much as Java does, because of the simple fact that you can't realistically use j.u.c-style concurrent data structures, since you don't have generics. Where the JVM GC really shines is when you're using shared-memory concurrent data structures, which are really great things—however, without generics, programmers just won't use them in the first place. (I'm no…

Why do you think generics are more relevant for concurrent data structures?

Because "programs don't need more than one type of dictionary, so the language can just hard code one implementation in" is at least a defensible position in a single-threaded setting (although I don't agree with it), but it definitely isn't in a scalable parallel setting.

Re: Why Go is doomed to succeed

#159

Post by nickbauman » Sat, Jun 13, 2015, 8:54 PM UTC

vezzy-fnord wrote: post #10

Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges clea…

The problem with Go is likely a result of having the kinds of stated goals that it has. The designers of Java deliberately created a language that was for people they didn't trust. The result is a hammer that looks and works like a dildo.

So we're likely headed to where the commensurate Go analogy to Java is a hammer that looks and works like a catheter or something?

One last analogy. What would you prefer: a pilot who has been certified to fly that aircraft and has a minimum number of flight hours or giving every passenger a joystick sticking out of their seat tray so that maybe collectively they won't crash the plane?

Oh, and you kids get off my lawn (waves cane)! ;)

Re: Why Go is doomed to succeed

#160

Post by Dewie3 » Sat, Jun 13, 2015, 9:12 PM UTC

vezzy-fnord wrote: post #10

Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges clea…

It's weird to see so many of these "Go is a cleaned up/incremental step up from C" when

1) There have been plenty of natively compiled, garbage collected languages without much more fuzz than that before.

2) It seems more popular with people with a Python, Ruby etc. background rather than a C++ background (which was originally suspected would be a decent audience) or a C background.