Sometimes it annoys me a little bit because it's standard lib is much smaller than python's however having it being compiled is more than worth it.
Thanks go team !
51–60 of 141 posts
Sometimes it annoys me a little bit because it's standard lib is much smaller than python's however having it being compiled is more than worth it.
Thanks go team !
Earlier quoted context omitted.
Go generally links to libc to use the system's getaddrinfo-- some OSes override it to do special things with dynamically discovered hosts on local networks, interfacing with LDAP/AD, etc. If you use `CGO_ENABLED=0 go build`, it should make a statically linked executable.
I don't believe that has been true for a few releases now. I believe go defaults to a pure Go resolver implementation now. You have to force enable the cgo resolver. https://golang.org/pkg/net/
"When cgo is available, the cgo-based resolver is used instead under a variety of conditions: on systems that do not let programs make direct DNS requests (OS X), when the LOCALDOMAIN environment variable is present (even if empty), when the RES_OPTIONS or HOSTALIASES environment variable is non-empty, when the ASR_CONFIG environment variable is non-empty (OpenBSD only), when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go resolver does not implement, and when the name being looked up ends in .local or is an mDNS name."
Great work, Go team! Standout points in my opinion: Overall performance improvements: >> "We observed a 5–35% speedup across our benchmarks." Decreased compile times and binary size: >> "While these changes across the compiler toolchain are mostly invisible, users have observed a significant speedup in compile time and a reduction in binary size by as much as 20–30%." Vendoring dependencies by default: >> "...and in…
The faster compilation time & speed up is quite real in our real life prod application. From Go 1.6 to 1.7: Test suite (CI), from 3:34 to 1:48 Docker image building, from 3:05 to 1:50 https://twitter.com/mattetti/status/763913903600349184
Ok, off topic question. Not an expert in grammar, but something about "Go 1.7 is released" seems wrong to me. Anyone could tell me if this is an correct usage of grammar? Edit: Dont know why so many downvote, but it is a honest question.
https://en.wikipedia.org/wiki/Historical_present http://www.grammar.net/presentaspast
"Is" combined with "released" does sound odd, but it's not too unusual, like in this sentence: "Heat is released into the atmosphere by cars." (From http://www.merriam-webster.com/dictionary/release)
> SystemCertPool returns an error on Windows. Maybe it's fixable later
This doesn't inspire confidence in Go as a cross platform language which is at version 1.7. If this is implemented in say 1.8, am I supposed to check for Go versions in order to know if the SystemCertPool func works or not? I mean why not just release it when it works on all tier-1 supported platforms?
The one thing that really pisses me off about the way Go handled vendoring is that they did it in a way that makes it incompatible with GOPATH. Previously in runC and Docker, we had build hacks that would symlink (or full copy) the current directory into vendor/src/ and then set the GOPATH to vendor/. This was compatible with every go version. In addition, many other projects did the exact same thing. But the way tha…
Judging by current packaging discussions, I don't see it happening any other way. I just hope they don't mess things up too much.
https://github.com/golang/go/commit/a62ae9f62fcfca02075b70e6... > SystemCertPool returns an error on Windows. Maybe it's fixable later This doesn't inspire confidence in Go as a cross platform language which is at version 1.7. If this is implemented in say 1.8, am I supposed to check for Go versions in order to know if the SystemCertPool func works or not? I mean why not just release it when it works on all tier-1 su…
No, not really. Just compile the program with 1.8, and don't worry about the bugs in the past.
Earlier quoted context omitted.
I suggest giving Ruby a try too. I find it great for both web dev and local automation scripts. You can do pretty much anything you can do in bash but with clearer and shorter code. I've been writing all my non-trivial automation code in Ruby for years. Rails is just a popular web framework for Ruby, there's a lot more the language can do.
It's annoying to have to install the ruby interpreter onto everything. Go feels a lot like a scripting language, but produces binaries.
Fortunately Elixir/Erlang releases include all the executables you'll need. They aren't quite as slick as Go binaries, which all live in one file, but it's still pretty cool.
Isn't this the point of llvm, to separate the "language component" from the "cpu component"?
I just learned Go 2 days ago and today I am already running my own web app! I love Go because it is kind of like C, but better (more modern).Generally, I always program my stuff in Java, but whenever I have an idea of creating something I could only choose between: C, Java, bash. Obviously I am not going to use C and bash for most of my ideas. Thinking about solving my issues in Java is meh so often I decided it is n…
I suggest giving Ruby a try too. I find it great for both web dev and local automation scripts. You can do pretty much anything you can do in bash but with clearer and shorter code. I've been writing all my non-trivial automation code in Ruby for years. Rails is just a popular web framework for Ruby, there's a lot more the language can do.
If you like Go, I don't see much reason to try Ruby except intellectual curiosity. Ruby is clearly a language on its way out and it is not just a lot slower than Go, it's also dynamically typed.