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

Four years of Go

blog.golang.org

Post reply on HN
Print view View original

161–170 of 202 posts

Re: Four years of Go

#161

Post by Roboprog »

axaxs wrote: post #97
laureny wrote: post #93

Earlier quoted context omitted.

> So we are pleased to see Go being used for the job it was designed for, This sounds a bit like revisionism. Rob Pike made it clear that the initial motivation for Go was the slowness of the C++ compilation. Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all. Personally, I think it will grab a decent amount of Ruby and Python programmers but it won't go much further…

I see that as an obvious mistake. C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. The problem though is that C++ people likely aren't C purists to begin with, or that C purists are too into C. Compounded by those who only drop to C when needed, you begin to see why it failed initially in this segment. I do think it will continue to gain ad…

The Go team rightly point out that C++ is needlessly complicated. That is why I despise C++. (I guess I was spoiled by doing Borland ObjectPascal first, as well)

Go provides most of the benefits of the JVM without being as much of a memory hog. Thus, it makes it a nice replacement for somebody who would rather use Pascal/Modula than C++. (Java originally was seen by me as a Pascal in C++ clothing for Unix)

Re: Four years of Go

#163

Post by wilderness_one »

enneff wrote: post #29
chetanahuja wrote: post #24

Looks like Go is succeeding more in the space where scripting languages like Python and Ruby are dominant and less in it's original intended space (systems programming). Rob Pike has written about it too. I wonder if they see this as an opportunity missed or unexpected boon.

We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense. So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.

I think of Go as systems programming for the web, not a typical, stand-alone system.

Re: Four years of Go

#164

Post by randomdata »

laureny wrote: post #86
sillysaurus2 wrote: post #48

Earlier quoted context omitted.

My experience with Go was bizarre -- I loved programming in it, but I don't understand why! For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem…

> Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages). There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's…

Like another commenter posted, REPLs are best suited for exploration. When you've got data and you're not quite sure what to make of it, or you want to do with it yet. IDEs, while also having their place, do not really fill that gap in any way.

I often find myself exploring in a language with a good REPL and then implementing the findings in a language that does not.

Re: Four years of Go

#165

Post by aangeles »

knodi wrote: post #6

I been using Go for a year now. Its hard to explain but for the most part I enjoy coding with Go. I could say i find it fun/enjoyable but that doesn't seem to convey the right feeling.

I agree with you coding in go is fun & enjoyable, It's a well designed language.

Re: Four years of Go

#166

Post by jff »

mynames wrote: post #133

Does anyone knows why there is no support for Go in Android?

Google's a big company with lots of fiefdoms, and Go is one of the smallest; I'm not sure it even counts as a fiefdom. Android is heavily invested in Java/C++ and those types don't like to admit that you can do anything worthwhile in Go.

After compiling Android a few times, though, you'll appreciate what the Go team was talking about when they said C++ compilation time was a driver for them.

Re: Four years of Go

#167

Post by shanemhansen »

tonyplee wrote: post #102
enneff wrote: post #50

Earlier quoted context omitted.

I think it's mostly a case of storage systems being a very core, important part of any software stack. If shit goes wrong at that level you're really screwed, so it takes longer to develop that kind of software and also longer for people to trust it enough to use it for serious things. But there is plenty of action at that level in the Go community, and as distributed consensus libraries like go-raft mature it will o…

Personally, I think there are other reasons. I developed software system with hundreds of millions to a few billions data entries items in the core object store (C++) and need to very fast access time. There are needs to open/load/read those objects in database in very fast speed ( 10 millions records. To get around those limitation, I end up design the data structures / datastore that eliminated the malloc/free, new…

Go has mmap and casting via the unsafe package, so the go solution to your performance problem looks exactly the same as the c++ solution.

I'd say go is actually an ideal language for building a database because:

1) syscall's and low level io (including mmap) are all pretty much first class. 2) networking (duh)

Some final ramblings: I realize "systems programming language" has lots of different definitions, some of which go doesn't meet due to it's stop the world gc. I'll concede that point, but as a parting shot let me remind you all that free'ing a tree of objects can cause similar pauses, although at a more convenient time. For me, I would assume that there are no guarantees in a database type system, you just want to go for something like: "99% of requests complete in less than a millisecond under certain controlled conditions". You never actually know if: 1) You have disk contention for that data you're reading causing pauses. 2) You've been swapped out and that pure in-memory operation slows down by an order of magniture 3) A billion other things.

For me personally, I don't really mind adding

4) The golang gc ran

To that list of things because benefits are worth the tradeoff, but that decision depends on the project.

References ---------- http://golang.org/pkg/syscall/ https://groups.google.com/forum/#!topic/golang-nuts/AzAtpOXt...

Re: Four years of Go

#168

Post by craigyk »

craigyk wrote: post #90

I want to like Go. There's definitely some parts that are great, but for a relatively new language there were missed opportunities to adopt awesome features in other PLs. There are also some internal inconsistencies that I find grating. These inconsistencies are particularly irksome given how opinionated Go is (and how much I agree with most of those opinions).

I went and looked up some of my notes back when I was trying out Go. I hope to learn from others wether these are real issues or simply my misunderstandings.

1. So we don't get generics, but the language built-ins seem to get to be type-parameterized (channels, slices, maps). Unfortunately the syntax for doing so for each of these is inconsistent (probably as a result of being special-cased rather than dog-fooded using language-level generics): []float, map[float]float, chan float.

2. Built-in types seem to receive other special treatments as well, which includes special initialization keywords (make vs. new) and built-in functions (len, cap, etc.) but I don't see why this needed to be the case, even for performance reasons. There's no reason why the these built-in types couldn't pretend to implement built-in interfaces to make more transparent with user-types while having the compiler optimize them with special-case functions for efficiency.

3. Unused variables are a hard error which is a completely understandable stance. Unfortunately, I think people may use workarounds to get around this. Also, I can't believe unused variables are a hard error, but uninitialized variables are not! Instead we are supposed to trust that everything is OK since they get initialized to some kind of "zero" value that isn't even under the developer's control.

4. Other small quibbles: I think pattern matching on function arguments could have been implemented as sugar that uses interfaces and method calls under the covers. Also named return values are ugly, and the function declaration syntax could have been made more concise.

Re: Four years of Go

#169

Post by grey-area »

quarterto wrote: post #138
alok-g wrote: post #82

Earlier quoted context omitted.

Are you saying that making sure the type is correct (just before the cast) becomes the programmer's responsibility? How often does this happen?

This is called a type assertion in Go. Whenever you ask for something as an interface but want to use the type's own method, you have to make a type assertion. interface Fooer { func Foo() } type Bar struct {} func (s Bar) Foo() {} func (s Bar) Baz() {} func DoFoo(f Fooer) { f.Foo() // fine // f.Baz() compile error f.(Bar).Baz() // fine }

Isn't the entire point of an interface to communicate the behaviour expected by the function though?

If you want a Bar specifically (as the DoFoo code does above), it should take a Bar as an argument.

If you want to accept any struct that satisfies Fooer, add all the methods to Fooer that you need them to satisfy...

Doing otherwise is just subverting the type system and you might as well use a blank interface and effectively have no type checking on your input - if you require a Fooer and then typecast someone might pass a Fooer and get a nasty surprise when it doesn't work.

Re: Four years of Go

#170

Post by asdasf »

tptacek wrote: post #64
sillysaurus2 wrote: post #48

Earlier quoted context omitted.

My experience with Go was bizarre -- I loved programming in it, but I don't understand why! For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem…

Golang is like a touring car. It's fast, but doesn't have the fastest engine. It's got some nice features, and it's comfortable (at least for the driver), but it doesn't have every bell and whistle. But: the handling is amazing; it's a monster in the corners. You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that c…

>especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.

Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.

Post reply on HN