I don't share some of the opinions I see in the comments here.<p>I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point.<p>But the n#1 thing for me in Go is: It's written in Go. It's refreshing to drill into the language details, I feel like I have learned so much from seeing the Go source code (and having it readily available with a Ctrl+click in VS Code).<p>Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me.
Given some of the comments, I'll make the same comment I've made before: Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp.<p>I'm a C++ dev, and I really enjoy using Go. If you don't like what it does or how it does it, it's not for you. Either way, people are out there using it, making systems from it, and generally getting on with it.
Go's success is attributable to the fact that it is the first compiled language in a long time which is backed by a major company and has managed to deliver a simple and enriched experience compared to the old company backed compiled languages.<p>1. Fast compilation is a killer feature.<p>2. Ease of deployment, as a self contained executable (static linked), is a joy.<p>3. Channels are a revolutionary concept to every programmer who had only touched mainstay languages.<p>4. Type inference is a revolutionary concept to every programmer who had only touched mainstay languages.<p>5. Go's syntax is less verbose than all other earlier mainstay languages. Such as how public/private is handled through casing, and not having to type public or private.<p>6. Go's structural typing is a revolutionary concept to every programmer who had only touched mainstay languages.<p>7. Everything that's new in Go to a programmer who had only touched mainstay languages before it is not there in Go as an extra set of features, but the only thing for them to use. This greatly focuses them on learning those new features. Also, non of the features are too radical to throw them off completely.<p>8. All the tools for Go, are built by the team behind Go.<p>9. Go's battery included, and has a great selection of modern standard libs.<p>When compared to Java, Go lacks very little, and brings a lot to the table. Generics are probably the biggest omission, but that's probably going to make it in the language eventually.
The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox)<p>By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk of mid-quality developers that make up the huge middle chunk of corporate devs, the space where Java reigns supreme.
IMO the Go goal is to be an enhancement of C. It is not as expressive as some existing languages (i.e., Go programs may be longer), but it is very good for translating clearly thought through logic into efficient machine code.<p>It supports some of the features that original C lacks (networking, parallelism, channels, etc.), which to me is a very good thing. With minimal forethought this allows writing programs that can be massively scaled later without impeding initial checkouts at small data sets.<p>Eventually the success or failure may be determined by the libraries developed by the user community. For example, fortran survived so long not because it was a good language, but because it had freely available, easy to use world class libraries for numerical computation. Many grad students kept using Fortran given the choice of an existing, working, ugly-ish code that they could use for their PhD projects vs redeveloping and retesting the same functionality from scratch.
I'm concurrently learning Go and Node, which might not be a fair comparison but I'm going to make the comparison anyway.<p>Node feels like a flesh wound with delicately layered bandaids. The ecosystem is a mess, you have to jerry rig basic packages to work together, the syntax and semantics of closures and context is ridiculous, and despite that callback mania is like this cool-aid that's supposed to feel great once you drink it (but hasn't yet for me).<p>Go just...works.
My impression is that Go is a language that was cobbled together to simplify the coding of some specific applications, such as simple servers. It lacks any kind of purity, is not the best choice for any specific task, but is just good enough for some (many?) tasks. And poor type safety!<p>Frankly, I can't help being disappointed by how bland this language is, and I have zero interest in using it. Maybe because I like coding, and the IMHO using Go or Java would totally kill the fun of it.
<a href="https://tip.golang.org/pkg/sort/#Slice" rel="nofollow">https://tip.golang.org/pkg/sort/#Slice</a><p>ouch compile time type safety... even Go maintainers have abandoned it. Go pundits can't expect developers not to do the same thing in their own codebase at that point.<p>Can't wait for aliases though.
I'm in a pretty weird place with Go.<p>On the one hand, I really cannot stop using it. I can build an small web applications in a day or two, I can write them in just slightly more lines than Rails, and the applications I can build are much speedier than Rails applications.<p>On the other hand, I really, really hate using Go. It's tremendously boring and I never feel the code is that elegant.<p>I've tried Haskell, but I end up messing around monads too much because there's so much IO.<p>Rails is fantastic, but I'd prefer to experiment. I never grow as a developer when I use Rails.<p>Node.js is great. But if I don't need to write a lot of JavaScript on the frontend I end up asking myself: why am I writing JavaScript on the backend?<p>Racket or Chicken Scheme look like good directions for me. Erlang looks interesting. Maybe I should give Clojure another shot?
I'm yearning for the Golang of functional programming. That is, excellent std lib, clear documentation, awesome tooling, active community.. and after typing this, maybe that's Elixir? Though I do love static typing.
Definitely the talk I enjoyed the most at FOSDEM today. Both instructive, relevant and pleasant to listen to. Glad to see things like sort.Slice or JSON rendering. When you're spoiled with python or groovy, you miss them them badly.
There's a worldwide Go 1.8 Release Party on Feb 16th. If you're interested in Go, or want to discuss changes in 1.8, find a meetup near you.<p><a href="https://github.com/golang/go/wiki/Go-1.8-Release-Party" rel="nofollow">https://github.com/golang/go/wiki/Go-1.8-Release-Party</a>
I was glad to find they made it much easier to define custom sorts for slices. But! Why on earth does what should really be syntactic sugar make sorting nontrivially slower?<p>It speaks to the lack of expressiveness in golang that you can't make sorting less egregiously verbose without adding a performance penalty.
I shall be moving my codebase to Go this year. I'm very impressed at how readable it is, how much thought has gone in to the tooling and support environment and how fast the GC is now. I also must be one of the few people who likes the assembler :)
Most of my work is C++ but I've also used Go a fair bit since Go 1.5. I like Go a lot. The C++ crowd (including myself) keeps trying to make things that are trivial in Go easier in C++ but the best efforts still look like a mess. I think the lightweight/green threads model of concurrency wins over others (threads, processes) and is incredibly difficult to get right in C++. Channels are also very useful and difficult to get right in C++. While C++ with some aid from Boost can be a very safe language it ends up being a lot harder to write and read with all sorts of [](){} -> hacked up conventions that are a result of backwards compatibility. I find the test infrastructure in Go to also be very pleasant and easy to use. Stuff you need to go to extremes of C++ to test are just trivial to do in Go.<p>Things I would like to see improved:<p>- Package management. I think "go get" was an interesting idea that is basically a fail for anything except the most trivial of situations. Vendoring is not a great solution either IMO. Perhaps some idea that manages package versions through local git repositories can work better since a git repository is a better representation of the version history of packages.<p>- I didn't like the compile speed loss we took when the compiler code base moved to Go. I'm not quite sure where it stand right now but one of the things that I liked about Go from the beginning is lightning quick builds.<p>- In my usage there seem to a few quirks in the language including the various scoping weirdness and the declare and assign operator := ... I frequently end up with code that re-uses the same variable such that the first instance is := and the next are = which makes refactoring a pain. The compound if statement also suffers from this.<p>The uppercase/lowercase public/private convention is also odd. You get used to it but it seems like a hacky afterthought.
I for one will be more interested in using Go when Jetbrains finishes their IDE. Clearly not everyone cares to develop in an IDE but after 33 years of doing it, I prefer the idea. Give Swift (my current work) as many years as Go has had (10 years), and maybe I won't find Go that interesting any more.
Conversion rules seem like an awfully specific language feature to introduce just to scratch a very particular itch.<p>The rest of the slides are pretty standard-fare, and that's a good thing. Would've liked a reference to the lack of monotonic time, though; either an acknowledgment that it's a problem (because it's now fairly widely known), or a mention that a new proposal to fix it [1] is in the works.<p>[1] <a href="https://news.ycombinator.com/item?id=13566110" rel="nofollow">https://news.ycombinator.com/item?id=13566110</a>
Go is better for applied tasks. Currently there is no faster way to write or simpler language than Go to write a highly scalable internet server that can handle 100-1000k concurrent clients on the commodity hardware. I suspect this applies to some big data analysis tasks in bioinformatics, that can be parallelized.
This slideshow doesn't work on narrow browsers: a narrow browser window clips the text, despite there being more than enough window space to display all the information on the slide.<p>Remember when the Web was automatically adaptive? Remember when we preferred HTML to PDF <i>because</i> it adapted?
Looks like the video is here, but YouTube is having trouble with it at the moment:<p><a href="https://www.youtube.com/watch?v=pwIOmKZBuVI" rel="nofollow">https://www.youtube.com/watch?v=pwIOmKZBuVI</a>
I've never used Go, but would you write your customer facing REST service using Go? Or would it only be used for back-end microservices? What's a recommended library for writing a customer facing REST API?
i love languages and i am enjoying seeing Go mature as a language. At the moment I do have my hands tied with Elm and Haskell.<p>Originally I am a Python programmer. Any advice for people transitioning for Python? What are some of the advantages of Go?
Question: who is going to remember all these conversion rules? By the second bullet you lost me.<p><i>Simply run the command below:</i><p><pre><code> go tool fix -diff -force=context state-of-go/tools/gofix.go
</code></pre>
How is typing 59 characters simple?
Golang really seems to have come a long way. But what holds me back from using it are the dangers of deadlocks and segfaults (due to forgotten error handling) that might be introduced even inadvertedly if applied to industrial-scale projects (say, 1M+ LOC, 10+ developers). That is, I see many small (server/microservice) projects flourish with Golang, and it seems an excellent replacement for certain types of C projects, but I wonder how Go enthusiasts believe it could scale to compete with Java or C++, due to the way it does error handling, and deadlocking issues with channels.