Live data from Hacker News

Six years of Go

blog.golang.org

161–170 of 327 posts

Re: Six years of Go

#161

Earlier quoted context omitted.

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!

And you had one data type that you used with that red-black tree, so you didn't mind not being able to abstract over the types of objects you were placing in the container. But we have lots of data types that we reuse for freelists and other types of containers. We don't want to have to reimplement that code for every single type we want. That's where generics save us.

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

I believe you that it wasn't a big deal in your case. But I disagree with your general claim. I think you're extrapolating from your use case to claim that generics aren't important (vital, in some cases). I'm saying that, in my use case, they are.

Re: Six years of Go

#162

Earlier quoted context omitted.

Best reason ever! Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun. If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides the…

Voice of dissension here. I switched from: * Mysql to MongoDB * PHP to Python * Javascript to Coffeescript All because I was bored of the old tech. and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that. Now to be fair, I learned a ton and I am so glad for that experience, but I lost my website.

MongoDB I can see, but Coffeescript is just sugar on top of Javascript, and I struggle to see how it could make any code unmaintainable – but i'd be interested to know why!

Re: Six years of Go

#163
post #66
post #51

Started using Go for my latest project (a successor to Evernote). It feels like such a relief, especially having just come out of a node.js project. It's everything I wanted in a (web-app) programming language, and for the first time I can say that a language has actually made my code better. I've never had a codebase this clean before.

I don't mean to be snarky and I'm definitely showing my age here, but isn't that exactly what devs were saying about node.js two years ago?

Perhaps it's because what makes a codebase messy is having written code in it over time.

In the beginning, those Node.JS codebases were clean and manageable. Then came bug fixes, changing requirements and refactors. 2 years worth of that led to something that was quickly becoming unmanageable.

But then came Go and, after a rewrite, everything was clean again! It doesn't matter than the code base is only 3 months old, I'm sure it's going to stay this clean forever!

But hey, should those Go codebases become messy a couple of years from now, I'm sure Rust will have matured into a worthy successor and, after a rewrite, we'll all have the cleanest codebases ever!

Re: Six years of Go

#164

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…

It's probably not at the point yet where you'd be interested in it (especially for tooling), but you might like Rust in the future.

Re: Six years of Go

#165
post #91

Earlier quoted context omitted.

> The prevailing feeling of Go is "getting things done". This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true. I think a more accurate way to look at Go is…

I agree with you, but there is something to the argument; it's just poorly phrased as "getting things done". gofmt, for instance, is uncontroversial. Taking the decisions about how to format code away from developers and standardizing it is widely seen as a win (a win Python flirts with as well). Well, there's a lot of other things in Go that have been pre-decided for you, not just the formatting. The net effect is t…

[deleted]

Re: Six years of Go

#166

I've been working on a huge monolithic project (for 1 person) for the better part of 2 years now. It is in PHP, but the backend segments ported over to various other languages like python, javascript(nodejs), and now to Go. Having now developed 30 micro-services for Go, which all utilise channels and thus run much faster than any other language I used is just amazing. Not only has my productivity increased majorly, b…

Have you tried the gorilla toolkit?

http://www.gorillatoolkit.org/

https://github.com/gorilla/

Re: Six years of Go

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

> 1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code. Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson This is especially useful when implementing REST servers/clients, because you can…

That is cool! Thanks

Re: Six years of Go

#169

Earlier quoted context omitted.

Best reason ever! Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun. If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides the…

Voice of dissension here. I switched from: * Mysql to MongoDB * PHP to Python * Javascript to Coffeescript All because I was bored of the old tech. and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that. Now to be fair, I learned a ton and I am so glad for that experience, but I lost my website.

Oh, you switch to MongoDB if you are bored with your current job ;) Otherwise PostgreSQL is what you switch to.

Re: Six years of Go

#170
I have a bit of a love-hate relationship going on with Go.

On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library.

On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using upper/lowercase is a shite idea. Package names (and packaging generally) are a mess. Magical built-in globals are a huge design smell. The lack of generics, as cliché a complaint as it is, results in loads of duplicated or generated code when building anything more complex than the simplest app. And so on.

I find the whole experience of using it to be unpleasant (rather like using a blunt knife), and yet it fits a set of requirements that mean I keep developing new projects using it – particularly high-performance small services that do things like fling JSON around, for which the built-in HTTP libraries + Gin are brilliant.

I'm looking forward to the point that a (trans|com)piler which smooths over the bad parts is available.

Post reply on HN