Go 1.7 is released(blog.golang.org) |
Go 1.7 is released(blog.golang.org) |
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 Go 1.7... the "vendor" behavior is always enabled"
Context package added to std lib:
>> "To make use of contexts within the standard library and to encourage more extensive use, the package has been moved from the x/net repository to the standard library as the context package."
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
However, the binary size didn't change appreciably. From 11129144 bytes, it reduced by 0.00179708340551618345%.
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 not worth it to invest time. I feel like using Java for my ideas is like using a semi truck for roadtrips. It can be done, but it's just not very efficient having to launch the JVM everytime I want to do something small.
Yes, I was open to new languages, but I did not really care about: C++, Python, Perl, Ruby and so on because I never cared about web dev. Now I was bored and finally decided to learn Go.
It's an introductory book for learning how to write webapps without a framework.
another book: https://github.com/astaxie/build-web-application-with-golang
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.
Swift is by far being the best all-rounder language and between the fastest and slowest.
Edit: Dont know why so many downvote, but it is a honest question.
Huh, I was under the impression that either SSA or CPS was pretty standard for any serious compiler. Does anyone know why they didn't design it for this from the beginning? It's like one of the earlier things you learn when making actual compilers.
It was based on the Plan 9 compilers, which didn't use SSA.
I know that the C2 and Graal compilers are SSA all the way until register allocation is done.
> 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?
https://github.com/golang/go/issues/16736
We actually try hard not to do platform-specific stuff, but in this case it seemed worth it, considering the problems people were having with cert validations and how Windows differs in how it validates TLS connections.
Tell me a language that has a first-party cross-platform library that allows you to get the system CA pool on all platforms.
No, not really. Just compile the program with 1.8, and don't worry about the bugs in the past.
Go get now update submodules... I'm honestly not sure what the current hack is for package management, but I assume people are still doing wrappers around go get to pin to commits/versions, (or else building your own repos for funsies), and I'm wondering if that breaks anything.
https://groups.google.com/forum/#!forum/go-package-managemen...
We use a unirepo for all of our Go work, and being forced to use the vendor directory would be a massive headache.
https://groups.google.com/forum/#!topic/golang-dev/098vr4999...
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 !
Consider Java's standard library, which is huge. That last few times I did anything in Java, I spent more time browsing the library documentation than coding. Admittedly, I did not know the library very well, if one uses Java all the time, that ratio probably changes. In Python I don't need to know the standard library well, because the way the documentation is written makes it very easy to find what I am looking for.
But the way that vendoring works in Go 1.5 and up is that you make vendor not a valid GOPATH and you have to now either create a fake GOPATH and move your current directory into it, or you have to do some symlink stuff within vendor/ that doesn't really work. Why was such a small cosmetic change seen as a good idea? It's needlessly incompatible with previous ways of making vendoring work seamlessly with Go.
I'm hoping that the packaging discussions that are going to be happening over the next few months don't result in a similar decision that "we know best".
- Open source, 6 years old, backing from Google
- Nice for concurrency and service implementations
- Not nice for generic types
- C like, modern, minimalist, garbage collected
- Becoming more popularI'm not much of a fan of using Go for anything 'big', but I have taken to using it in places where I would have previously used Python (tiny/simple services, housekeeping/utility scripts fired by cron, etc.)
I'd love to use Go at work (amongst many other things), but my employer already gives me a hard time for writing small utilities in Python rather than Java (I refuse to wait for a JVM to spin up just to convert a single file from csv to xml. I simply will not do it, and apparently my employer doesn't consider it worth firing me over).
- Ease of deployment. It's a standalone binary - I don't have to ensure python and all needed libraries are installed/configured.
- I like Go's standard library - it usually has everything I need to whip up a basic network service easily.
- Better/easier concurrency support.
- It's faster than Python (though that's usually not incredibly important most of the time).
I am looking forward to recompiling my code to see how things are. I have had my side project running on a set of Go micro services compiled against 1.4 since last year.
What can we expect from Go 1.8?
https://groups.google.com/forum/#!topic/golang-dev/098vr4999...
Isn't this the point of llvm, to separate the "language component" from the "cpu component"?
Whereas with LLVM, while they could benefit from all the work that has gone into it, they would get a dependency on C++ for life.
This way, the progress is slower and multiple releases will be required to achieve some optimizations, on the other hand it is the only way to prove to naysayers that for the systems programming use case of writing compilers, Go is also a viable option.
[1] https://golang.org/doc/faq#What_compiler_technology_is_used_...
One of the other reasons relates to how stacks are handled for goroutines.
In number of features, yes. Everything else and you come off as opinionated. I cannot comfortably write C# from my Linux workstation since all the tools are Windows-first.
C# is a language where everything must be done in classes and inherits a C++/Java school of OOP which I find abhorrent as it tends to favor monstrosities of abstraction upon abstraction. I can almost always read a Go codebase and get a good general sense of what it's doing in a few minutes, I can't say the same about C# codebases, and I have worked with C# for around the same time I've worked with Go.
These things aren't clear cut for everyone the same way.
* requires a separate and quite heavy run-time * still too windows-centric * Enforces a class-based OOP style * Functional programming elements feel very tacked-on * Feels heavier, slower, more bureaucratic * The async/await Task-based concurrency features are still not as flexible as Go's concurrency.
I find Go much more light-weight, easer to get into, enjoyable, and fun. So, how exactly is C# "vastly superior" to Go?
The semantics of Go are fine for the most part. My only problem with Go is manipulating slices. The rest is just awesome and it requires a lot of taste to simplify semantics without taking away the languages power.
"Go 1.7 has been released" would also be correct, but uses the present perfect tense.
So the question is, can "released" be used as an adjective? "The released version has a bug" seems correct to me, and "released" clearly functions as an adjective there.
All that said, the present perfect version seems clearly correct, while I can't make a great argument for the adjectival version.
Example from nytimes.com right now, "Bag Left Alone by Mother of Olympian Is Blown Up".
(Downvotes: Dunno why either. People are grumpy.)
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)
"Nintendo Wii U is released." - it just sounds strange.
"Nintendo Wii U has been released." - ok, sounds good.
"Nintendo Wii U released." - ok, sounds good.
has been is Passive voice and should be avoided.
In informal writing you should avoid using the passive voice, as it sounds disconnected and boring. Technical articles can sound better in the passive voice though, and I remember my physics teachers always used to berate people for not using it. So we should have written "the experiment is performed" rather than "I performed the experiment".
The is is redundant which may be why it doesn't scan well for you.
GO 1.7 released
Works much better, no?
Which is also why we ended up in this frustrating profusion of competing tools (Godeps, Glide and many others, plus the messy business that is git submodules) rather than a concerted effort towards a unified solution.
I don't at all believe the argument that they can't design something because they don't need it at Google. They're engineers, after all. You don't need to use a bridge in order to build one. There are plenty of existing tools (Bundler, Cargo, NPM, Cabal) that can also be used as case studies in how to do things right (Bundler, Cargo) or don't do them wrong (NPM).
In my company we use Glide, which is the best solution I've encountered so far, but it's beyond buggy, and struggles with some Google repos that need to be flattened in order to avoid duplicate, conflicting dependencies (glog and pflags, sigh).
So why is the defacto vendoring system for the Go tooling incompatible with old Go versions (the "organic" solutions were compatible with Go versions without vendoring support because they were implemented before vendoring support was a thing!)?
The vendor/src hack meant that you could compile with ANY version of Go -- that's important for distributions (and other people who want to build runC and Docker -- put plainly we pin Go versions because of compiler bugs). But no, now we have to use vendor/ which means that now we have to do even more messing around with the GOPATH (which makes rpmbuild even more ugly than it needs to be). sigh
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://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...
I've spent way too much of my life trying to optimize Ruby performance and memory usage, switching from one web server to the next, then fixing threading issues in dependencies, and so on. It's not fun. All that upfront productivity is lost in the end.
Quite happy to spend more time upfront investing in a reliable end-product.
It's used by the largest Go projects that exist. So if the Go developers didn't look at what the largest Go projects do and take inspiration from that, I'm really not sure what else to say.
A hack that is used by everyone is relied upon behaviour. I wouldn't even call it a hack, it's trying to make Go's obsession with your filesystem actually usable -- why on earth does my compiler toolchain care about how my home directory is structured?
The old method still works, you just have to call the directory something other than vendor/. Which just defeats the whole point.
> Did you bring it up during the development of 1.5?
My experience with Go 1.5 was a lot of other (more serious) bugs, so I didn't have a chance to comment on that particular issue. I'm surprised nobody from Docker said anything though.
I've been struggling at work to learn and use Rails for the better part of a year. I constantly have to grab someone and have them help me. Either I'm an idiot, or Rails has a bigger learning curve than people make it out to have because I've never experienced this in all my 10 years of programming professionally.
I've found Ruby code the hardest to debug over the years. Also, I think the web development community is waking up to the value of type safety.
I will use Ruby for the occasional script because I like its backtick syntax for invoking other commands, but that's it.
GCC uses a separate representation (RTL) for their backend that is not in SSA form [2]. LLVM stays in SSA form for some backend phases but lowers the SSA form before register allocation (as also mentioned in [1]).
I took a quick look at the C2 and the Graal compiler. C2 seems to use LLVM's code generator (and thus lowers SSA before register allocation) but Graal seems to support SSA-based register allocation, nice.
[1] https://news.ycombinator.com/item?id=11210948
[2] https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GNU_C...
C2 is the HotSpot Server compiler. It definitely does not use LLVM anywhere.
Can you provide a link to the source code?
It is even described in many of the project contracts.
For one example, check this comparison: https://dockyard.com/blog/2016/08/09/phoenix-channels-vs-rai...
Ansible's moment in the sun is fading now that Docker came onto the scene, but that was a glorious moment. It's still very useful for anyone with long-running, non-removable machines. Ansible requires Python and allows a great deal of behavior to be defined in simple YAML instructions.
The classical case is Ruby + Rails + Passenger + CentOS. While there is SCL with any Ruby and Rails version you might want, that does not mean, that the Passenger package will work with it :(.
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.
1: https://www.techempower.com/benchmarks/#section=data-r12&hw=...
2: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
If you use `CGO_ENABLED=0 go build`, it should make a statically linked executable.
"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."
I should also check how Windows with Bonjour behaves.
Search for systemConf().canUseCgo()
https://github.com/golang/go/blob/master/src/net/lookup_unix...
Otherwise it will dynamically link glibc in case of CGO code.
Note: the race detector does not work without cgo enabled.
go install -tags=netgo github.com/google/git-appraise/git-appraise env CGO_ENABLED=0 go get github.com/google/git-appraise/git-appraise
go install net: open /usr/lib/go/pkg/linux_amd64/net.a: permission denied
You could install go locally somewhere in ~ and point GOROOT there.
I quite like the SCL [1]. It solves the problem, that you might need different version of node/python/ruby/rails/php/whatever, than is packaged with the OS release of your choice. It has the software nicely packaged and maintained. Now getting third party packages to work with that, that's the problem. Passenger rpm [2] requires system-provided ruby, not just any ruby... I will survive that that App X wants Gem Y installed by rubygem. I won't like it, but it is workable and makes maintenance/updates slightly more difficutlt. But I will not put unpackaged module into Apache config.
[1] https://www.softwarecollections.org/
[2] https://www.phusionpassenger.com/library/install/apache/inst...