661–670 of 670 posts
Earlier quoted context omitted.
Haskell and Ocaml, e.g. http://okmij.org/ftp/Computation/typeclass.html .
I thought Ocaml still boxed values, so there's no equivalent of value witness tables?
Earlier quoted context omitted.
OP was talking about getting started. I also don't understand why you can't use the same GOPATH across multiple projects, especially with godeps?
Multiple unrelated Go projects in different GIT/SVN repositories. GOPATH experience is painful.
Earlier quoted context omitted.
I can sympathize with the dislike of exceptions. I very much prefer Rust's error handling model (return Result ) The fact that Go has had this much success without generics is mind-boggling to me.
Because Google. Go is quite similar to Limbo, by some of the same authors, how much success did it have outside AT&T?
No, it was adopted quickly because it's a simple, script-like language producing static binaries that didn't require any runtime, highly portable with built-in cross-compilation, requires very little resources, is able to perform pretty damn good and has an extensive standard library (although not perfect) supporting many modern technologies.
That are a lot of boxes it ticks off. I remember wanting to start hobby projects with friends where the end-result would preferably be a native binary, and the limit was that I was the only-one with a C/C++ background. Now anyone with some scripting background can pick up Go in a few days, without having to worry too much about a build system, portability, cpu architectures, performance, memory leaks, ...
Sure, Google was the initial push, but it only really took off once projects like Docker showed it's potential.
Earlier quoted context omitted.
I use one GOPATH and work on dozens of projects. I would hate it if I had to change GOPATH often. In Go, if you find yourself fighting the system, chances are you are doing it wrong. 'go get github/user/project && cd $GOPATH/github/user/project'. And to avoid dependency issues, I use one of the many vendoring tools. Currently 'govend'.
You are limited to one repository. So all your Go projects have to live in one repo. That's the issue, and it's a big design flaw - do away with this GOPATH
I don't have go/src/ checked in. Is that what you mean? If you do that, you are doing it wrong. I have many, many go/src/$org/$project directories, each of them have their own source control (most of which is different git repos). If I am working on my stuff, cd $GOPATH/src/github.com/sethgrid/$project. That is the repo under source control. Do any development I want, push up any changes to that repo. Rinse and repeat. I can then cd $GOPATH/src/github.com/sethgrid/$project2 and do the same. When I want to pull down $project3, I just `go get github.com/sethgrid/$project3` or manually clone it and I can cd over to it and work on it separately.
Maybe I'm not understanding your criticism.
Earlier quoted context omitted.
the use of the monotonic click example is also interesting because of the similar tone of responses to that issue. I think it's just the rsc way. basically it goes like: > If google isn't screaming about it, it's not important. > If google has a workaround, then it's fixed.
As a maintainer, you're bombarded with reasonable requests (I think around 10 a day on the Go project). Part of your job is to turn down hundreds of these and pick the few that benefit the most people from a diverse set of users, and also don't break anything or extend the api surface too much. Then whatever you choose people complain vociferously. Sometimes good requests get ignored in that noise. Choosing is hard,…
Admitting a mistake on "generics" would probably go a long way towards credibility for the team.
No matter how many excellent decisions they've made that have delicately balanced opinions and tradeoffs, this one hasn't gone over well, and it's very widely known.
Earlier quoted context omitted.
Which is exactly what software engineers should spend most of their time doing.
, err = if err != nil { return nil, err } , err = if err != nil { return nil, err } Is not what software engineers should spend time on, definitely. Not automating ubiquitous trivial propagations with at least explicit "rie " (rie for "return if error") is a complete engineering fail under any philosophy. Oh, I have an idea . If ", err" part is missing from lvalue, insert that mantra automagically under #pragma ARIE=…
The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++ Improvements to package management is probably the highest item on my wishlist for Go 2.
Earlier quoted context omitted.
I was merely suggesting to indulge the author, especially now that generics might actually happen.
The problem is that the community did indulge the author and the other Go maintainers 5 years ago and their was an apparent refusal to see lack-of-generics as an issue, almost as though Turing-completeness was sufficient justification to not include them. "Find us examples and show us so we can ponder this further" is incredibly condescending after we did that 5 years ago and they decided to stall (or to use the auth…
It's actually a classic bulshitting tactic by people who have no actual argument. Effectively, it's "well, we'll defer a choice until we can PROVE that decision X is PERFECT in EVERY way."
That's not to say: IF there's a real, quantifiable doubt, then by all means, continue to discuss (but preferably set time limits), but to do that you MUST set out precisely what the problems are, what potential solutions could (and couldn't) be, etc. etc. Not just vague "this feels wrong" objections.