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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

31–40 of 318 posts

Re: Seven years of Go

#31

Post by brandur »

ohstopitu wrote: post #17

I've always gotten into go on a high level and would love to delve in deeper. Coming from a java/js background, my pointers are a bit rusty (and I try to avoid them as much as possible). Would it be possible to use go without the use of pointers at all?

You will probably need to acknowledge their existence, but the good news is they're quite a bit easier to use than C and there are far fewer foot guns (i.e. no pointer arithmetic or any such thing). They also deference automatically so they're more ergonomic to write (i.e. you can call functions on a pointer as if it was a normal struct value, and there is no "." vs. "->" distinction like in C-family languages).

I'd suggest just getting in and trying to write some. It'll take a little bit of playing around, but the language is quite intuitive and I'd expect that you'd figure it out pretty quickly.

Re: Seven years of Go

#32

Post by jerf »

fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

"Channels without panics. Channels are awesome, but Go's design of them means that you have to learn special ways to design your usage of channels so that it does not crash your program. This is asinine to me. So much type safety exists in Go, and yet it's so easy for a developer to trip over channels and crash their program."

I've solved this in my programming by finally coming to grips with the fact that channels are unidirectional, and if you want any bidirectional communication whatsoever, up to and including the client telling the source for whatever reason it has closed, even that one single bit, that must occur over another channel of its own. Clients must never close their incoming channels. This does mean that many things that Go programmers sometimes try to bash into one channel need to be two channels.

But I agree it's a problem.

Re: Seven years of Go

#33

Post by tptacek »

gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

Strong, strong disagree on the idea that ORMs aren't necessary because of some property of Golang itself. Lack of decent ORMs is probably my biggest complaint about Go, and I think if you look at a lot of large web app packages you'll find people are all writing their own 40-60% of an ORM.

Re: Seven years of Go

#34

Post by masklinn »

ohstopitu wrote: post #17

I've always gotten into go on a high level and would love to delve in deeper. Coming from a java/js background, my pointers are a bit rusty (and I try to avoid them as much as possible). Would it be possible to use go without the use of pointers at all?

AFAIK Go pointers are closer to Java references than they are to C or C++ pointers. They mostly make the difference between "references" and "values" clear and flexible (though they do have pitfalls, value receivers versus pointer receivers are a big one) rather than move that to type-level semantics (as C# does).

Re: Seven years of Go

#35

Post by zeveb »

barrystaes wrote: post #12

These big funny logos, illustrations, and memes appearing in todays technology websites & videos really dont help for office environments. :( Colleagues should not visit websites littered with memes and cute drawings, but i do.

I love the look of the Go gopher, but you're not wrong. There's nothing wrong with having a little fun, but there is something wrong with prolonged immaturity. Where's that line? I don't know. Is the Go's use of the gopher on one side or the other of that line? I honestly don't know.

Re: Seven years of Go

#36

Post by greendragon »

fizzbatter wrote: post #28
greendragon wrote: post #18

Earlier quoted context omitted.

Curious what they weren't so happy about with Python? Was it purely performance? If so, did they consider PyPy, or at least profile what the slowest bits are so they can evaluate whether to throw everything out or just rewrite the slow bits? Was it the language itself? Not everyone likes dynamic languages, though it's odd they started with it. Did you consider Node at all?

Type safety mainly, i think. Performance is a definite concern, but they have a lot of internal applications and the stability of them varies. I offered up that less dynamic languages would provide more speed and reliability to boot. I know Python got types in 3.5, though i'm not sure if it has Go-like Interfaces (Traits in Rust). If not, i think it really should. I do firmly believe they'll be quite happy with Go th…

Seems a lot of the Go fans I read are former Python users burned by dynamic typing, so I agree they'll end up happy (or at least happier than Rust) with Go. Though one more option you might want to consider is Nim: http://nim-lang.org/ (It's pretty easy to get up to speed in it, especially for a Python user so long as they're not expecting to use fancy OO features.)

Re: Seven years of Go

#38

Post by masklinn »

jerf wrote: post #32
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

"Channels without panics. Channels are awesome, but Go's design of them means that you have to learn special ways to design your usage of channels so that it does not crash your program. This is asinine to me. So much type safety exists in Go, and yet it's so easy for a developer to trip over channels and crash their program." I've solved this in my programming by finally coming to grips with the fact that channels a…

> I've solved this in my programming by finally coming to grips with the fact that channels are unidirectional, and if you want any bidirectional communication whatsoever, up to and including the client telling the source for whatever reason it has closed, even that one single bit, that must occur over another channel of its own. Clients must never close their incoming channels. This does mean that many things that Go programmers sometimes try to bash into one channel need to be two channels.

Erlang got it right (again), by sending messages to processes they can only be unidirectional.

Re: Seven years of Go

#39

Post by fizzbatter »

jerf wrote: post #32
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

"Channels without panics. Channels are awesome, but Go's design of them means that you have to learn special ways to design your usage of channels so that it does not crash your program. This is asinine to me. So much type safety exists in Go, and yet it's so easy for a developer to trip over channels and crash their program." I've solved this in my programming by finally coming to grips with the fact that channels a…

I don't know how, but frankly i'd love to eliminate all simple panics. Nil pointers and channels seem two big culprits, offhand.

Granted, i left out nil pointer/interface panics because it seems unrealistic given how difficult it was for Rust to get rid of nil pointers. I'm not sure Go 2.0 could do it and still be considered Go.

Re: Seven years of Go

#40

Post by oelmekki »

barrystaes wrote: post #12

These big funny logos, illustrations, and memes appearing in todays technology websites & videos really dont help for office environments. :( Colleagues should not visit websites littered with memes and cute drawings, but i do.

Well, if that is your main problem with go, I'll say this is awesome :) (means the language itself is almost perfect)
Post reply on HN