Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Half a decade with Go

blog.golang.org

Post reply on HN
Print view View original

81–90 of 257 posts

Re: Half a decade with Go

#81

Post by timtadh »

TheHydroImpulse wrote: post #43
timtadh wrote: post #27

Earlier quoted context omitted.

I feel like you haven't met a lot of Go programmers in that case. The programmers I have met who use Go or are interested in it are often genuinely good programmers. Of course there are "crowd" followers in any language as popular in Go but Go is not a "Blub" language nor does it attract Blub programmers. Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want tha…

> Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice. Rust doesn't do that. Rust expands the macros a…

yep. I never meant to imply that rust macros were expanded at runtime. I was trying to use rust as an example of a c-style langauge with a nice macro system.

Re: Half a decade with Go

#82

Post by stanleydrew »

wwweston wrote: post #57
ansible wrote: post #47

Earlier quoted context omitted.

So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)? As discussed elsewhere on this page, Go is not the most feature-rich language out there. But it does have features that seem to help my solve my problems with a minimum amount of fuss. Like using interfaces liberally, instead of having to define classes. Having lex…

I like functions as first-class values and closures. If they weren't present, I might well have bailed months ago. :) And from various experiences doing OO with other languages, I can kindof buy that Go interfaces are often 80% of what you want. Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal wi…

It's a painful exercise (entirely due to Apple, not Go), but we implemented an Apple Push Notification Service provider in Go that relies on several of its concurrency primitives.

I think implementing a simple HTTP proxy might also be a really good exercise, though I haven't done it.

Re: Half a decade with Go

#83

Post by djur »

davecheney wrote: post #69
djur wrote: post #55

Earlier quoted context omitted.

Rust isn't nearly as stable as Go. It still hasn't reached the state that Go was in when it was released outside Google. That's not a judgment of Rust, just a result of it being developed in the open instead of inside a company, and it being much more ambitious than Go.

Go was released as an open source project on the 10th of November 2009. Which part of that is _not_ open to you in a way that Rust is ?

Both of them are open now. In 2009, it was possible to write a guide to writing software in Go:

https://web.archive.org/web/20091113154825/http://golang.org...

That looks a lot like today's Go. All of the major design decisions were made, distinctive Go concepts (slices, maps, interfaces, goroutines, switching on concrete type, etc.) are all present. Most of the code examples would compile today with only a few tweaks (if any).

Suffice it to say that Rust was not in that state in 2010. It was barely in that state by 2014. Go was released as a beta; Rust was released as a pre-alpha. That isn't a judgment of either language or community.

Re: Half a decade with Go

#84

Post by jlouis »

coolsunglasses wrote: post #68
platz wrote: post #64

Earlier quoted context omitted.

I don't like go either, but I won't believe that a ghc webserver is a fast as a go webserver until we can see it in the techempower benchmarks.

The Techempower benchmarks are using the old version of GHC, 7.6, and the Golang devs have been tuning Go's core libraries to win at this specific benchmark.

Even then, it is only a factor of 2 slower. That is next to nothing.

Re: Half a decade with Go

#85

Post by coolsunglasses »

jlouis wrote: post #84
coolsunglasses wrote: post #68

Earlier quoted context omitted.

The Techempower benchmarks are using the old version of GHC, 7.6, and the Golang devs have been tuning Go's core libraries to win at this specific benchmark.

Even then, it is only a factor of 2 slower. That is next to nothing.

Right, precisely, and this is at a very silly tier of microbenchmarking where you're doing little to no actual work, something you virtually won't ever find in the "real world".

Re: Half a decade with Go

#86

Post by diyorgasms »

codemac wrote: post #17

You still need a Makefile if you use things like godep, or their new `go generate` stuff. They have a long way to go on tooling; however, getting to say that is a luxury, due to just how "right" golang has been for systems work. Golang has been amazing to work with, and has just been stupidly productive. I miss debugging (gdb) and generic compile tools like tup, but that's about it!

Do people prefer not using Makefiles? I ask because Makefiles are a standard part of my workflow, and while I know I can 'go build' or 'go [whatever]' I still cling to my Makefiles as a preferred tool.

Re: Half a decade with Go

#87

Post by macu »

kjksf wrote: post #16
wyager wrote: post #12

Earlier quoted context omitted.

What do you think is worthwhile about Go? I agree that the tooling is nice, but beyond that, there is nothing interesting to me. Goroutines aren't interesting; languages like Erlang and Haskell got green threads right many years before Go was on the scene.

You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer. Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html for an example of that line of think…

> I program in Go because when writing code, it irritates me less than other languages.

This is how I feel too. There are countless styles of prose, but some styles are restricted deliberately for aesthetics or practical reasons. I prefer to write prose in plain terms, and Go enables me to write code the same way. Some languages more than others have parts that stick out in odd ways, and add unwelcome personality to my code.

Yet sometimes I wish to put higher concepts into abstract terms, and Go is less expressive here. You can't always shape things the way you want, and you can't build reusable parts with the same flexibility as in other languages. But, when it comes to tinkering and giving form to ideas, I am more productive working with a basic set of LEGO than a box of all the specialized pieces someone may have thought I might ever find a use for.

Re: Half a decade with Go

#88

Post by enneff »

meowface wrote: post #75
wwweston wrote: post #39

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment. And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java ( http://blog.plover.com/prog/Java.html ) approximate my experience Go fa…

Going by Paul Graham's "Blub" essay ( http://www.paulgraham.com/avg.html ), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.

The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.

Re: Half a decade with Go

#89

Post by spotman »

wwweston wrote: post #39

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment. And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java ( http://blog.plover.com/prog/Java.html ) approximate my experience Go fa…

If you have spent six months, is that just occasionally tinkering and reading things online, or actually using it fairly regularly?

If you have developed software in go, and after a couple months you aren't finding its saving you time, or at least pleasant to work with, maybe its not for you.

I feel like it is similar to C, but more opinionated, with much less rope to hang yourself, and often things I would have used C or Java, I find doing them in golang saves me plethoras of time.

It is opinionated, but for me the aha moment was after I learned enough of the standard libraries to feel comfortable in the language, I find myself getting things done at lightning speed, and it has performance that is as solid as the jvm in your average use case.

I find the code is also pleasant to read, and the language lends itself to writing verbose, simple code, which I find easier to debug than overly abstracted systems.

Re: Half a decade with Go

#90

Post by reverius42 »

enneff wrote: post #88
meowface wrote: post #75

Earlier quoted context omitted.

Going by Paul Graham's "Blub" essay ( http://www.paulgraham.com/avg.html ), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.

The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.

I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.
Post reply on HN