Live data from Hacker News

Four years of Go

blog.golang.org

171–180 of 202 posts

Re: Four years of Go

#171

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.

You may not find it useful, but that doesn't mean it is a universal truth. I always have ghci open.

Re: Four years of Go

#172

Earlier quoted context omitted.

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

I knew in theory one can use mmap and unsafe pointer in go.

One main different between C and go is this:

   C can type cast any mmap pointer and de-reference it got the values (pointer, offset to other locations) extremely fast - 
When one has to do this hundreds of millions times, that usually makes huge different in overall execution time. I personally know a lot of test cases that means minutes to finished certain operations v.s. days (+GBs of RAM).

Re: Four years of Go

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

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.

Re: Four years of Go

#174
post #170
post #64

Earlier quoted context omitted.

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.

This is more "Internet article of faith" than actual fact; it's something people say because it was said in some blog post once. For whatever it's worth to you, I've been a systems programmer since ~1995. The lingua franca of systems programming is C; Golang's type system is strictly superior to C.

Re: Four years of Go

#175
post #110
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…

> Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages). C# ==> http://www.mono-project.com/CsharpRepl C++ ==> http://root.cern.ch/drupal/content/cint C ==> http://www.softintegration.com/demos/chstandard/interactiveC... Java ==> http://www.javarepl.com/console.html People, please pay attention in compiler design classes and don't mix languages wit…

Also, the "Display" tab in Eclipse lets you execute random code while you are attached to a JVM via debugging, in the current breakpoint context - that is like 95% of a repl, imho. Many people don't know this one, and its very useful.

Re: Four years of Go

#176
post #68
post #28

Earlier quoted context omitted.

Programming is now multi-language and multi-paradigm. It matters more what you can do and not what you can do it in. Being able to compose libraries and systems from parts is way more important than knowing a specific language.

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?

Re: Four years of Go

#177
post #15

Earlier quoted context omitted.

Seems pretty far behind Java in terms of adoption. By 1999, virtually all new enterprise development was being done on Java. In 1997 Java was already #4 on the TIOBE language popularity index. Go isn't even close.

Java stepped into a natural void. There weren't many safe GC-based languages being used in the Enterprise at that point.

Yes, but there were several waiting in the wings. In the early '90s lots of people were expecting a GCed language - Smalltalk or Dylan or Self or CL or ML or ... - to make the breakthrough and become a mainstream application-programming language. Many of them (including Bill Joy) were pretty unhappy when it turned out to be Java that made it big.

Re: Four years of Go

#178

Earlier quoted context omitted.

> It's difficult for statically-typed languages to provide one. No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages. > there's no dynamic typing Yes, there is, through `interface{}`.

The main thing stopping Go having a REPL (when there are ones for C, for example) is that Go can't yet compile to, or load, dynamic libraries. This stops each bit of REPL being compiled up and executed, which would otherwise be simple.

And most likely never will, given the Go's team stance on dynamic linking.

Re: Four years of Go

#179

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…

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

Re: Four years of Go

#180
post #97

Earlier quoted context omitted.

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)

Funny, I have a similar background, but I despise C instead.

C++ gives me back stronger type and enough power to have a safer language than C can ever offer.

I also jumped into Java when it appeared for the same reason.

Until Go compilers provide support for generics and dynamic loading, I rather use C++1y, D or Rust.

Post reply on HN