Live data from Hacker News

Seven years of Go

blog.golang.org

21–30 of 318 posts

Re: Seven years of Go

#21

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?

No, but pointers in Go are much gentler than pointers in C (for instance: there's no pointer math, and no pointer casting). If you understand the difference between passing by value and passing by reference (something you already have to understand to use Javascript), you've got all the background you need.

Re: Seven years of Go

#22

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?

Go pointers are pretty much Java references. You have to put in an asterisk every so often, but they aren't C pointers by any means.

Re: Seven years of Go

#23

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?

No, but also you use pointers for a far narrower set of semantics in Go than you do in languages like C. I think you'll find that if you have a grasp of reference semantics in java and javascript, then Go's pointers won't cause you much grief.

Re: Seven years of Go

#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 not necessary, and those that do aren't any good really.

I ended up inventing my own challenge - a time-series database backed by PostgreSQL (http://github.com/tgres/tgres), because I needed a difficult problem. Tgres is still not fully baked, but what it does couldn't possibly be done in e.g. Python, and not in C in as little time (even though it's been two years in development).

Contrary to what the blogs say, Go is _not_ an easy language to learn. Interfaces, goroutines, channels, selects, etc. will take a long while to become second nature, and if you're not using them then you're not really getting anything out of Go.

With respect to all the criticism Go is getting out there, e.g. lack of generics - I honestly can't say there is anything that bugs me at all. Some things may take getting used to, but usually in the end you're glad to have done so.

As someone who has done a lot of programming in my life (in Python, C (remember mod_python?) and also Ruby, and (with displeasure) Java) I can say that Go is a big deal in the language landscape and will not long from now be as big as Python - in fact I think it is Python developers who are most likely to switch over to Go for their next project.

Re: Seven years of Go

#25

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?

Most meaningful applications will require the use of pointers. For example, unmarshalling json comes to mind.

I wouldn't "avoid the use of pointers" if I were you. Rather, use them, run into problems, fix the problems, and you'll learn what you need to know about pointers in Go. Given your background, you code. Figuring out pointers in Go will be trivial for you, especially when you learn in context (e.g., writing something you think is cool). You got this.

Re: Seven years of Go

#26
post #5

Is there a recommendable (and somewhat recent) book on how to get started with Go?

For me, doing (in that order) the go tour [1], then reading "effective go" [2], then reading the language specs [3] have been a very good and immersive experience (of course, playing with some code along the way), better than a book. Bonus point: those are official docs, so you can expect them to keep up to date.

Note: "language specs" may sound scary at first (it certainly scared me), especially if you have w3c specs in mind. But this is actually very different, specs are pleasant to read and somewhat look like a documentation (past the mandatory "how to read those specs" section and its arid specs content conventions explanation).

[1] https://tour.golang.org/welcome/1

[2] https://golang.org/doc/effective_go.html

[3] https://golang.org/ref/spec

Re: Seven years of Go

#27
post #4
post #3

Go isn't a perfect language, but it strikes the right balance for me between productivity and safety. There are few other languages right now with the same ease of deployment, good tooling, excellent standard lib, and raw performance. Here's to another seven years.

Out of interest, can you point me to any GUI bindings or native Go GUI toolkits etc.? I would like to take a look, as I am normally writing native C++ GUI desktop apps. EDIT: Thanks for all the info everyone. I hope my responses don't appear argumentative - I am genuinely curious.

I'm certain there are more, but here are a few

platform native https://github.com/andlabs/ui

gtk http://mattn.github.io/go-gtk/

qt https://github.com/therecipe/qt

qml https://github.com/go-qml/qml

shiny (still being developed, Go native) https://github.com/golang/exp/tree/master/shiny

Re: Seven years of Go

#28

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…

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 though. Rust, not so much.

Re: Seven years of Go

#29

Earlier quoted context omitted.

Out of curiousity, why were the only choices Go or Rust? The type of thing you describe sounds ideal for Scala, Java, Kotlin, C# ...

I had to pick something i was familiar with too. We need this on a shorter timeframe (when is that not true? haha) , and evaluating a language is hard. As it is, this was a partial reason against Rust for me. After my time learning Rust, i'm still not 100% confident in my ability on it. My lack of experience and thusly productivity-hit is a real factor i had to calculate. Moreso with the rest of the team. With Scala/…

Best of luck with the project! :)

Re: Seven years of Go

#30

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…

i love go, but follow rust with a lot of curiosity. a very interesting language, and much more ambitious than go.

when i've played with it, one thing that was always a big turn-off for me was super-long compile times.

as someone who used to do a lot of c++, i am loathe to go back to a language with long compile times, no matter how good the language...

Post reply on HN