Live data from Hacker News

Six years of Go

blog.golang.org

151–160 of 327 posts

Re: Six years of Go

#151
post #83

I wish the gdb support were better or that delve were more stable. I also had some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and I got told I was wrong and there was no problem. Back in 2009 #go-nuts seemed to be a much different place. I write Go at work, and I admire many of the same things in Go I admire about Python. I still wish generics were part of the language and will say their exc…

I've been yelled at on #go-nuts too; I ran into what turned out to be an authentic limitation of Go's I/O scheduling, and was instead chided for _'ing out error results in my minimized example code.

What was the limitation?

Re: Six years of Go

#152
post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

> It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 yea…

If Java is still around in 2100 I weep for how little progress was made.

Re: Six years of Go

#153

Earlier quoted context omitted.

I think that falls into my use case of "simple". If you don't need to make those kinds of decisions, then by definition your problem set is simple (at least from a business logic point of view, even simple business problems get complex at scale). The problem, I have with the sentiment (which I grant is largely me over reading into it) is that a lot of the things people think of as noodling or a waste of time, are the…

I think you're missing a subtlety of my argument. I'm not saying you never need to pick a container that isn't a simple hash table, or design a DSL, or roll your own event loop, or design a hierarchy of abstractions. I've done all of those things in Golang --- even the event loop! But in C++, those are decisions you might make in parsing a config file, or in managing a simple table of sessions, or adding an LRU cache…

> You can't get away from the decisions. I have an array of stuff, and I have to decide, "do I want a list, an slist, a vector, or a deque, and what the fuck is a deque?". 98% of the time there is one sane decision that is so close to optimal that it's not worth tinkering with.

I'm currently working on a project (WebRender) in which we keep using the standard library hash table in the first cut of code whenever we need an associative lookup table, and every time we use it it keeps coming up #1 in the profile. Almost every single time. We then have to switch to another, more optimized data structure, and generics really help here so that we can reuse these data structures. In fact, if we didn't have them, we'd probably be sunk.

Re: Six years of Go

#154
post #83

Earlier quoted context omitted.

I've been yelled at on #go-nuts too; I ran into what turned out to be an authentic limitation of Go's I/O scheduling, and was instead chided for _'ing out error results in my minimized example code.

What was the limitation?

Very fast port scanner with fine-grained timers, the I/O scheduler leaks file descriptors (briefly, but enough to be a drag).

I got around it by coding down to syscalls and allocating a goroutine to a simple poll() loop.

Re: Six years of Go

#155
post #142

Earlier quoted context omitted.

Do you really thing it's fair to blame a whole language for making your project unmaintainable, when you admit you were just learning it -- and you had come from PHP?

php is much maligned here on HN, but it doesn't mean that it automatically makes for a bad programmer. Here's another exmaple for you: Over the years, the project I work on has used the following: vb .NET C# .NET WCF asp Webforms MVC2 MVC4 The result is a maintenance headache (it's not a nightmare, but we do have to pause every time we unexpectedly encounter VB!), and that's where we've been disciplined enough to sta…

> but it doesn't mean that it automatically makes for a bad programmer.

I came to PHP late from proper languages circa 2008/2009ish been programming since I was a kid in the 80's, I've no great love for the language, it's purely a tool and once you ignore the rusty bits it's not a bad language for a lot of web stuff but I've never been concerned with purity/beauty for it's own sake I just care about what I can do in a language, these days I use PHP a lot on the web, Python for just about everything else (even my build system for automating browserify is in Python using Envoy) and I play with Go and such on the side.

All that and there is a lot of work in PHP clearing up after others (if you like those kinds of engineering problems which I do) which is also nice.

Re: Six years of Go

#156

Earlier quoted context omitted.

I think you're missing a subtlety of my argument. I'm not saying you never need to pick a container that isn't a simple hash table, or design a DSL, or roll your own event loop, or design a hierarchy of abstractions. I've done all of those things in Golang --- even the event loop! But in C++, those are decisions you might make in parsing a config file, or in managing a simple table of sessions, or adding an LRU cache…

> You can't get away from the decisions. I have an array of stuff, and I have to decide, "do I want a list, an slist, a vector, or a deque, and what the fuck is a deque?". 98% of the time there is one sane decision that is so close to optimal that it's not worth tinkering with. I'm currently working on a project (WebRender) in which we keep using the standard library hash table in the first cut of code whenever we ne…

Again, I'm not arguing that we never need custom containers.

Re: Six years of Go

#157

Earlier quoted context omitted.

> You can't get away from the decisions. I have an array of stuff, and I have to decide, "do I want a list, an slist, a vector, or a deque, and what the fuck is a deque?". 98% of the time there is one sane decision that is so close to optimal that it's not worth tinkering with. I'm currently working on a project (WebRender) in which we keep using the standard library hash table in the first cut of code whenever we ne…

Again, I'm not arguing that we never need custom containers.

I'm saying that some projects need custom containers all the time—to the exclusion of the built-in ones—and need to reuse the implementations of those containers.

Re: Six years of Go

#158

Earlier quoted context omitted.

I picked up Go because C frustrated me so much. Can you give some examples as to why you prefer C?

Not the author... I prefer C99. A smattering of features I like: * Variable Length Arrays * Variadic Macros * Designated Initializers * Anonymous Structs * Compound Literals Some of the meta-"features" I like: * No built-in runtime or GC * A choice of dynamic vs static compilation * A good libc is wonderful but not necessary to get work done fast * The tooling is mature and plentiful I'm sure Go is a fine language. I…

I just want to point out:

1. Variable Length Arrays: Go has slices 2. Anonymous Structs: Go has these 3. No built-in runtime (in C): This is not true unless you are compiling -ffreestanding -nostdlib, etc. I have done this in C, but such programs have to call system-calls directly and provide their own malloc, etc.

Re: Six years of Go

#159

Earlier quoted context omitted.

Again, I'm not arguing that we never need custom containers.

I'm saying that some projects need custom containers all the time— to the exclusion of the built-in ones —and need to reuse the implementations of those containers.

So did we! We didn't use Golang's maps to implement limit order books; we used a red-black tree. We did not build our own, nor did we find a red-black tree that was designed for order books.

This just isn't as much of a big deal as people think it is. Go makes it a drag to use a custom container, but it doesn't make it hard, and that might be how it should be!

Re: Six years of Go

#160
post #58

Earlier quoted context omitted.

Having said that Rob Pike told me that Go is now one of Google's "official languages".

... which just means developers at Go now have permission to use it, along with Python, Java, and C++, to build things, right?

what does "just" mean?

What are your company's official languages used for?

Post reply on HN