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

51–60 of 318 posts

Re: Seven years of Go

#51

Post by vram22 »

tptacek wrote: post #33
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.

>Strong, strong disagree on the idea that ORMs aren't necessary because of some property of Golang itself.

Might be interesting to hear reasons - by both you and the parent commenter.

Re: Seven years of Go

#52

Post by 0xmohit »

drej wrote: post #47

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 d…

Packaging in Go is bound to improve in the coming releases. You can follow Go Package Management list: https://groups.google.com/forum/#!forum/go-package-managemen...

Re: Seven years of Go

#53

Post by pcwalton »

fizzbatter wrote: post #39
jerf wrote: post #32

Earlier quoted context omitted.

"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.

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

That wasn't difficult at all.

Re: Seven years of Go

#54

Post by randomdata »

tptacek wrote: post #33
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.

In my experience there is one property of Go that minimizes the need for a good ORM, and that is that the problem domain Go excels in does not have great overlap with the problem domain that ORMs excel in. What interfacing with a relational database does come up is of the nature that does not fit well into the ORM model anyway.

Of course, you can write software in the same domain where ORMs excel in Go, but I am not sure it is the best tool for that job. A good ORM would go a long way to making that less true, but I'm not sure even that would put Go at the same level as tools that are geared towards that type of problem. Go, like all tools, is still targeted at a certain class of problems.

Re: Seven years of Go

#55

Post by sqrt »

drej wrote: post #47

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 d…

> I've built tiny servers, parsed plethora of file formats, calculated maths, wrote data, (de)compressed stuff, encrypted things, ...

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. :)

Re: Seven years of Go

#56

Post by vram22 »

72deluxe wrote: post #4
be_erik wrote: 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.

Here is one - WALK:

https://github.com/lxn/walk

A friend had used it in a commercial project, and IIRC he said it worked okay. Not tried it myself yet. I think it wraps the Win32 GUI SDK but also has a declarative mode [1] (at least for GUI widget layout) on top, or something like that - only looked at some sample code briefly.

[1] meaning you can declare your GUI layout declaratively, but in Go code - it does not need XML or some other language or markup format like some declarative approaches do - IIRC.

I actually wish the Go team had built support for some / many of the major GUI toolkits on major OS's (at least) from near the start of Go's development. I realize that there could have been, or still could be, some issues with that, due to differences between Go and (C and C++) [2] models (object file format, calling conventions, stack and heap layout, etc. - basically compiler and compiler-output-related stuff), and hence it may not be easy to create bindings from the former to the latter. Not familiar with this area.

[2] since many of the major GUI toolkits are natively written in C or C++, so a Go wrapper would need to bind to them.

Not complaining though, I know what they (the Go team and community) have already done is a huge achievement anyway.

Re: Seven years of Go

#57

Post by pcwalton »

brandur wrote: post #41
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…

I've taken a very similar path recently myself and started looking into Rust. > 2. Proper error handling. I love error checking Hugely agree here. I can get behind Go's overall mentality of returning errors instead of throwing exceptions, but in my mind there are not enough primitives in the language to keep this style of coding safe and sustainable. Rust's `Result` type, `try!` macro, and pattern matching are an inc…

> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry).

It depends a lot on your use case. I wouldn't say that Go is unconditionally more practical: there are cases in which you just can't use it.

Re: Seven years of Go

#58

Post by Mr_T_ »

mseepgood wrote: post #6
kawsper wrote: post #5

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

"The Go Programming Language" by Alan Donovan and Brian Kernighan: http://gopl.io

Highly recommendable. It's the next modern classic after K&R's 'The C Programming Language'.

Re: Seven years of Go

#59

Post by [deleted] »

Thaxll wrote: post #16
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…

Choosing Rust in a shop where no one knows Rust is indeed a big mistake where in Go it's pretty easy to pick up the language quickly.

[deleted]

Re: Seven years of Go

#60

Post by sandGorgon »

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 !

Post reply on HN