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.
> Many of the "old" ways of thinking do not apply to Go
Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen.
When I say the language is broken, look at Go type system, then look at how Go reflection makes the language look a dynamically typed one. It would have been smarter to tone down the reflection and make it unnecessary with a smarter type system. If it is there then it is because it was necessary for Go designers. If it had not been, then Go would not need that insane reflection.
Now Go back to your Go code and remember all tricks you need to learn when working with arrays :
I use a testing framework[0] all the time in Go, and while I appreciate it's possible to write tests without one I think it's just pig-headed to not have something like that in the standard library.
If you just use testing.T you will most likely end up with a lousy, developer-hostile test suite. (Also, the default coverage metrics are very very weak. But I love Go just the same.)
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.
I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically.
The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code (if err != nil). In some languages, you hide the glue code in monads. In some languages, you hide the glue code in macros. In some languages, generics reduce the glue to chained methods on helper objects. In Go, once in a while you can hand-write a lambda function to manage a closed-over error variable and clean things up a bit, but that's about all you get.
> 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.
> what it does couldn't possibly be done in e.g. Python
What can you do in Go that you can't do in other languages? I can't think of anything. The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives, but you also lose a lot of expressive power.
My 2c: Go is incredibly convenient for non-programmers. I don't make a living writing software, I make a living answering quantitative questions, using computers. I use Python for most tasks, but when I need extra performance and/or portability, I grab Go every single time.
The main appeal is the quality standard library that covers most things I get in contact with. I could get immersed in it right away, because I didn't spend weeks trying to read the spec - the spec itself is so trivial it's mindblowing. The standard library feels very Pythonic in terms of reach. I've built tiny servers, parsed plethora of file formats, calculated maths, wrote data, (de)compressed stuff, encrypted things, ... The joy of not having to worry about 3rd party dependencies for all these is quite refreshing. And the appeal of few runtime issues thanks to static compilation is oh so excellent.
Sure, Go didn't invent any of these practices and sure, it doesn't have generics, runtime assembly, it's opinionated in a few places, its vendoring is subpar, ... But when you're someone who isn't really a programmer, these things don't matter much. I'm not here for the hype, I'm here for the productivity and ease of use.
Go is the VB, or the PHP of service development. Lots of obvious and immediate shortcomings, but with just the right amount of niceties for its domain in a very easy to teach and deploy package.
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.
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 weren't too happy with it.
For weeks (literally) i mulled it over, i really really really wanted to use Rust. Rust gives me a peace of mind that Go never came close to. Unfortunately, Rust does not fit the development speed nor developer experience[1] that this shop has.. and i really felt Go would be the best choice for this place.
My point to this post isn't to make a Rust vs Go comparison.. but rather, a wishlist for the hopefully eventual Go 2.0. I have no idea if/when that will ever be made.. but i hope it will, and i hope they adopt some things from Rust.
1. 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.
2. Proper error handling. I love error checking - i love it in Rust especially. It's very explicit, and most importantly, very easy to check the type of things. Recently i was reading an article about Go errors[2] and it made me realize how messy Go errors are. There are many (three in that article) ways to design your error usage, and worst of all your design doesn't matter because you have to adapt to the errors returned by others. There is no sane standard in use that accounts for the common needs of error checking.
3. Package management. It's a common complaint, i know. But Rust & Cargo is so excellently crafted.. Go just got it wrong. Recently i've been using Glide, and while it's a great tool, there is only so much it can do. It's a tool built to try and put some sanity in a world where there is next to no standardization. We need a Go package manager.. hell, just copy Cargo.
4. Enums. My god, Enums. Such a simple feature, but so insanely welcome and useful in Rust.
You'll note that i didn't list Generics. I know that's high on peoples list, but not mine. To each their own.. please don't start a holy war. (this is likely due to me using Go for ~4 years. I'm quite comfortable without Generics)
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).
I've had a little exposure to Go and seen how rapid development in Go can be while still maintaining decent performance.
Is anyone aware of scientific stack development in Go? Specifically, does HN think thee will be a Numpy or Scipy equivalent in Go or does this not make any sense?
Question : Is there a possibility that when Go package management is launched there will be a good opinionated framework like rails for GO . Because for new learners ORM , authentication etc things matter a lot. I know Go promotes use of native HTTP package instead of frameworks but it is a large barrier for newcomers and have risk of writing error-prone web applications.
Doing ORMs and auth without knowing what you're doing imply a huge risk out of itself, which Go tries to avoid.
If you have relational data the solution is not to use an ORM to half-abstract it away, it's to learn SQL. ORMs can be useful tools to avoid boilerplate, but they will show their ugly internals when SHTF, and those are always harder to understand than plain SQL.
As for auth, it's very easy to add to any web application or HTTP API using one of the many middleware solutions out there.
I'd suggest no. If Rails is the right tool for the job, there is no reason to not use Rails.
If Rails is not the right tool for the job, reimplementing Rails on top of Go isn't going to make it the right tool.
It is possible that some future "killer app" will emerge out of the Go ecosystem like Rails did with Ruby, but the effort to build something like Rails to duplicate Rails is not a particularly good use of someone's time.
I remember reading the initial announcement. I looked at the language briefly, and found some of the syntax too weird.
A few years later, I looked again and discovered I actually liked it very much. Still do. I mostly use it for toy programs I write in my free time, but I find that Go is very compatible with the way my mind works. I am currently trying to use Go at work for some of the tasks I usually would use Perl for. The fact that it comes with a relatively nice templating engine in the standard library makes it very attractive to replace the CGI scripts that have piled up over the years.
Interestingly, I had pretty much the same experience with Python - at first, I disliked the syntax ("no Dutch person is telling me how to indent my code!"), but then I came back a couple of months later and found that I really liked the language. (wrt indentation, Python only forces me to do something I would do anyway, it just took me a while to understand that.)
As a Pythonista , I tried small projects in Go and Rust but ended up liking Nim overall. Compiles to C and the syntax just feels like I'm writing Python.
has anybody evaluated building an api in Go vs Kotlin ? We are considering moving our financial tool api from python to either Go or JVM/Kotlin/JavaLombok+lambda .
I really like Kotlin as a language.. but im really worried about the future. Jetbrains isnt Google....
I like Kotlin also because we are an app-based startup.. and we have been considering Kotlin on the app side as well. That would be a nice crossover of engineering !
go is my favorite language period, apps that i write in go seem more stable, easy to maintain because the syntax is quite concise, and the performance of the code seems quite good.
my language history is basic, turbo pascal, c, java, perl, python, javascript, ruby, nodejs, go, swift.
what i really dont like about go or havent mastered yet about the language are error handling and interfaces. error handling forces these oblong parts of code where you check if err is not nil and then do something, that part makes the code look a bit verbose, but i like most other things about the language where i bear and grin.
gobyexample.com is an excellent resource for learning go. i have used go as a restful api backend, a websocket service, and static site generator, all pretty solid code with no errors. i used to run ror and found that not having a good orm at first made programming db apps annoying, but i learned sql syntax long before using orm's and it was just fine.
i have to admit that html templating languages are not that great (ace, amber), but workable.
go apps when written correctly run fast and efficiently.
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.
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.
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.
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).
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.
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.
[+] [-] gtrubetskoy|9 years ago|reply
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.
[+] [-] aikah|9 years ago|reply
Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen.
When I say the language is broken, look at Go type system, then look at how Go reflection makes the language look a dynamically typed one. It would have been smarter to tone down the reflection and make it unnecessary with a smarter type system. If it is there then it is because it was necessary for Go designers. If it had not been, then Go would not need that insane reflection.
Now Go back to your Go code and remember all tricks you need to learn when working with arrays :
https://github.com/golang/go/wiki/SliceTricks
Just because :
> A weakness of Go is that any generic-type operations must be provided by the run-time
https://blog.golang.org/slices
Now what was your point about the "old" ways of thinking again ?
[+] [-] biztos|9 years ago|reply
If you just use testing.T you will most likely end up with a lousy, developer-hostile test suite. (Also, the default coverage metrics are very very weak. But I love Go just the same.)
[0]: https://github.com/stretchr/testify
[+] [-] tptacek|9 years ago|reply
[+] [-] richard_todd|9 years ago|reply
The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code (if err != nil). In some languages, you hide the glue code in monads. In some languages, you hide the glue code in macros. In some languages, generics reduce the glue to chained methods on helper objects. In Go, once in a while you can hand-write a lambda function to manage a closed-over error variable and clean things up a bit, but that's about all you get.
[+] [-] junke|9 years ago|reply
Such as?
[+] [-] wyager|9 years ago|reply
What can you do in Go that you can't do in other languages? I can't think of anything. The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives, but you also lose a lot of expressive power.
[+] [-] mmargerum|9 years ago|reply
Multiple result sets Sorting slices
[+] [-] drej|9 years ago|reply
The main appeal is the quality standard library that covers most things I get in contact with. I could get immersed in it right away, because I didn't spend weeks trying to read the spec - the spec itself is so trivial it's mindblowing. The standard library feels very Pythonic in terms of reach. I've built tiny servers, parsed plethora of file formats, calculated maths, wrote data, (de)compressed stuff, encrypted things, ... The joy of not having to worry about 3rd party dependencies for all these is quite refreshing. And the appeal of few runtime issues thanks to static compilation is oh so excellent.
Sure, Go didn't invent any of these practices and sure, it doesn't have generics, runtime assembly, it's opinionated in a few places, its vendoring is subpar, ... But when you're someone who isn't really a programmer, these things don't matter much. I'm not here for the hype, I'm here for the productivity and ease of use.
[+] [-] sqrt|9 years ago|reply
If you've written code to do all those things, I think you'd be justified in calling yourself a programmer, even if software isn't your main gig. :)
[+] [-] 0xmohit|9 years ago|reply
[+] [-] jasonwatkinspdx|9 years ago|reply
[+] [-] bbatha|9 years ago|reply
[+] [-] bigato|9 years ago|reply
[+] [-] be_erik|9 years ago|reply
[+] [-] 0xmohit|9 years ago|reply
[0] https://blog.tylerchr.com/golang-18-whats-coming/
[+] [-] fizzbatter|9 years ago|reply
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 weren't too happy with it.
For weeks (literally) i mulled it over, i really really really wanted to use Rust. Rust gives me a peace of mind that Go never came close to. Unfortunately, Rust does not fit the development speed nor developer experience[1] that this shop has.. and i really felt Go would be the best choice for this place.
My point to this post isn't to make a Rust vs Go comparison.. but rather, a wishlist for the hopefully eventual Go 2.0. I have no idea if/when that will ever be made.. but i hope it will, and i hope they adopt some things from Rust.
1. 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.
2. Proper error handling. I love error checking - i love it in Rust especially. It's very explicit, and most importantly, very easy to check the type of things. Recently i was reading an article about Go errors[2] and it made me realize how messy Go errors are. There are many (three in that article) ways to design your error usage, and worst of all your design doesn't matter because you have to adapt to the errors returned by others. There is no sane standard in use that accounts for the common needs of error checking.
3. Package management. It's a common complaint, i know. But Rust & Cargo is so excellently crafted.. Go just got it wrong. Recently i've been using Glide, and while it's a great tool, there is only so much it can do. It's a tool built to try and put some sanity in a world where there is next to no standardization. We need a Go package manager.. hell, just copy Cargo.
4. Enums. My god, Enums. Such a simple feature, but so insanely welcome and useful in Rust.
You'll note that i didn't list Generics. I know that's high on peoples list, but not mine. To each their own.. please don't start a holy war. (this is likely due to me using Go for ~4 years. I'm quite comfortable without Generics)
[1]: By experience, i mean what they desire/expect. They're a Python shop after all, i didn't want to make a choice that would cause them to spend weeks/months feeling unproductive. [2]: http://dave.cheney.net/2016/04/27/dont-just-check-errors-han...
edit: minor text fixes.
[+] [-] kawsper|9 years ago|reply
[+] [-] oelmekki|9 years ago|reply
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
[+] [-] mseepgood|9 years ago|reply
[+] [-] mmmBacon|9 years ago|reply
Is anyone aware of scientific stack development in Go? Specifically, does HN think thee will be a Numpy or Scipy equivalent in Go or does this not make any sense?
[+] [-] psiclops|9 years ago|reply
https://github.com/gopherds/resources
[+] [-] f2f|9 years ago|reply
there's Gonum: https://github.com/gonum
[+] [-] appleiigs|9 years ago|reply
[+] [-] tbarbugli|9 years ago|reply
[+] [-] cdelsolar|9 years ago|reply
[+] [-] pvsukale3|9 years ago|reply
[+] [-] mixedCase|9 years ago|reply
If you have relational data the solution is not to use an ORM to half-abstract it away, it's to learn SQL. ORMs can be useful tools to avoid boilerplate, but they will show their ugly internals when SHTF, and those are always harder to understand than plain SQL.
As for auth, it's very easy to add to any web application or HTTP API using one of the many middleware solutions out there.
[+] [-] randomdata|9 years ago|reply
If Rails is not the right tool for the job, reimplementing Rails on top of Go isn't going to make it the right tool.
It is possible that some future "killer app" will emerge out of the Go ecosystem like Rails did with Ruby, but the effort to build something like Rails to duplicate Rails is not a particularly good use of someone's time.
[+] [-] thewhitetulip|9 years ago|reply
It is not a barrier, you might like the intro book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook... and https://github.com/astaxie/build-web-application-with-golang...
[+] [-] krylon|9 years ago|reply
A few years later, I looked again and discovered I actually liked it very much. Still do. I mostly use it for toy programs I write in my free time, but I find that Go is very compatible with the way my mind works. I am currently trying to use Go at work for some of the tasks I usually would use Perl for. The fact that it comes with a relatively nice templating engine in the standard library makes it very attractive to replace the CGI scripts that have piled up over the years.
Interestingly, I had pretty much the same experience with Python - at first, I disliked the syntax ("no Dutch person is telling me how to indent my code!"), but then I came back a couple of months later and found that I really liked the language. (wrt indentation, Python only forces me to do something I would do anyway, it just took me a while to understand that.)
[+] [-] sdsk8|9 years ago|reply
[+] [-] joshbaptiste|9 years ago|reply
[+] [-] sandGorgon|9 years ago|reply
I really like Kotlin as a language.. but im really worried about the future. Jetbrains isnt Google....
I like Kotlin also because we are an app-based startup.. and we have been considering Kotlin on the app side as well. That would be a nice crossover of engineering !
[+] [-] epynonymous|9 years ago|reply
my language history is basic, turbo pascal, c, java, perl, python, javascript, ruby, nodejs, go, swift.
what i really dont like about go or havent mastered yet about the language are error handling and interfaces. error handling forces these oblong parts of code where you check if err is not nil and then do something, that part makes the code look a bit verbose, but i like most other things about the language where i bear and grin.
gobyexample.com is an excellent resource for learning go. i have used go as a restful api backend, a websocket service, and static site generator, all pretty solid code with no errors. i used to run ror and found that not having a good orm at first made programming db apps annoying, but i learned sql syntax long before using orm's and it was just fine.
i have to admit that html templating languages are not that great (ace, amber), but workable.
go apps when written correctly run fast and efficiently.
[+] [-] ohstopitu|9 years ago|reply
[+] [-] tptacek|9 years ago|reply
[+] [-] maxlybbert|9 years ago|reply
[+] [-] brandur|9 years ago|reply
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.
[+] [-] travjones|9 years ago|reply
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.
[+] [-] masklinn|9 years ago|reply
[+] [-] adrusi|9 years ago|reply
[+] [-] bawigga|9 years ago|reply
[+] [-] amelius|9 years ago|reply
[+] [-] keymone|9 years ago|reply
[+] [-] jamescun|9 years ago|reply
https://golang.org/doc/faq#Does_Go_have_a_ternary_form
[+] [-] barrystaes|9 years ago|reply
[+] [-] oelmekki|9 years ago|reply
[+] [-] chrisper|9 years ago|reply
[+] [-] zeveb|9 years ago|reply