Live data from Hacker News

Four years of Go

blog.golang.org

111–120 of 202 posts

Re: Four years of Go

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

The majority of big data systems are written in GC enabled languages.

Using a GC just requires a different mindset when designing data structures.

Re: Four years of Go

#114
post #101

So I've given Go a try with a couple of projects, and I like it so far. However, I really don't like its "warnings are errors" feature — in particular in respect to unused imports. If I comment out a line that uses an import, then it no longer compiles until I go to the top of the file and comment it out. Has anyone come up with a good solution to this? Preferably using Vim tooling.

Just use goimports which is removing/adding imports automatically based on your source code: https://github.com/bradfitz/goimports

Re: Four years of Go

#115

Does a chart without a y-dimension say anything at all?

It's search volume. The values are 0 at the origin to 100 at the highest point. But there are no units, I presume Google knows but doesn't give real numbers.

Re: Four years of Go

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

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 kinds of large applications programming, I don't know. But since a lot of apps do need the simple scripts and the application logic, it's kind of nice to have them all in the same language - which is one place where javascript may take over more, I suppose, if ever they can convince OS designers to build node.js tools into the default installs...

Re: Four years of Go

#117
post #58

I spend about 30% of my time system side in Go, and the rest in Node.js. I'm working to migrate almost all of my time to Go. The language is fun to work in and, personally, the overall experience is much improved over Node.js. It's exciting to see the momentum behind the language and the great people who are attracted to it.

Are Node.js and Go used in separate systems or do they have their own special places?

Re: Four years of Go

#118
post #100
post #53

Those experienced in Go, do you miss generics?

At first, I thought Generic is not that much desired. But after having some time with Go, I think Go really need generics. The problem is Go lacks immutable data structure. I believe everybody know why immutable data structure is required. Go slice and map are all mutable-only, so to make some read-only data view, we need to write all the containers by hand. Amount of code increases exponentially. It would be great i…

[deleted]

Re: Four years of Go

#119
post #64

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…

Normally, if I see a car analogy applied to programming languages (which hackers seem to do a lot), I instantly brace myself for petty debate on the semantics of the analogy itself (which hackers seem to do a lot).

This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).

Re: Four years of Go

#120
post #29

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.

No, I found the term systems programming to be brilliant to describe the kind of things exactly between applications and operating systems, and I think the Go team did a good job communicating this from day 1. It just seems it was misunderstood (maybe even intentionally so) by detractors that focussed too much on their very own interpretation of the term.
Post reply on HN