Thank you! Go has made me enjoy programming once again.
Six years of Go
301–310 of 327 posts
Re: Six years of Go
#302Earlier quoted context omitted.
maybe not specific to language, but compared to projects like Angular, React etc... Go has much less traction. Swift is a new language and is already much more widely used.
Not going to debate your claim, but Swift is an unfair comparison, as it is practically forced upon you if you want develop for one of the most important platforms today (you can of course still write stuff in objC, but Apple has made it clear that you'd better learn Swift).
>[Swift] is practically forced upon you if you want develop for one of the most important platforms today
>Apple has made it clear that you'd better learn Swift
Can anyone point to any statments to this effect by a leader at Apple? I haven't found any with a web search.
Re: Six years of Go
#303I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…
It's like most languages: if you go in hoping to write in the style of your favorite previous language, the language is going to resist you. Python does the same thing to you if you want to write in functional style. Ruby also punishes you if you want custom data structures (it's the Rails community that coined the term "golden path", right?). If you've got loads of duplicated code due to lack of generics, you may no…
I agree to some extent; different languages require different coding styles – that's totally fine. But that doesn't mean that there aren't valuable features to be taken from other languages, nor that they the language's design doesn't have problems. I strongly feel we should resist the temptation to believe that just because an idiomatic design design exists means there is no room for the language to become even better!
I won't harp on about generics in Go, because I think it's far from the biggest issue – but the hardcoded magic generics show that such a feature is useful. I'd love a simple set implementation, for example – but I often find myself reduced to writing dumb, ugly, difficult-to-read code to work around the fact that it's not possible.
SICP famously says "programs must be written for people to read, and only incidentally for machines to execute." And I can't help but feel, whenever I'm writing Go, that I'm spending far too much time telling the computer what to do – and nowhere near enough telling future developers what I wanted to do.
Re: Six years of Go
#304Earlier quoted context omitted.
Oh, you switch to MongoDB if you are bored with your current job ;) Otherwise PostgreSQL is what you switch to.
What's the problem with document databases, really? To be honest, for 80% of the projects I've ever worked with, fixed-schema rdbms's fitted just like... a square peg in a round hole! Heck, even for advanced analytics, I find mongo aggregates and mongo map reduce 10x more intuitive and SQL that inevitably ends up using zillions of non-portable tricks, stored procedures and god knows what. And atomicity and whatever e…
I was not referring to document databases as a whole, just to MongoDB in particular. You can use PostgreSQL as a document database. I heard too many stories with Mongo where people were dealing with locks or broken data instead of solving their business problems.
Re: Six years of Go
#305Earlier quoted context omitted.
I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…
If there a paradigm for handling multiple potential errors in a function? I'm usually stuck using: reply, err := redis.Givemethevalue(key) if err != nil { return err } thing, err2 := postgres.getById(reply) if err2 != nil { return err2 }
I tend to use structs like mini "dynamically" scoped namespaces for breaking up hairy tasks. Pattern looks like:
struct fooer {
x int
blah string
// ... more state
err error
}
func Foo(x int) (string, error) {
f := &fooer{x: x};
defer f.cleanup()
f.stepOne()
f.stepTwo()
f.stepThree()
return f.blah, f.err
}
func (f *fooer) stepOne() {
// ... do stuff and maybe set f.err
}
func (f *fooer) stepTwo() {
if f.err != nil {
return
}
// ... do stuff and maybe set f.err
}
func (f *fooer) stepThree() {
if f.err != nil {
return
}
// ... do stuff and maybe set f.err; set f.blah
}
func (f *fooer) cleanup() {
// ...
}
- No method signatures to patch up.
- Easier to non-local jump via return if you have some unusual control flow, etc.
- You can easily find all references to `f.err` to verify your error handling.
- The method names and step list take on a self-documenting quality.
Another key insight I had when learning to tolerate Go: It's ok to do throw away work. You don't need to abort instantly on failure, you can just make sure code paths handle zero values or other invalid states more robustly. For example, I sometimes add a function like:
func (f *fooer) fail(err error) {
if f.err == nil {
f.err = err
}
}
Re: Six years of Go
#306Earlier quoted context omitted.
> What the heck are you talking about > I can't decide if you're trolling or just genuinely this ignorant. Stuff like this breaks the HN guidelines. Please edit it out of your comments when posting here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html
I've had this message several times, but "What the heck are you talking about" doesn't break any rule whatsoever that I can find. In fact I fail to see how it could be toned down anymore. Are we not permitted to express confusion? Is 'heck' not the lightened American friendly version of 'hell'? How much more would you like me to blunt what I say in order that it doesn't violate unclear rules?
What you posted was uncivil. "What are you talking about" adds no information and is a variant of name-calling. Asking whether someone is "trolling or ignorant" is also name-calling, just with a branch in it. And "name X or retract your claim" is a form of intellectual bullying, so also uncivil.
Any substantive point you have will become sharper once you edit such rudeness out, so it isn't a question of "blunting", but of being respectful. Even if you don't respect the person you're talking to, you need to respect the community by holding yourself to a higher standard.
Re: Six years of Go
#307Earlier quoted context omitted.
I tried to go there to ask some questions while picking up the language, and what I got was RTFM, where manual includes the language specification, Effective Go book, and A Tour of Go. Apparently you're unfit to ask a question unless you know everything about the language already. Killed my excitement for learning the language.
What languages have nice IRCs? I ask b/c I was very pleasantly surprised by the extremely civil and noob-helpful #haskell. Are there other nice ones out there? Good to know...
#elixir-lang is quite nice and noob friendly too.
Re: Six years of Go
#308Earlier quoted context omitted.
Go's concurrency is limited to the CSP-style and favors share nothing problems. Languages like Clojure can do CSP just fine, but also have powerful language-level support for heterogeneous concurrency problems that are easy to use and easy to understand.
This isn't remotely true. CSP via goroutines and channels is idiomatic Go, but it's not the only option. Go offers mutexes and other concurrency primitives which, along with goroutines as lightweight thread analogues, allow what you're looking for.
The real problem here is that Go does not allow a user to create their own powerful concurrency primitives.
Locks exist, but you can't create a synchronized data structure. You can't create your own channel type because that's a generic thing which is reserved for the language authors, not the language users.
The whole point of modern programming is to create useful abstractions that allow a programmer to get things done without having to worry as much, and concurrency-related abstractions like parallel map-reduce and actors are powerful, but you have zero chance of making an abstraction for that in Go.
In Go it's basically CSP or bust; saying "you can use locks" is not an answer; locks are not a way to handle concurrency, they're a primitive for shooting yourself in the foot if you're unfortunate to be in a language where you can't abstract them away suitably.
Re: Six years of Go
#309Earlier quoted context omitted.
Go's concurrency is limited to the CSP-style and favors share nothing problems. Languages like Clojure can do CSP just fine, but also have powerful language-level support for heterogeneous concurrency problems that are easy to use and easy to understand.
This isn't remotely true. CSP via goroutines and channels is idiomatic Go, but it's not the only option. Go offers mutexes and other concurrency primitives which, along with goroutines as lightweight thread analogues, allow what you're looking for.
[deleted]
Re: Six years of Go
#310Earlier quoted context omitted.
Would you care to share some code example?
Happy to; I'll share the whole thing. http://pastebin.com/qBh6NRXc It's not cleaned up for easy reading (hell, I haven't even run `go fmt` on it ;) ). But it has unit tests and seems to work. ;) One thing worth noting is that it relies on the Storables to also be tagged with necessary JSON. It occurs to me that I could also have used tags instead of the key() function in the interface to specify which field in the St…
Just for you, I did a code review. The code review has two revisions, one where I gofmt'd it because I can't read non-go-fmt'd code anymore, and a second where I added comments expressing some concerns. I'll be honest, I gave up on a few bits just because it wasn't fun to do; I strongly suggest rethinking the use of a storable interface vs taking an 'interface{}' value for both gets and puts akin to how the json stdlib does it.
You can see the comments here: https://gist.github.com/TheDong/ce1d7b86b88c86d972b6/revisio...
You should never post code without a copyright license or disclaimer attached and I'd appreciate if you rectified that forthwith.