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

181–190 of 202 posts

Re: Four years of Go

#181

Post by pjmlp »

jff wrote: post #166
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.

Well, support for Go on Android is already open for quite a while, so it seems to be low priority

https://code.google.com/p/android/issues/detail?id=39482

Re: Four years of Go

#183

Post by bad_user »

pjmlp wrote: post #179
bad_user wrote: post #129

Earlier quoted context omitted.

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

> 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. So what?! Languages and implementations are not the same thing.

Err, what?

So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.

Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's the community's culture like?

Lately I've been learning some Clojure. I'm fascinated by how Clojure developers work with the source-code. Emacs is an extremely capable editor, but for Clojure it's a full-fledged IDE and a shell for the REPL and it can do anything you'd expect from an IDE. And the whole workflow is basically typing code, sending that piece of code for evaluation in the REPL, typing in the REPL some quick invocations to see how it works, rinse and repeat. The learning experience is also completely awesome, as for some reason you end up reading a lot of the standard library's implementation - coupled with the REPL on the other side in which to quickly type what you read - the workflow is amazing (though Smalltalk developers are probably laughing at me right now).

Re: Four years of Go

#184

Post by pjmlp »

bad_user wrote: post #183
pjmlp wrote: post #179

Earlier quoted context omitted.

> 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. So what?! Languages and implementations are not the same thing.

Err, what? So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language. Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's t…

> So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.

Reference implementations only define languages that lack a proper ANSI/ISO/ECMA standard.

> though Smalltalk developers are probably laughing at me right now

Yes we are. :)

Emacs is a light version of a Lisp Machine. Now imagine how would your OS be, if everything would be as customizable as Emacs.

Sadly, Lisp machines and Smalltalk environments died on the mainstream.

Re: Four years of Go

#185

Post by genwin »

penguindev wrote: post #176
genwin wrote: post #68

Earlier quoted context omitted.

I'm thinking Go has got to eventually eclipse Python in popularity, since the former can do the same work using a fraction of the servers, for about the same coding difficulty.

"for about the same coding difficulty." Oh really? Checking every single function call for an error return code doesn't complicate things?

If the function has less chance of erroring than a hardware failure, why check? I have a function that calls functions that call functions and so on. At the top level function I check if Go has panic()ked; if so I recover() and report the nice error message I want. Seems to offer close enough functionality to try...catch.

Re: Four years of Go

#186

Post by jmelloy »

bad_user wrote: post #129
ryanjshaw wrote: post #122

Earlier quoted context omitted.

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

LinqPad isn't bad.

Re: Four years of Go

#187

Post by enneff »

laureny wrote: post #93
enneff wrote: post #29

Earlier quoted context omitted.

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.

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

> Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all.

This is a strong overstatement. It's true that we thought more C++ programmers would be into Go, but it's also true that there more than a few teams at Google that have moved from C++ to Go, or chosen to use Go instead of C++ for new projects. It's not a black and white thing; there is no archetypal C++ programmer that does or does not like Go.

To reiterate: Go was designed for systems programming. People are using Go for systems programming. On top of that, there are many others using Go for other purposes. We're pretty thrilled about this.

Re: Four years of Go

#188

Post by yuushi »

alok-g wrote: post #80
yuushi wrote: post #76

Earlier quoted context omitted.

I think interface{} is a horrible, horrible hack. For me, the answer is an emphatic yes.

Could you please explain more? :-)

Sure. Think of void * in C. interface{} in Go isn't really that different, there's just a bit more language support for testing if it satisfies a specific type or not. Add in type assertions, and it's basically as though you had a dynamic_cast in C++ that worked from void * to an interface type.

To me, it just seems ugly. I like a type system where I know what a type is at each point, and there isn't some ugly "catch all" type that you can use when you run out of other options, which effectively just throws away all type information (and this is what interface{} does, as everything implements it).

Re: Four years of Go

#189

Post by deckiedan »

asdasf wrote: post #173
deckiedan wrote: post #116

Earlier quoted context omitted.

One place Go won't be replacing python (or perl) is in the "smarter shell-scripts that don't suck" space. Being able to write a 10 line script, dump it on the server and point cron at it, and then open it in situ to see what it's doing is invaluable. Also, when things get a bit edgy, to copy the file, edit 2 lines, and run it to fix something that the original didn't cover... It may be better than Python for some kin…

I find good old /bin/sh is better than perl or python for the use case you are talking about. Perl rose out of the huge gulf between shell and C. The distance from shell to go is much smaller.

I have a bunch of scripts which are written in standard shell, and for simple stuff, it's fine. But as soon as it starts doing file name manipulation, or working with collections of files (say finding the age of the most recently changed file in a directory, and checking how long ago that was and changing color-extended attributes of the enclosing directory so projects untouched in over a month turn grey...), and you have people on the network who name files by copying and pasting from word documents (I didn't even know you could put a newline in a filename!), I've found python to be much more reliable and easy to write correctly.

Re: Four years of Go

#190

Post by stass »

cmccabe wrote: post #158
stass wrote: post #108

Earlier quoted context omitted.

And yes, REPL is still helpful even if the compilation is fast; amusingly most languages that have REPL features fast compilation (at least those not based on JVM). The benefit of REPL is that it preserves state which one can experiment on, and sometimes that state can be cumbersome/take long to acquire.

Most languages that have "traditionally" shipped with a REPL don't feature compilation at all. So yeah-- I guess that's fast? (Before you start, I'm not interested in pedantic arguments about how any language can be compiled. I know.) If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test su…

One of the languages that originally featured REPL, Lisp, was always compiled, both to machine code or byte code. Ditto smalltalk. I am not even sure which "traditional" languages you are talking about.

When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.

Post reply on HN