Go 1.7 is released | Hacker News Reader

Go 1.7 is released

blog.golang.org

545 pointstechietim133 comments

Open articleView on HN

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 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."

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

Following the twitter link and got this: "Something is technically wrong. Thanks for noticing—we're going to fix it up and have things back to normal soon."

The link works for me. :)

I've noticed this too on random pages. Seems Twitter is having issues today.

Wow. That's impressive. Thanks for the example numbers, Matt!

Thanks to the Go team, getting such an improvement without having to do anything is awesome. And I can't believe there is more coming in 1.8

That's a ridiculous speed improvement. Holy shit.

How large-ish is your codebase?

That's what I was wondering. Our largest Go application takes maybe 5 seconds to compile clean. We largely use Go as a number of Microservices though.

167912 LOC

On our code base, we're seeing >2x build speed increases vs. go 1.6! Compiling the entire go monorepo, including vendored dependencies, dropped from 73 seconds to 29 on 4 CPUs when moving from 1.6.3->1.7rc6. Huge improvements to CI times, when amortized across go build, go test, docker builds etc.

From Go 1.5.4 to 1.7, I can see that the compilation time has improved. Didn't measure it, though.

However, the binary size didn't change appreciably. From 11129144 bytes, it reduced by 0.00179708340551618345%.

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 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.

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.

Agreed. I recently transitioned from Rails development to devops, and there's no Ruby on any system by default. My Bash got better fast!

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.

This is a hurdle, but IMO it's not too annoying if you already have rights to install packages. Just automate interpreter installation in bash if it's not already there. Way too much time and money is invested in fighting the esoteric crannies of Bourne shell when the logic would be much clearer in Ruby or Python.

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.

You might have the right to install packages, but that may not solve your problem, that the application may require different version than available in the repo.

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 :(.

Yeah, if you can install packages, then you can run the RVM installation script and install the right version of Ruby. In fact, you don't even need admin privileges if you use RVM.

That will get you off package system for the entire stack and now the maintenance of the whole circus is up to you. Which is exactly what I'm trying to get away from.

I do dislike individual language package managers and ecosystems for this reason, but I think it's gotta be accepted at this point. Practically every language has their own package repo and versioning apparatus now. Ruby has RVM, Node.js has NVM, Python has PyPi/venv, etc. Most projects expect their users to deploy with these and include things like Gemfiles to define dependencies. That usually means if you insist on using the upstream packages provided by the distribution, you're going to have to install them manually and have a bunch of extra headaches to worry about anyway (to be honest, most custom applications are really difficult to get running using only distro-packaged Ruby or Python libs).

The individual language package managers are very nice for development, as you may have any package version you want, and also for non-linux users, where there may be no native package management at all. For operations, however, they suck mightly (that's terminus technicus).

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...

Then Python is a good alternative, it's basically already installed everywhere.

'Everywhere' being most Linux distributions, an outdated version (2.7) on OS X, no version at all on Windows.

Go and Python are not even close to being in the same league for performance in a majority of cases.

1: https://www.techempower.com/benchmarks/#section=data-r12&hw=...

2: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Maybe try Crystal (https://crystal-lang.org/) then. It has many of the benefits of Go and a Ruby-like syntax. It feels even more like a scripting language than Go because of awesome type inference, uses a similar model as Go for concurrency, and even has proper generics ;-)

> I suggest giving Ruby a try too.

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.

Why is it 'clearly' on its way out? IMO Rails is still the best web framework around, and the last release has really put it ahead of its closest competition.

Not really,

https://www.techempower.com/benchmarks/

I wasn't making a statement about performance. That has very little to do with most web development.

On my little part of the world, performance always plays a role in web development.

It is even described in many of the project contracts.

Until you have users. :-P

For one example, check this comparison: https://dockyard.com/blog/2016/08/09/phoenix-channels-vs-rai...

Ruby is too forgiving, has multiple syntaxes for the same thing, and lets people do really obscure shit in a large codebase (monkey patching, hidden imports, etc). In short: it enables developer laziness.

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.

I can't speak to this. I'm a Go and Python programmer. I learned Go in about ~8 hours and have been very productive with it over the past 2 years.

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.

Agreed on popularity but Kickstarter is slow and memory is still expensive. Shorter code isn't always a good idea when most Rail and Ruby developers can't tell between APIs.

Swift is by far being the best all-rounder language and between the fastest and slowest.

I'd second this. Rails is still probably the fastest way to get an MVP off the ground, and most of the time it's more than fast enough. You can get UX on par with a well done SPA almost entirely using server code with Turbolinks 5 + Action Cable, too.

The fastest way to get an MVP off the ground is to use the tools you know best. It doesn't have to be Rails :)

Yes, this is also usually true. But if you don't know tools that are particularly well suited for the job, or you just don't like them and are looking for something else to try, I would put Rails at the top of the list for productivity. (For most use cases)

The only problem is that you need to maintain and enhance that MVP for the next several years -- unless it's just a hackathon.

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.

I think this will interest you, https://github.com/thewhitetulip/web-dev-golang-anti-textboo...

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

Seems like a great release. Faster compilation and faster at runtime. Normally these 2 are considered opposite of each other.

And smaller binary size too. For a statically linked blob, that's a big plus.

BTW, what does one have to do to get fully statically linked executables? The binaries I've created with go get SOMETHING are linking against libc, but I remember that go doesn't rely on the system libc. Has that changed? For instance I just installed git-appraise, and it's a dynamically linked executable. What am I doing wrong?

CGO_ENABLED=0

Otherwise it will dynamically link glibc in case of CGO code.

Note: the race detector does not work without cgo enabled.

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.

By some OSes, you mean any Linux distro with Avahi installed, right? I'm assuming getaddrinfo checks NSS for where to look up hostnames.

I should also check how Windows with Bonjour behaves.

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/

from the same page:

"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."

It is probably the net package. The net package depends on cgo and libc for some DNS resolution. There is a pure Go implementation, but the cgo one is used if cgo is available. If you disable cgo as the other comments say, the pure Go implementation will be used instead. Alternatively, you can not include the net package.

Search for systemConf().canUseCgo()

https://github.com/golang/go/blob/master/src/net/lookup_unix...

Most likely it depends on the `net` package which can use `getaddrinfo` for dns lookups. Try using the `netgo` build tag:

    go install -tags=netgo github.com/google/git-appraise/git-appraise

I tried that and also

    env CGO_ENABLED=0 go get github.com/google/git-appraise/git-appraise

but I always get an error that go wants to write net.a in /usr/lib, which I naturally am not allowed to do because it's owned by the distro (Arch) go package:

    go install net: open /usr/lib/go/pkg/linux_amd64/net.a: permission denied

I have only set GOPATH to ~/.go and nothing else. Any other GO environment variable I should have used?

Go needs to re-build the stdlib packages with the new build tag as well.

You could install go locally somewhere in ~ and point GOROOT there.

After the transition from C to Go of the gc toolchain there was a lot of potential in both areas. The SSA backend increased even more that potential. And there is still room for improvement, so future versions will be even better. But yes, it's a great release. Congrats to the team!

Yay, s390x support is finally in mainline! Finally we (SUSE) no longer needs to use gcc-go to build Go binaries on some platforms (we've had nothing but issues from gcc-go, half of the patches we apply to Docker are to make it behave when built with SLE's gcc version).

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.

What about it seems wrong to you?

Maybe "Go 1.7 has been released" or "Go 1.7 is out"

Exactly, both would have been a fine. I am wondering if this is a grammar mistake, or general English usage difference in US and Commonwealth countries.

I am not a native English speaker myself. But yes that fragment while correct parsed a bit weirdly in my head because "is" is often used for properties of an entity like "John is dead" and "has been" is often used for something that is done to something. Like "John has been convicted". I think it has something to do with "is" being a simple present form while "released" in one sense talks about the state of the object in which case it is fine but also in another case is the action of getting released in which case it is in the simple past tense.

I'm happy as long as no one tries to say "Go 1.7 has dropped".

Same, it sounds off to me. I'm also not a grammar expert but know when something sounds 'off'.

"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.

""Nintendo Wii U has been released."

has been is Passive voice and should be avoided.

Sometimes good advice, but certainly not a rule. As Pinker points out in "A Sense of Style", passive voice lets you modify word order to emphasize what's important to the reader.

It's newspaper headline-style, i.e., written in present-tense.

Example from nytimes.com right now, "Bag Left Alone by Mother of Olympian Is Blown Up".

(Downvotes: Dunno why either. People are grumpy.)

Like another commenter mentioned, this style is commonly used in headlines. It's referred to as historical present tense. Here are a few resources for more information:

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)

It seems right to me (American speaker). "Released" functions as an adjective, with similar meaning to "available." "Go 1.7 is available" would be grammatically correct.

"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.

It's just present tense, usually known as "historical present" tense when used in a headline like this. "Released" here might be intended as an adjective or verb; it's ambiguous, but both are valid in the sentence structure.

Isn't it the passive voice? You conjugate to be and add the past participle. "Go 1.7 is released" rather than "we have released Go 1.7". The passive voice makes Go the subject of the sentence, otherwise it would focus on who is doing the releasing which is less important in this context.

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".

Release the Hounds.... The Hounds have been released. Go is released seems fine to me.

>Go 1.7 is released

The is is redundant which may be why it doesn't scan well for you.

GO 1.7 released

Works much better, no?

>A new compiler back end, based on static single-assignment form (SSA), has been under development for the past year

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.

> Huh, I was under the impression that either SSA or CPS was pretty standard for any serious compiler.

It was based on the Plan 9 compilers, which didn't use SSA.

It was more expedient to start with the Plan 9 tool chain that we had at the time. Ken was already familiar with the code base, which was small and compiled quickly (a few seconds). Because of this we got a lot done quickly, knowing that we would eventually modernize the compiler.

How much is Ken involved in the language today?

Ken is not really involved in the project these days. His last commit was in 2011, before Go 1 was even released.

(afaik) He retired around the Go 1.0 release, though he showed up as unixken on reddit during a Go Ask Me Anything.

https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...

SSA is standard for the middle end but not for the backend. According to my knowledge there are only two compilers with an SSA-based backend: libFirm (www.libfirm.org) and the Go compiler.

Obviously no backend is in SSA format after register allocation, but before allocation what do other compilers use if not SSA? Is there some kind of low-level LLVM and GCC IR separate from the front-end and middle one? That isn't in SSA?

I know that the C2 and Graal compilers are SSA all the way until register allocation is done.

You can stay in SSA form even after register allocation. In libFirm the assigned registers are just attributes of the values in the SSA representation. There was some additional discussion regarding this in [1].

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...

I think you didn't understand Chris' post.

C2 is the HotSpot Server compiler. It definitely does not use LLVM anywhere.

Since there is also a programming language called C2, I took a look at the wrong compiler.

Can you provide a link to the source code?

https://github.com/dmlloyd/openjdk/tree/jdk9/jdk9/hotspot/sr...

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 supported platforms?

>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?

No, not really. Just compile the program with 1.8, and don't worry about the bugs in the past.

Go is far better than most languages at supporting random system APIs. I mean, you can cross-compile code on Windows that uses Linux syscalls. Try doing that in Python. Actually I just Googled and I'm not sure Python even lets you use syscalls. I also couldn't even find any third party library to give you the system CA pool, let alone a first party one.

Tell me a language that has a first-party cross-platform library that allows you to get the system CA pool on all platforms.

My third-party Python library that gives access to the system CA trust store: https://github.com/wbond/oscrypto

Thanks for the reminder. I've filed:

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.

Be sure to check out the release notes, especially if you run FreeBSD (see known issues section).

https://golang.org/doc/go1.7

FWIW, this isn't a new regression on FreeBSD. We also saw these problems on Go 1.6 once we looked at our old build logs. It's just now documented.

vendor directories are no longer optional, which is nice.

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.

There are active discussions on the Go Package Management mailing list and the intention to propose further improvements to the go toolchain for future releases. We had good discussions with the Go Team during GopherCon last month.

https://groups.google.com/forum/#!forum/go-package-managemen...

Hopefully we'll have something official soon. For now, glide has been working well for us.

To be clear, vendor directories are still optional to use, you just don't have to enable them by default.

We use a unirepo for all of our Go work, and being forced to use the vendor directory would be a massive headache.

My understanding is that there is no longer an option to disable them as a feature as there was in 1.6, though of course you don't have to use them.

Yup, and you can always rename vendor/ to _vendor/ if you want to ignore them temporarily.

Cool. What's the plan for Go 8? What exciting features are up ahead?

SSA for all architectures, then delete the old compiler backend and optimize the frontend which can then assume an SSA backend and do less work. (Currently the frontend assumes a less-capable backend so has to do more work, which actually makes SSA slower)

You can read through this thread to see what people want to work on for Go 1.8.

https://groups.google.com/forum/#!topic/golang-dev/098vr4999...

I have some years of experience with python and picking up golang was extremely straightforward.

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 !

That's been my feeling for a long time now. After getting spoiled by Pythons enormous standard library, other languages feel incredibly bare-bones and getting things done takes a lot more work. I wish other languages focused more on including lots of library functions.

Size alone is only half (at best) of the equation. What makes Python's standard library stand out is the way it is structured and documented.

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.

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/<package> 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 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".

I just wish they would add tagging support.

> 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".

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.

If anything, the Go people have repeatedly claimed they don't know best -- because Google famously uses a huge monorepo with all deps vendored, and don't do "package management" as such -- and have preferred to let the community find a solution organically.

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).

> If anything, the Go people have repeatedly claimed they don't know best

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

I can't explain that since I'm not on the Go team. However, it's possible that they also didn't realize this hack was being relied on by people. The fact that you describe it as a hack implies it was never intentionally supported behaviour. Did you bring it up during the development of 1.5?

> The fact that you describe it as a hack implies it was never intentionally supported behaviour.

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.

Elevator description:

  - 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 popular

I wish the Clojure compiler was half as fast as Go's :(

I'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).

What makes you choose Go over Python for simple services and utility scripts? (I'm just learning Go but would heavily lean towards Python for those things)

Off the top of my head:

- 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).

Spinup of the JVM is 50 msec or so, for a hello world. Perhaps it's been a while since you tried running a small program on it? I can see why you might think the JVM starts slowly if you only ever run huge programs on it.

Great work,

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?

You can read through this thread to see what people want to work on for Go 1.8.

https://groups.google.com/forum/#!topic/golang-dev/098vr4999...

Awesome! Time to recompile RaspChat :D

Is Go based on llvm? It doesn't seem like it, but would be curious to know why not?

Isn't this the point of llvm, to separate the "language component" from the "cpu component"?

It's not based on LLVM. I don't know how recently the official FAQ was updated, but they say [1] that while they thought about using LLVM, they thought it was too large and slow for what they were looking for.

[1] https://golang.org/doc/faq#What_compiler_technology_is_used_...

There are llvm (and gcc) implementations of go but main/reference implementation was written from scratch in C and later moved to pure go. IIRC the authors wanted to achieve really fast compilation and a few other things that required them to start from scratch.

There was also the matter of figuring out llvm in order to use it. The initial Go compiler was based on the Plan 9 C compiler toolchain, which the designers of Go know well.

One of the other reasons relates to how stacks are handled for goroutines.

This comment from one of the Go maintainers (Russ Cox) is relevant: https://news.ycombinator.com/item?id=8817990

One benefit is that they were able to bootstrap the language and now enjoy having a pure Go toolchain.

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.

Pehaps this is the point of LLVM, but the point of Go was getting rid of C++.

Nice work

The semantics of Go is too ugly. It has no taste.

It's also a necessary "evil" to demonstrate that languages should have the right amount of features, no more and tools are part of a language, along with ease of deployment. It's is questionable whether Go strikes the right balance when it comes to features vs "simplicity" though, but it might inspire better solutions in the future. I think MSFT is trying to follow the same path with .net core and its tool chain, I hope they succeed as C# and F# are vastly superior to Go.

>I hope they succeed as C# and F# are vastly superior to Go.

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.

C# in VSCode is really good, and works on Linux. Have you tried it?

I wrote C# professionally for 7 years. IMO, it's in almost way inferior to Go:

* 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?

That's your taste.

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.

Reply on news.ycombinator.com