Go 1.3 is released
blog.golang.org
blog.golang.org
"Because concurrent Go programs use channels to pass not just values but also control between different goroutines, it is natural when reading Go code to want to navigate from a channel send to the corresponding receive so as to understand the sequence of events.
Godoc annotates every channel operation—make, send, range, receive, close—with a link to a panel displaying information about other operations that might alias the same channel."
Understanding large concurrent programs is significantly easier with a precise pointer analysis to help you track objects.
I still can't tell if it's evolved beyond a mark-and-sweep - I have to assume no - we've heard the GC would be seeing improvements and that the current (now older) method was stop-gap.
>> The garbage collector has been sped up, using a concurrent sweep algorithm, better parallelization, and larger pages. The cumulative effect can be a 50-70% reduction in collector pause time.
"The net/http package now provides an optional Server.ConnState callback to hook various phases of a server connection's lifecycle (see ConnState). This can be used to implement rate limiting or graceful shutdown."
Knows anyone here a code example for this?
When you have multiple libraries you have to be very specific about when you run godep, lest you find yourself with two libraries needing different versions of a common library, for example Main imports Foo and Bar, which both import Baz. Godep provides a mechanism for handling this: each dependency is explicitly locked into a fixed revision (e.g. commit sha, in the case of git). The pain comes about when during debugging as it can be very hard to reason which version of a library you're using.
Additionally the revision aspect is also a bit of a PITA, we use a development flow which rebases our small commits into a big commit and then merges that into our master branch; if you ran godep prior to that you're now referencing a commit that no longer exists. Given the chain of references that can exist this can go a very long way down. This same pattern also forces you into needing to push your dev branches to an origin server, as godep checks out the repos during the build, which while pretty benign a concern is a PITA if you forget and your build breaks because of it.
We're strongly considering moving to "one big repo" to help combat this issue (as well as a few others) for our internal golang repositories. Referencing "published commits" in 3rd party libraries is an acceptable level of pain. We're not entirely sold on this yet... just considering it.
It seems to be a solution for some (not all) projects that are released in binary form, but that isn't relevant to most projects out there[0]. I have never felt the need for what godep provides; vendoring myself has been sufficient for the (very rare) case in which I need specific versions of dependencies other than tip/trunk.
I asked around on #go-nuts, and (though the sample size was small), the other regular contributors who idle in the channel seemed to have the same experience.
YMMV obviously.
[0] https://botbot.me/freenode/go-nuts/2014-06-19/?msg=16563763&...
"Cross compiling with cgo enabled is now supported. ... Finally, the go command now supports packages that import Objective-C files (suffixed .m) through cgo."
Great news!!!!!!!!!!!!!!!!!!!!
This makes me really happy. I end up writing a lot of bindings to C libraries (libjpeg, libpng, etc), some of which use incomplete types to hide the contents of their internal structs. With this fix I'll finally be able to work within the constraints of the typesystem and stop hacking around it with casts to/from unsafe.Pointer.
warning: GOPATH set to GOROOT (T:\Tools\Go) has no effect
go build runtime: windows/386 must be bootstrapped using
make.bat
In the case of FORTRAN it is because the vector and matrices are recognized types, in other language, they are not built-in types but the convenience is added thanks to operator overloading.
I think there are certain mathematical operations that operate over what would be implemented as complex objects, so it is convenient to continue using these agreed upon symbols to implement your work.
// addition and multiplication of native integers
1 + 3 * 4
// add and mult of math objects
matrixA + matrixB * matrixC
// here the math is slightly occluded
add(matrixA, multiply(matrixB, matrixC)) E = 1/2 mv^2
E = 0.5 * (m * v)**2
E = (m.mult(v)).pow(2).times(0.5)
I think the first example is much closer to the maths.
This is not some contrived example, if you have raw data and you're using mathematical equations to work out relationships you do this kind of thing all the time.
1. String concatenation (Go has it) 2. Matrix/vector operations
That's it. Any other use case for operator overloading is dubious at best. It sucks for scientific programmers, but Go is a general purpose language, not a Scientific Programming language.
Complicating parsers, the grammar, readability, all those things, just to please your sub-group -> no thanks.
v := Vector{}
v2 := Vector{}
result := v.Add(v2)
result := v + v2
Note: I think it is good that Go does not have operator overloading, though I think it's a shame that means it's not as good for scientific & math programming.
Operator overloading has absolutely no effect on the parser or grammar.
It may harm readability but that's more a question of naming. An operator is just a name. If you use that name to refer to something unexpected, you'll harm readability. If you use it for something intuitive, you'll improve it.
I like Go a lot, but Google switching to it for Android would probably have the opposite effect. Many people learn Java in school. Almost no one learns Go.
non-static typing is a massive loss of safety.
It’s not without warts. You can bail with panic(), which is essentially a throw.
It’s tedious to handle errors, but that’s because actually handling errors is tedious.
I'm not joking when I say it really is that easy. Go makes it (and, really, many other things) very difficult for reasons that are at best murky.
This is effectively like doing this in Java:
try {
DoX()
DoY()
DoZ()
} catch( Exception ) {
// The code has no idea what failed here.
}
if err := DoX(); err != nil {
// handle error from DoX
}
if err := DoY(); err != nil {
// handle error from Doy
}
if err := DoZ(); err != nil {
// handle error from DoZ
}
If you only care about whether something succeeded use Option, if you care about the error use Either, Validation, etc.
Just pick the right Monad.
The first exception hit pops out the other side and you pattern-match against it. So, the one that did file access and returned a FileNotFoundException. If you have multiple pieces of code that can return FileNotFoundExceptions, you can pass a message in the exception, just like any other Java exception. You can often be more type-specific, too. Bear in mind that defining a new exception in Scala is a one-liner, and you can encapsulate your FileNotFoundException in a RetrievalFailedException very easily and cleanly.
Your method is not more robust, I assure you--it's just verbose and both typo- and thinko-prone.
An that is what makes go awesome. In java or php, you, as a developer, can never know wether the functions you are calling will throw an exception. The only way to know? Read the doc, if you're lucky and there's a doc, or read the code... The result? your program will crash if you didn't add your try..catch block.
Go forces you to either explicitly ignore errors (and your fellow co-worker will know you did it on purpose) or deal with them. No surprises.
That's what checked exceptions are for in Java.
(I'm not sure if that was your understanding or not)
"The panic and recover functions behave similarly to exceptions and try/catch in some other languages in that a panic causes the program stack to begin unwinding and recover can stop it. Deferred functions are still executed as the stack unwinds. If recover is called inside such a deferred function, the stack stops unwinding and recover returns the value (as an interface{}) that was passed to panic."
That's true...but no different from "exceptions can only be caught in catch blocks".
> which makes them significantly different from exceptions that I'm used to that can be caught in any part of the code.
It doesn't make them any different from exceptions -- just as a catch block can be anywhere up the call chain, a deferred function can have been set anywhere up the chain.
Defer is basically "finally", except the position is different, and "recover" inside it lets it also do what "catch" does.
[1] https://hackage.haskell.org/package/base-4.7.0.0/docs/Data-L...
Yeah, the native fundamental collections are generic.
- it isn't a priority
- it is a tricky thing to get right in the context of Go
- there haven't been any satisfactory proposals thus far
If this isn't quite right I'd love to be corrected.
In the meantime there have been several satisfactory proposals (in the lists and elsewhere), and it's not like 200 other languages implementing Generics have had many issues with them.
So, it boils down to the Go core team putting up the solution to an impossible tradeoff as the holdback (and a little exagerrated one at that, with relation to the costs involved).
And then, they said "the language won't change" etc recently.
It's the "nice to have" things that make programming easier/more correct/better.
Edit: I'm kind of hoping "But does it have generics?" will become the new "Will it blend?" for golang discussion.
One of the reasons I like HN.