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

121–130 of 202 posts

Re: Four years of Go

#121

Post by girvo »

mseepgood wrote: post #88
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…

> It's commonly believed that a REPL is valuable and increases productivity A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.

Depends on the language and the programmer. I find a properly configured REPL amazingly productive at nearly any point in a development life cycle.

Re: Four years of Go

#122

Post by ryanjshaw »

bad_user wrote: post #99
laureny wrote: post #86

Earlier quoted context omitted.

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

The REPL and IDEs are somewhat orthogonal. IDEs are extremely limited in fact, as they can only rely on static-type info to infer meaningful stuff about how your software will behave. A REPL on the other hand is a runtime instance of your software that you can touch and interact with. Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example…

Huh. The Visual Studio Immediate window [1] has existed since the days of Visual Basic [2]. What are you guys seeing as a REPL that I'm not?

[1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as...

[2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...

Re: Four years of Go

#123

Post by simonw »

mseepgood wrote: post #88
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…

> It's commonly believed that a REPL is valuable and increases productivity A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.

I do almost all of my most productive programming in a REPL (Python/JavaScript programmer here) and I have done for nearly 10 years now.

Re: Four years of Go

#124

Post by fauigerzigerk »

laureny wrote: post #91
thrownaway2424 wrote: post #27

Earlier quoted context omitted.

I assume you mean in terms of hype? Java can do stuff and people use it which is fine. The con was that it was inherently portable and secure and can be used for client software. None of that is true. Today if someone told me that our new client interface was going to be java that person would be reassigned to a role where their awful judgement would not resurface. Java today is basically the slower edition of C++ wh…

> I assume you mean in terms of hype? There is nothing wrong with hype if that hype is warranted, and Java certainly has an unmatched track record in terms of delivering solid, portable and easy to maintain code bases that power millions of applications today. > The con was that it was inherently portable and secure and can be used for client software. Java hasn't been pitched for client software since the death of a…

In my opinion Java is pretty good at CPU intensive tasks. Where it falls short is memory usage and memory management. A lot of software is being written in C++ because Java cannot use much of a machine's memory without incurring rather large garbage collector pauses. What Java needs is structured value types and an affordable implementation of pauseless garbage collection.

Re: Four years of Go

#125

Post by grey-area »

venuzr wrote: post #67
alok-g wrote: post #53

Those experienced in Go, do you miss generics?

That was my initial struggle as well coming into Go (I have worked for several years in C# & Java). You learn to work around this limitation using interfaces for both function parameters and return types. Frankly, I have had to do a little more explicit typecasting that I would have liked (going from interfaces to the actual type) but it is ok.

Isn't the idea behind interfaces that you add whatever methods you need to use to the interface? If that's the case you don't need or want to cast, you can just assume that the object given to you conforms to that interface...

Re: Four years of Go

#126

Post by shazow »

alok-g wrote: post #53

Those experienced in Go, do you miss generics?

One scenario I ran into is building a generic function call caching solution. Coming from Python, there tons of great libraries for memoizing and caching [0][1][2]. Even the Python 3 standard library has a simple one built in [3]. But building something similar in Golang proved to be near impossible.

I got a half-working solution [4] with a lot of interface{} and some reflection, but upon speaking with some of the Golang devs, the consensus was "this is not something you do in Go." From what I understand, you're expected to build a custom memoizing function for each set of datatypes you're expecting to use it for (which admittedly is not a ton of code), and generic helpers are not advised.

I can't say authoritatively whether "Go needs generics!" or not, but life has been much easier after porting my code back to Python—though a large part of it was because it was a fairly dynamic webapp which is still a pain point for Go. I hope to give Go another try soon, probably for a different project.

[0] https://pypi.python.org/pypi/dogpile.cache

[1] https://pypi.python.org/pypi?%3Aaction=search&term=cache&sub...

[2] https://pypi.python.org/pypi?%3Aaction=search&term=memoize&s...

[3] http://docs.python.org/dev/library/functools.html#functools....

[4] https://github.com/shazow/memoizer

Re: Four years of Go

#128

Post by p0nce »

codeka wrote: post #60

When I look at the Google Trends for "golang", China is the top region by a huge margin (the next highest region after China is Sweden at 30) [ http://i.imgur.com/XHW40kp.png ]. And the rise of interest in "golang" in general seems to correspond to the massive spike in China [ http://i.imgur.com/Y3oO2jf.png ]. I'm not really sure what that means...

Perhaps people mispelling "Gobang" http://en.wikipedia.org/wiki/Gomoku

Re: Four years of Go

#129

Post by bad_user »

ryanjshaw wrote: post #122
bad_user wrote: post #99

Earlier quoted context omitted.

The REPL and IDEs are somewhat orthogonal. IDEs are extremely limited in fact, as they can only rely on static-type info to infer meaningful stuff about how your software will behave. A REPL on the other hand is a runtime instance of your software that you can touch and interact with. Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example…

Huh. The Visual Studio Immediate window [1] has existed since the days of Visual Basic [2]. What are you guys seeing as a REPL that I'm not? [1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as... [2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...

Well, it's difficult to see what a REPL is or does, if you're calling Visual Studio's "Immediate Mode" a REPL. It's not. It can evaluate simple expressions, but you can't type arbitrary code in it and hence you can't do arbitrary development in it, so it's not a REPL.

The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.

Re: Four years of Go

#130

Post by pcwalton »

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…

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

I think it has nothing to do with the difference between C and C++ and everything to do with the reasons why people use C and C++: extreme performance, zero-cost abstractions, and integration with native libraries.

Post reply on HN