25 ms·

The State of Go

466 points by dotmanish 10y ago

camperman 10y ago
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 :)
naaaaak 10y ago
Awful to try to read on mobile. Regular page anywhere?
- dgellow 10y ago
  I agree ... Even on an iPad, impossible to navigate correctly, slides stopped in between when you swipe
- MasterIdiot 10y ago
  Actually works pretty good for me with Firefox on Android.
- gigatexal 10y ago
  It's terrible for me on iOS with a 6s plus using safari.
- sambe 10y ago
  Completely unusable, perhaps the worst in recent memory of any front page article. Strange thing is that previous Go presentations have looked almost identical aesthetically but worked well.
- shurcooL 10y ago
  What do you mean by regular page? Try the source, it's pretty readable. https://github.com/golang/talks/blob/master/2017/state-of-go.slide https://github.com/golang/talks/blob/master/2017/state-of-go...
inblueredgreen 10y ago
https://tip.golang.org/pkg/sort/#Slice https://tip.golang.org/pkg/sort/#Slice 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. Can't wait for aliases though.
- bostik 10y ago
  The ability to provide inline comparison function for Sort() is welcome. It's one of those infrequently needed language niceties that have (at least for me) made perl and python so slick to use. Sorting arrays of objects or small hashes, based on arbitrary properties/keys, is quite useful.
  - yxhuvud 10y ago
    You are not really responding to the comment you are replying to, though. Yes, being able to do custom sorting is nice, but no-one challenged that claim. The type system really doesn't look very nice when it won't even manage type safety in such a simple case as this. Also, compared to other languages that is in sort of a similar spot[* ], such as Swift or Crystal that both manage type safe custom sort functions, it looks even worse. [*] That is, modern languages that compile down to native code while having some basic way of avoiding manual memory management.
gw 10y ago
I'm at FOSDEM where this talk was just given. Francesc was hilarious.
- campoy 10y ago
  well thanks
  - spraak 10y ago
    I love your Just For Func videos! I wondered if you could make one explaining pointers in Go. No explanation I've found really settles in for me, and while I'm getting a 'feel' for them writing more code and getting feedback from the compiler, I'd like to find a good explanation of them. I'm asking you specifically because you have a really great way of explaining things, and a warm presentation style. Either way, thanks for all you've given through your talks and videos!
grabcocque 10y ago
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) 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.
- rpercy 10y ago
  Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.
  - MichaelGG 10y ago
    Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or maps. Maps and folds are just simpler than loops, without even appealing to terseness and elegance. Hey I know I'm in no place to judge -- the creators of go and Google overall have accomplished more than I'll ever do. I just really cannot grasp the mindset and penchant for unexpressive languages. 1: http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277
    - sidlls 10y ago
      Maps and folds are implicit loops. For some explicit is simpler.
      - mattnewton 10y ago
ptero 10y ago
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. 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. 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.
- Taek 10y ago
  In my experience writing go is very fast and reading go is also very fast. The language was designed to be very comfortable, and they did a great job with that. You sit down to write something and you don't have to think too much about the best way to tackle the problem, the lines of code just flow from your fingertips. There's mostly one way to do everything, which makes doing things easy. Code review is much the same.
  - tejasmanohar 10y ago
    I feel the same. Go is a different type of terse. I think terseness goes beyond the number of lines. When I skim Go code, I can grasp the meaning of it very quickly.
    - sjellis 10y ago
      I've seen talks where Rob Pike describes Go as being "light on the page" vs. "noisy", meaning (I think) that it doesn't have lots of sigils and annotation bits around the code.
  - oscargrouch 10y ago
greg7mdp 10y ago
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! 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.
- aczerepinski 10y ago
  But if you like typing `if err != nil` it's actually the most fun language.
  - rpercy 10y ago
    Heh, it does feel repetitive. But after ~10 years with Java, I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception. Obviously, there's no perfect solution, and preference is subjective.
    - stefano 10y ago
      It's the same cognitive load, really. Instead of deciding how to best propagate exceptions, you're now deciding how to best propagate the error value.
      - rpercy 10y ago
        Not really. In a language like Java, some of the questions I'd have to ask myself are: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Should I throw a checked or unchecked exception? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) In golang, I know there's really just the one pattern: check if err != nil, prepend a descriptive message, and return it.
rusbus 10y ago
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? It speaks to the lack of expressiveness in golang that you can't make sorting less egregiously verbose without adding a performance penalty.
- zzzcpan 10y ago
  > what should really be syntactic sugar They probably use run time reflections, not a compile time syntactic sugar a.k.a. generics. As Go doesn't have those, so anything like that would require a compiler hack and nobody likes hacks.
  - DougBTX 10y ago
    Syntax sugar is extra syntax to make an existing feature easier to use, syntax sugar has no runtime impact. Generics are not syntax sugar, they add functionality such as stricter compile-time type checking and improved run-time performance (e.g., C# can use unboxed primatives in generics)
joaodlf 10y ago
I don't share some of the opinions I see in the comments here. 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. 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). Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me.
- jrs95 10y ago
  Especially when compared to working with something like Spring Boot every day it's fantastic. Getting rid of all the bloat is a bigger win than any of its unique features in my opinion.
  - Scarbutt 10y ago
    Comparing Go directly to Spring Boot? ;)
  - hepta 10y ago
    What are your problems with spring boot? What bloat are you referring to?
    - jrs95 10y ago
      I suppose most of my negative experiences with it are specifically in the context of using it to build microservices. The memory usage alone created a bit of a problem, I ended up using nearly all of my 16GB of RAM when I had to run many services simultaneously. And because the functionality of any given service was fairly minimal, there really wasn't a need for a framework like that. The autoconfiguratuon was also a bit dangerous. Since any dependency could cause any other dependency to reconfigure itself, it made it difficult to determine why things would break at times. At one point one of our libraries that used RabbitMQ behaved differently in some other services because another dependency saw RabbitMQ on the class path and started trying to use queues that didn't exist. Someone spent a day and a half figuring that out because the error was being swallowed by something else so the application was just failing to start with some crypic error. And when autoconfiguration wasn't enough, you'd sometimes find yourself needing to write dozens of lines of Java to do something as simple as connecting to a second database. In general I found we tended to have less predictable or obvious behavior in our Spring apps, and they tended to be more likely to fail at runtime than I would've liked.
coldcode 10y ago
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.
- rpercy 10y ago
  I've been using the Gogland beta for the last few weeks and it's been quite stable. For large codebases, it's hard to beat a good IDE's ability to quickly jump between symbols (go to definition, find usages, etc).
  - geoka9 10y ago
    Check out godef/guru - they let you do all those things (and more) in a text editor.
    - rpercy 10y ago
      Oh, very cool. Will definitely check out guru. Thanks for the tip.
- geoka9 10y ago
  To each their own, but Go is probably the only mainstream language that has first class integration with text editors. So I wouldn't let that stop me from using it, unless you can't see yourself using a text editor at all.
  - solidsnack9000 10y ago
    What is the first class integration? My experience using Ruby, Python and Rust (via Racer) with Vim+Syntastic has been pretty good.
    - geoka9 10y ago
      IDE functionality, similar to what godef/guru for Golang offer. But I'd settle on any mostly working jump-to-definition tool for Ruby/Python/Java that can be integrated with Vim/Emacs.
amelius 10y ago
How is Go as a compiler-target? I'm asking because I've heard that Go has a very good concurrent garbage collector.
DrBazza 10y ago
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. 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.
- mattnewton 10y ago
  Idk if that's such a clean binary, one of my favorite languages is Haskell, and people both complain about that and don't use it :)
  - dtzur 10y ago
    Imagine I gave you reddit gold
  - ice109 10y ago
    I'm starting a backend job tomorrow that's all Haskell. what are people's complaints?
    - shard972 10y ago
      The main one I see is that it is too hard for programmers who don't fully understand haskell/functional programming. I see people complain at times about it's performance but there is always someone there to rebut that it's fast at some things but not others.
      - ice109 10y ago
        yea compile times are killing my ability to iterate.
- tdestan 10y ago
  > Stroustrup is right, there are languages that people complain about, and languages that no-one uses. This quote has always struck me as an intellectually lazy cop out to avoid engaging with criticism. It's an indirect appeal to the fallacy of false equivalence: "If people actually used language $Foo, surely they would complain about it just as much, because all programming languages are basically the same." > Either way, people are out there using it, making systems from it, and generally getting on with it. See, this argument could be used to dismiss any criticism of just about anything.
bokertov 10y ago
I'm on my iPhone and the slides don't work well.
zalmoxes 10y ago
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. https://github.com/golang/go/wiki/Go-1.8-Release-Party https://github.com/golang/go/wiki/Go-1.8-Release-Party
bokertov 10y ago
I'm on my iPhone and the slides are terrible to navigate on a mobile browser.
- spraak 10y ago
  Yeah I came here to comment about that, too. It's surprising to me - I would have expected the Go team to have implemented/fixed that
j2kun 10y ago
I'm concurrently learning Go and Node, which might not be a fair comparison but I'm going to make the comparison anyway. 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). Go just...works.
- JepZ 10y ago
  Hehe, I have to underline this aspect as npm killed half an hour of my work yesterday, when I redownload some package in a sibling directory (for diff purposes). Never had this experience with go. The comparison is a little emotional for me, but when I realized npm just killed my code, I was emotional... Nevertheless, Javascript/Ecmascript is the result of years of development in a living environment (the web) while go was designed from scratch, by some of the most capable programming language designers on this planet, to enhance their previous work. Who wonders about the result?
niftich 10y ago
Conversion rules seem like an awfully specific language feature to introduce just to scratch a very particular itch. 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. [1] https://news.ycombinator.com/item?id=13566110 https://news.ycombinator.com/item?id=13566110
- cetxcz 10y ago
  The conversion feature is in fact very convenient. We often keep different types for what we get from the user (JSON) and what we write on the database (e.g: BSON). Having the ability to convert between them without having to re-type everything is useful for a lot of code out there.
  - calcifer 10y ago
    To be fair, you can do that right now with unsafe.Pointer, but of course it's better to have a compile time checked version of it.
throwaway91111 10y ago
Man I really wish they would stop using whatever crappy presentation software this is; it NEVER works well on mobile.
- shurcooL 10y ago
  It's `present`, a very simple tool. Written in Go, open source. Using it is a choice. I agree its ability to work on mobile is limited and that could use a CL (or a few) to improve. https://godoc.org/golang.org/x/tools/cmd/present https://godoc.org/golang.org/x/tools/cmd/present
  - Cyph0n 10y ago
    A beautiful example of NIH syndrome in the real world.
    - notfreeyet 10y ago
      It's an example of someone quite effectively solving their own problem in a couple hundred lines of code. That it's flawed in ways that are not part of its original use case is irrelevant. NIH is a problem when you spend a lot of time creating inferior solutions to solved problems. Not when you spend a tiny amount of time solving your own problems very effectively for years...
    - enneff 10y ago
      Can you suggest another presentation tool that makes it as easy to author and maintain slides? Nothing like this existed when Rob and I wrote present.
      - Cyph0n 10y ago
        I'm not sure what your exact requirements were, but I immediately thought of the following: * Beamer: write slides in LaTeX, maintainable for a long time to come and easy to build. * Reveal.js: use JS and HTML to author slides, easy to present, and pretty maintainable I think. * Pandoc[1]: use Markdown or RST to write your slides, then compile to HTML (e.g., Reveal.js) or LaTeX (Beamer). * Google Slides I'm not sure if any of these (except Beamer) were available back when you wrote the tool, but given some of the complaints in this thread (e.g., not mobile-friendly), wouldn't it make sense to migrate to some other tool going forward? [1]: Absolutely fantastic tool all-round, and written in Haskell to top it off. I used it a few years back to write a LaTeX report in Markdown. It's definitely not as good as writing LaTeX directly, but it's a great place to start. I can't praise Pandoc enough.
zirtec 10y ago
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.
- vorg 10y ago
  Always good to see features from the likes of Python and Apache Groovy make it into Go.
Bino 10y ago
Is there a youtube view available?
notforgot 10y ago
Question: who is going to remember all these conversion rules? By the second bullet you lost me. Simply run the command below: go tool fix -diff -force=context state-of-go/tools/gofix.go How is typing 59 characters simple?
- shurcooL 10y ago
  `staticcheck` will statically analyze your code and suggest all places where the new conversion rule can be applied. All the other rules are same as the last 7 years, you know them through experience after using Go for a week. Way simpler than most other languages. That go fix command can be typed once and update millions of lines of code. Pretty simple.
  - notforgot 10y ago
    These rules intimidate me (I don't know Go). You also meant to say the go fix command does a lot (which is great), not that calling it is simple (which is not great).
- _arvin 10y ago
  How lazy are you?
  - JepZ 10y ago
    I also hate any command that has more than, lets say 3 spaces, for its complexity, but hopefully this conversion stuff is more or less just a one time job so: who cares ;-)
- psankar 10y ago
  If you are precise, you will understand that the command is only 32 characters. You should not include the filepath in your length calculation. And 32 characters is not much longer than, say: python manage.py makemigrations
spraak 10y ago
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.
- yawaramin 10y ago
  You may be interested in https://facebook.github.io/reason/ https://facebook.github.io/reason/ They have an active community that is very engaged in improving the entire developer experience. Plus ReasonML is just OCaml under the (new syntax) hood so you have decades of OCaml expertise and libraries to draw on. In case that's not enough, it also deploys to JavaScript and targets the npm ecosystem, so you also have the entire npm package collection at your disposal.
  - spraak 10y ago
    Wow, thanks very much for sharing that!
- Kexoth 10y ago
  I was thinking about this a year ago & decided on Elixir. So far I have no regrets. As you mentioned Elixir satisfies all the conditions you mentioned. For the static typing part, I agree. But since there's no OOP, the flow of the information throughout the app is pretty explicit & the reasoning behind it is easy to be debugged.
  - im_down_w_otp 10y ago
    There is static type checking/analysis available. Just use Dialyzer.
    - Kexoth 10y ago
      You're right. I've used it once as a part of an exercise in the "Programming Elixir" book and never again. It should maybe come bundled with mix, as some other tools, that way it'll be more approachable. Also there's a wrapper for it, which helps in the process.[0] [0] - https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir
Hydraulix989 10y ago
Why are we getting rid of OSX 10.8 and some of ARM6? Are they _really_ that much extra work to support? I have a hard time believing so.
- enneff 10y ago
  Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip doesn't support needs to be done in software, and we don't have a reliable platform for testing against ARM6.
  - Hydraulix989 10y ago
    I guess I am a bit more upset about ARM6. How were you testing before? Have you considered using an emulator? Even Linux still supports ARM6.
    - enneff 10y ago
      I don't remember the details of our testing platform, it's been a while since I've been involved in ARM6 builders. I do remember that we used to test against emulators but they diverged significantly enough from the real hardware that we stopped using them.
    - 4ad 10y ago
      You can't test properly against emulators like QEMU. Emulators are written to be fast, not accurate (although in absolute terms they are pretty slow), e.g. they execute correct code quickly, but they don't fail to run incorrect code the same way real hardware would do. For example, when I wrote the arm64 Go port, I quickly discovered that the emulator would not cause a trap on unaligned memory access! Incorrect code executed just fine on the emulator. Even worse, I found several other bugs in a span of few days. In the end, I ended up writing my own arm64 emulator before hardware became available. I finished the port on real hardware. Of course, in principle an emulator could do perfect emulation, but in practice testing Go on an emulator would mean testing and maintaining an emulator as well. Apart from all that, running the Go test suite in a reasonable time requires a reasonable fast (e.g. server class) computer. Emulators just don't make the cut. And neither do small/old ARM systems. We could reduce the scope of the tests for embedded platforms, but then somebody would have to step in and work on and maintain those platforms. People always complain when the minimum hardware requirements for ARM are increased, but never offer to step in and help... Personally, I am interested in Go on embedded systems, but I don't have the time to maintain this as well.
tehwalrus 10y ago
Impossible to read on an iPhone SE. Landscape or portrait, slides cut in half and jumping around when you try to scroll.
riprock 10y ago
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?
Keyframe 10y ago
One thing I never understood with Go was what's the deal with multiple return values in functions? Why would you do this? What was the reasoning?
- twic 10y ago
  One of Go's other design decisions is signalling failures by returning errors. Multiple return values makes it possible to do that and also return a real value. If you didn't have multiple return values, you would have to do something ugly: C-style pseudo-return via a passed-in pointer, or returning an error or a value as an interface{} and requiring the caller to type-switch on it. Or add a special case to the language to somehow allow an error return alongside a normal return. Multiple return makes this straightforward and uniform.
  - Keyframe 10y ago
    Alright, that actually makes sense. Thanks.
- nvarsj 10y ago
  My guess is it comes from its C language roots, where every method returns an error code. With multiple return values, you can return an error code and the return value. This is a nice improvement over having to do my_func(in, &out).
fnl 10y ago
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.
- Strom 10y ago
  It's even easier to mishandle errors and get deadlocks in C++. That is in addition to all sorts of other fun like buffer overruns. If the team is capable of not messing these things up in C++, then they are more than capable of not messing up in Go.
  - fnl 10y ago
    Modern C++14 provides quite good support on those fronts, and modern Java8 has lost most of its "code notoriety". But that's just arguing back and forth. Here's the real argument: What popular OSS projects of noteworthy scale are being developed in Go? I know a few dozens in either Java or C++, and even a few fairly noticable Scala projects (Spark, Flink, Play, ...), but I yet have to see anything written in Go that can be called "industrial sized".
    - tasuki 10y ago
      Docker is written in golang: https://github.com/docker/docker https://github.com/docker/docker
    - benjaminjackman 10y ago
      I think IPFS is being made in go. Not sure if that qualifies as industrial sized or not.
    - sjellis 10y ago
      If you want examples of "industrial-sized" Go projects right now, you may have to look at case studies for proprietary cloud infrastructure, e.g. CloudFlare, Fastly, DigitalOcean, SoundCloud, and SendGrid. These companies obviously don't open up their product code, but they've been happy to share some information about their use of Go.
knodi 10y ago
I think Go is an amazing lang, its simple yet powerful. I have been using it in production for over 3 years.
- fnl 10y ago
  Mind to elaborate on what? Writing servers/services, and devops tasks, or something different?
cft 10y ago
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.
- fnl 10y ago
  As a bioinformatician, I can tell you: no. Hardly anywhere you have that concurrency need. You have a few clients only, typically, but with very highly parallel work-loads (as opposed to concurrent ones). Go is a bad for there.
YZF 10y ago
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. Things I would like to see improved: - 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. - 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. - 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. The uppercase/lowercase public/private convention is also odd. You get used to it but it seems like a hacky afterthought.
neonkiwi 10y ago
Looks like the video is here, but YouTube is having trouble with it at the moment: https://www.youtube.com/watch?v=pwIOmKZBuVI https://www.youtube.com/watch?v=pwIOmKZBuVI
didibus 10y ago
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. 1. Fast compilation is a killer feature. 2. Ease of deployment, as a self contained executable (static linked), is a joy. 3. Channels are a revolutionary concept to every programmer who had only touched mainstay languages. 4. Type inference is a revolutionary concept to every programmer who had only touched mainstay languages. 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. 6. Go's structural typing is a revolutionary concept to every programmer who had only touched mainstay languages. 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. 8. All the tools for Go, are built by the team behind Go. 9. Go's battery included, and has a great selection of modern standard libs. 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.
kmicklas 10y ago
And yet no generics still. What a joke.
- grzm 10y ago
  Is go something you'd like to use? Are you happy with the stack you're currently using? What is that stack? There are clearly people who are getting things done using go, and finding generics aren't something they require. Dumping on a language you don't like is boring and gratuitously negative.
JacksonGariety 10y ago
I'm in a pretty weird place with Go. 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. On the other hand, I really, really hate using Go. It's tremendously boring and I never feel the code is that elegant. I've tried Haskell, but I end up messing around monads too much because there's so much IO. Rails is fantastic, but I'd prefer to experiment. I never grow as a developer when I use Rails. 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? Racket or Chicken Scheme look like good directions for me. Erlang looks interesting. Maybe I should give Clojure another shot?
- JackMorgan 10y ago
  Your comment is similar to how I feel about Clojure. It's "good enough" for me for most things. Whenever I need something fast, that's what I grab for first. But, it feels "mushy" after +10k lines of logic, and I'm wishing it was F# or Haskell. I think I just need to bite the bullet and only use Haskell from now on. If it's slower at first, meh, it'll catch up when it grows.
wtbob 10y ago
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. Remember when the Web was automatically adaptive? Remember when we preferred HTML to PDF because it adapted?
mrcactu5 10y ago
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. Originally I am a Python programmer. Any advice for people transitioning for Python? What are some of the advantages of Go?
- deleted 10y ago
  [deleted]
- aryehof 10y ago
  My advice is be demand rather than supply driven. Be driven by what paradigm and language is suited to a problem, rather than just what can I apply my new silver-bullet language to.
widdma 10y ago
Video here: http://video.fosdem.org/2017/H.1302/ http://video.fosdem.org/2017/H.1302/ (go_state.*)
- kyrra 10y ago
  Already on the Go channel on Youtube: https://www.youtube.com/watch?v=tY4UKkgb5IY https://www.youtube.com/watch?v=tY4UKkgb5IY

466 points by dotmanish 10y ago

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

naaaaak 10y ago

Awful to try to read on mobile. Regular page anywhere?

dgellow 10y ago
I agree ... Even on an iPad, impossible to navigate correctly, slides stopped in between when you swipe
MasterIdiot 10y ago
Actually works pretty good for me with Firefox on Android.
gigatexal 10y ago
It's terrible for me on iOS with a 6s plus using safari.
sambe 10y ago
Completely unusable, perhaps the worst in recent memory of any front page article. Strange thing is that previous Go presentations have looked almost identical aesthetically but worked well.
shurcooL 10y ago
What do you mean by regular page? Try the source, it's pretty readable. https://github.com/golang/talks/blob/master/2017/state-of-go.slide https://github.com/golang/talks/blob/master/2017/state-of-go...

inblueredgreen 10y ago

https://tip.golang.org/pkg/sort/#Slice https://tip.golang.org/pkg/sort/#Slice 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. Can't wait for aliases though.

bostik 10y ago
The ability to provide inline comparison function for Sort() is welcome. It's one of those infrequently needed language niceties that have (at least for me) made perl and python so slick to use. Sorting arrays of objects or small hashes, based on arbitrary properties/keys, is quite useful.
- yxhuvud 10y ago
  You are not really responding to the comment you are replying to, though. Yes, being able to do custom sorting is nice, but no-one challenged that claim. The type system really doesn't look very nice when it won't even manage type safety in such a simple case as this. Also, compared to other languages that is in sort of a similar spot[* ], such as Swift or Crystal that both manage type safe custom sort functions, it looks even worse. [*] That is, modern languages that compile down to native code while having some basic way of avoiding manual memory management.

gw 10y ago

I'm at FOSDEM where this talk was just given. Francesc was hilarious.

campoy 10y ago
well thanks
- spraak 10y ago
  I love your Just For Func videos! I wondered if you could make one explaining pointers in Go. No explanation I've found really settles in for me, and while I'm getting a 'feel' for them writing more code and getting feedback from the compiler, I'd like to find a good explanation of them. I'm asking you specifically because you have a really great way of explaining things, and a warm presentation style. Either way, thanks for all you've given through your talks and videos!

grabcocque 10y ago

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

rpercy 10y ago
Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.
- MichaelGG 10y ago
  Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or maps. Maps and folds are just simpler than loops, without even appealing to terseness and elegance. Hey I know I'm in no place to judge -- the creators of go and Google overall have accomplished more than I'll ever do. I just really cannot grasp the mindset and penchant for unexpressive languages. 1: http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277
  - sidlls 10y ago
    Maps and folds are implicit loops. For some explicit is simpler.
    - mattnewton 10y ago

ptero 10y ago

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

Taek 10y ago
In my experience writing go is very fast and reading go is also very fast. The language was designed to be very comfortable, and they did a great job with that. You sit down to write something and you don't have to think too much about the best way to tackle the problem, the lines of code just flow from your fingertips. There's mostly one way to do everything, which makes doing things easy. Code review is much the same.
- tejasmanohar 10y ago
  I feel the same. Go is a different type of terse. I think terseness goes beyond the number of lines. When I skim Go code, I can grasp the meaning of it very quickly.
  - sjellis 10y ago
    I've seen talks where Rob Pike describes Go as being "light on the page" vs. "noisy", meaning (I think) that it doesn't have lots of sigils and annotation bits around the code.
- oscargrouch 10y ago

greg7mdp 10y ago

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

aczerepinski 10y ago
But if you like typing `if err != nil` it's actually the most fun language.
- rpercy 10y ago
  Heh, it does feel repetitive. But after ~10 years with Java, I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception. Obviously, there's no perfect solution, and preference is subjective.
  - stefano 10y ago
    It's the same cognitive load, really. Instead of deciding how to best propagate exceptions, you're now deciding how to best propagate the error value.
    - rpercy 10y ago
      Not really. In a language like Java, some of the questions I'd have to ask myself are: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Should I throw a checked or unchecked exception? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) In golang, I know there's really just the one pattern: check if err != nil, prepend a descriptive message, and return it.

rusbus 10y ago

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? It speaks to the lack of expressiveness in golang that you can't make sorting less egregiously verbose without adding a performance penalty.

zzzcpan 10y ago
> what should really be syntactic sugar They probably use run time reflections, not a compile time syntactic sugar a.k.a. generics. As Go doesn't have those, so anything like that would require a compiler hack and nobody likes hacks.
- DougBTX 10y ago
  Syntax sugar is extra syntax to make an existing feature easier to use, syntax sugar has no runtime impact. Generics are not syntax sugar, they add functionality such as stricter compile-time type checking and improved run-time performance (e.g., C# can use unboxed primatives in generics)

joaodlf 10y ago

I don't share some of the opinions I see in the comments here. 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. 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). Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me.

jrs95 10y ago
Especially when compared to working with something like Spring Boot every day it's fantastic. Getting rid of all the bloat is a bigger win than any of its unique features in my opinion.
- Scarbutt 10y ago
  Comparing Go directly to Spring Boot? ;)
- hepta 10y ago
  What are your problems with spring boot? What bloat are you referring to?
  - jrs95 10y ago
    I suppose most of my negative experiences with it are specifically in the context of using it to build microservices. The memory usage alone created a bit of a problem, I ended up using nearly all of my 16GB of RAM when I had to run many services simultaneously. And because the functionality of any given service was fairly minimal, there really wasn't a need for a framework like that. The autoconfiguratuon was also a bit dangerous. Since any dependency could cause any other dependency to reconfigure itself, it made it difficult to determine why things would break at times. At one point one of our libraries that used RabbitMQ behaved differently in some other services because another dependency saw RabbitMQ on the class path and started trying to use queues that didn't exist. Someone spent a day and a half figuring that out because the error was being swallowed by something else so the application was just failing to start with some crypic error. And when autoconfiguration wasn't enough, you'd sometimes find yourself needing to write dozens of lines of Java to do something as simple as connecting to a second database. In general I found we tended to have less predictable or obvious behavior in our Spring apps, and they tended to be more likely to fail at runtime than I would've liked.

coldcode 10y ago

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.

rpercy 10y ago
I've been using the Gogland beta for the last few weeks and it's been quite stable. For large codebases, it's hard to beat a good IDE's ability to quickly jump between symbols (go to definition, find usages, etc).
- geoka9 10y ago
  Check out godef/guru - they let you do all those things (and more) in a text editor.
  - rpercy 10y ago
    Oh, very cool. Will definitely check out guru. Thanks for the tip.
geoka9 10y ago
To each their own, but Go is probably the only mainstream language that has first class integration with text editors. So I wouldn't let that stop me from using it, unless you can't see yourself using a text editor at all.
- solidsnack9000 10y ago
  What is the first class integration? My experience using Ruby, Python and Rust (via Racer) with Vim+Syntastic has been pretty good.
  - geoka9 10y ago
    IDE functionality, similar to what godef/guru for Golang offer. But I'd settle on any mostly working jump-to-definition tool for Ruby/Python/Java that can be integrated with Vim/Emacs.

amelius 10y ago

How is Go as a compiler-target? I'm asking because I've heard that Go has a very good concurrent garbage collector.

DrBazza 10y ago

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

mattnewton 10y ago
Idk if that's such a clean binary, one of my favorite languages is Haskell, and people both complain about that and don't use it :)
- dtzur 10y ago
  Imagine I gave you reddit gold
- ice109 10y ago
  I'm starting a backend job tomorrow that's all Haskell. what are people's complaints?
  - shard972 10y ago
    The main one I see is that it is too hard for programmers who don't fully understand haskell/functional programming. I see people complain at times about it's performance but there is always someone there to rebut that it's fast at some things but not others.
    - ice109 10y ago
      yea compile times are killing my ability to iterate.
tdestan 10y ago
> Stroustrup is right, there are languages that people complain about, and languages that no-one uses. This quote has always struck me as an intellectually lazy cop out to avoid engaging with criticism. It's an indirect appeal to the fallacy of false equivalence: "If people actually used language $Foo, surely they would complain about it just as much, because all programming languages are basically the same." > Either way, people are out there using it, making systems from it, and generally getting on with it. See, this argument could be used to dismiss any criticism of just about anything.

bokertov 10y ago

I'm on my iPhone and the slides don't work well.

zalmoxes 10y ago

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. https://github.com/golang/go/wiki/Go-1.8-Release-Party https://github.com/golang/go/wiki/Go-1.8-Release-Party

bokertov 10y ago

I'm on my iPhone and the slides are terrible to navigate on a mobile browser.

spraak 10y ago
Yeah I came here to comment about that, too. It's surprising to me - I would have expected the Go team to have implemented/fixed that

j2kun 10y ago

I'm concurrently learning Go and Node, which might not be a fair comparison but I'm going to make the comparison anyway. 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). Go just...works.

JepZ 10y ago
Hehe, I have to underline this aspect as npm killed half an hour of my work yesterday, when I redownload some package in a sibling directory (for diff purposes). Never had this experience with go. The comparison is a little emotional for me, but when I realized npm just killed my code, I was emotional... Nevertheless, Javascript/Ecmascript is the result of years of development in a living environment (the web) while go was designed from scratch, by some of the most capable programming language designers on this planet, to enhance their previous work. Who wonders about the result?

niftich 10y ago

Conversion rules seem like an awfully specific language feature to introduce just to scratch a very particular itch. 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. [1] https://news.ycombinator.com/item?id=13566110 https://news.ycombinator.com/item?id=13566110

cetxcz 10y ago
The conversion feature is in fact very convenient. We often keep different types for what we get from the user (JSON) and what we write on the database (e.g: BSON). Having the ability to convert between them without having to re-type everything is useful for a lot of code out there.
- calcifer 10y ago
  To be fair, you can do that right now with unsafe.Pointer, but of course it's better to have a compile time checked version of it.

throwaway91111 10y ago

Man I really wish they would stop using whatever crappy presentation software this is; it NEVER works well on mobile.

shurcooL 10y ago
It's `present`, a very simple tool. Written in Go, open source. Using it is a choice. I agree its ability to work on mobile is limited and that could use a CL (or a few) to improve. https://godoc.org/golang.org/x/tools/cmd/present https://godoc.org/golang.org/x/tools/cmd/present
- Cyph0n 10y ago
  A beautiful example of NIH syndrome in the real world.
  - notfreeyet 10y ago
    It's an example of someone quite effectively solving their own problem in a couple hundred lines of code. That it's flawed in ways that are not part of its original use case is irrelevant. NIH is a problem when you spend a lot of time creating inferior solutions to solved problems. Not when you spend a tiny amount of time solving your own problems very effectively for years...
  - enneff 10y ago
    Can you suggest another presentation tool that makes it as easy to author and maintain slides? Nothing like this existed when Rob and I wrote present.
    - Cyph0n 10y ago
      I'm not sure what your exact requirements were, but I immediately thought of the following: * Beamer: write slides in LaTeX, maintainable for a long time to come and easy to build. * Reveal.js: use JS and HTML to author slides, easy to present, and pretty maintainable I think. * Pandoc[1]: use Markdown or RST to write your slides, then compile to HTML (e.g., Reveal.js) or LaTeX (Beamer). * Google Slides I'm not sure if any of these (except Beamer) were available back when you wrote the tool, but given some of the complaints in this thread (e.g., not mobile-friendly), wouldn't it make sense to migrate to some other tool going forward? [1]: Absolutely fantastic tool all-round, and written in Haskell to top it off. I used it a few years back to write a LaTeX report in Markdown. It's definitely not as good as writing LaTeX directly, but it's a great place to start. I can't praise Pandoc enough.

zirtec 10y ago

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.

vorg 10y ago
Always good to see features from the likes of Python and Apache Groovy make it into Go.

Bino 10y ago

Is there a youtube view available?

notforgot 10y ago

Question: who is going to remember all these conversion rules? By the second bullet you lost me. Simply run the command below: go tool fix -diff -force=context state-of-go/tools/gofix.go How is typing 59 characters simple?

shurcooL 10y ago
`staticcheck` will statically analyze your code and suggest all places where the new conversion rule can be applied. All the other rules are same as the last 7 years, you know them through experience after using Go for a week. Way simpler than most other languages. That go fix command can be typed once and update millions of lines of code. Pretty simple.
- notforgot 10y ago
  These rules intimidate me (I don't know Go). You also meant to say the go fix command does a lot (which is great), not that calling it is simple (which is not great).
_arvin 10y ago
How lazy are you?
- JepZ 10y ago
  I also hate any command that has more than, lets say 3 spaces, for its complexity, but hopefully this conversion stuff is more or less just a one time job so: who cares ;-)
psankar 10y ago
If you are precise, you will understand that the command is only 32 characters. You should not include the filepath in your length calculation. And 32 characters is not much longer than, say: python manage.py makemigrations

spraak 10y ago

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.

yawaramin 10y ago
You may be interested in https://facebook.github.io/reason/ https://facebook.github.io/reason/ They have an active community that is very engaged in improving the entire developer experience. Plus ReasonML is just OCaml under the (new syntax) hood so you have decades of OCaml expertise and libraries to draw on. In case that's not enough, it also deploys to JavaScript and targets the npm ecosystem, so you also have the entire npm package collection at your disposal.
- spraak 10y ago
  Wow, thanks very much for sharing that!
Kexoth 10y ago
I was thinking about this a year ago & decided on Elixir. So far I have no regrets. As you mentioned Elixir satisfies all the conditions you mentioned. For the static typing part, I agree. But since there's no OOP, the flow of the information throughout the app is pretty explicit & the reasoning behind it is easy to be debugged.
- im_down_w_otp 10y ago
  There is static type checking/analysis available. Just use Dialyzer.
  - Kexoth 10y ago
    You're right. I've used it once as a part of an exercise in the "Programming Elixir" book and never again. It should maybe come bundled with mix, as some other tools, that way it'll be more approachable. Also there's a wrapper for it, which helps in the process.[0] [0] - https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir

Hydraulix989 10y ago

Why are we getting rid of OSX 10.8 and some of ARM6? Are they _really_ that much extra work to support? I have a hard time believing so.

enneff 10y ago
Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip doesn't support needs to be done in software, and we don't have a reliable platform for testing against ARM6.
- Hydraulix989 10y ago
  I guess I am a bit more upset about ARM6. How were you testing before? Have you considered using an emulator? Even Linux still supports ARM6.
  - enneff 10y ago
    I don't remember the details of our testing platform, it's been a while since I've been involved in ARM6 builders. I do remember that we used to test against emulators but they diverged significantly enough from the real hardware that we stopped using them.
  - 4ad 10y ago
    You can't test properly against emulators like QEMU. Emulators are written to be fast, not accurate (although in absolute terms they are pretty slow), e.g. they execute correct code quickly, but they don't fail to run incorrect code the same way real hardware would do. For example, when I wrote the arm64 Go port, I quickly discovered that the emulator would not cause a trap on unaligned memory access! Incorrect code executed just fine on the emulator. Even worse, I found several other bugs in a span of few days. In the end, I ended up writing my own arm64 emulator before hardware became available. I finished the port on real hardware. Of course, in principle an emulator could do perfect emulation, but in practice testing Go on an emulator would mean testing and maintaining an emulator as well. Apart from all that, running the Go test suite in a reasonable time requires a reasonable fast (e.g. server class) computer. Emulators just don't make the cut. And neither do small/old ARM systems. We could reduce the scope of the tests for embedded platforms, but then somebody would have to step in and work on and maintain those platforms. People always complain when the minimum hardware requirements for ARM are increased, but never offer to step in and help... Personally, I am interested in Go on embedded systems, but I don't have the time to maintain this as well.

tehwalrus 10y ago

Impossible to read on an iPhone SE. Landscape or portrait, slides cut in half and jumping around when you try to scroll.

riprock 10y ago

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?

Keyframe 10y ago

One thing I never understood with Go was what's the deal with multiple return values in functions? Why would you do this? What was the reasoning?

twic 10y ago
One of Go's other design decisions is signalling failures by returning errors. Multiple return values makes it possible to do that and also return a real value. If you didn't have multiple return values, you would have to do something ugly: C-style pseudo-return via a passed-in pointer, or returning an error or a value as an interface{} and requiring the caller to type-switch on it. Or add a special case to the language to somehow allow an error return alongside a normal return. Multiple return makes this straightforward and uniform.
- Keyframe 10y ago
  Alright, that actually makes sense. Thanks.
nvarsj 10y ago
My guess is it comes from its C language roots, where every method returns an error code. With multiple return values, you can return an error code and the return value. This is a nice improvement over having to do my_func(in, &out).

fnl 10y ago

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.

Strom 10y ago
It's even easier to mishandle errors and get deadlocks in C++. That is in addition to all sorts of other fun like buffer overruns. If the team is capable of not messing these things up in C++, then they are more than capable of not messing up in Go.
- fnl 10y ago
  Modern C++14 provides quite good support on those fronts, and modern Java8 has lost most of its "code notoriety". But that's just arguing back and forth. Here's the real argument: What popular OSS projects of noteworthy scale are being developed in Go? I know a few dozens in either Java or C++, and even a few fairly noticable Scala projects (Spark, Flink, Play, ...), but I yet have to see anything written in Go that can be called "industrial sized".
  - tasuki 10y ago
    Docker is written in golang: https://github.com/docker/docker https://github.com/docker/docker
  - benjaminjackman 10y ago
    I think IPFS is being made in go. Not sure if that qualifies as industrial sized or not.
  - sjellis 10y ago
    If you want examples of "industrial-sized" Go projects right now, you may have to look at case studies for proprietary cloud infrastructure, e.g. CloudFlare, Fastly, DigitalOcean, SoundCloud, and SendGrid. These companies obviously don't open up their product code, but they've been happy to share some information about their use of Go.

knodi 10y ago

I think Go is an amazing lang, its simple yet powerful. I have been using it in production for over 3 years.

fnl 10y ago
Mind to elaborate on what? Writing servers/services, and devops tasks, or something different?

cft 10y ago

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.

fnl 10y ago
As a bioinformatician, I can tell you: no. Hardly anywhere you have that concurrency need. You have a few clients only, typically, but with very highly parallel work-loads (as opposed to concurrent ones). Go is a bad for there.

YZF 10y ago

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. Things I would like to see improved: - 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. - 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. - 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. The uppercase/lowercase public/private convention is also odd. You get used to it but it seems like a hacky afterthought.

neonkiwi 10y ago

Looks like the video is here, but YouTube is having trouble with it at the moment: https://www.youtube.com/watch?v=pwIOmKZBuVI https://www.youtube.com/watch?v=pwIOmKZBuVI

didibus 10y ago

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. 1. Fast compilation is a killer feature. 2. Ease of deployment, as a self contained executable (static linked), is a joy. 3. Channels are a revolutionary concept to every programmer who had only touched mainstay languages. 4. Type inference is a revolutionary concept to every programmer who had only touched mainstay languages. 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. 6. Go's structural typing is a revolutionary concept to every programmer who had only touched mainstay languages. 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. 8. All the tools for Go, are built by the team behind Go. 9. Go's battery included, and has a great selection of modern standard libs. 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.

kmicklas 10y ago

And yet no generics still. What a joke.

grzm 10y ago
Is go something you'd like to use? Are you happy with the stack you're currently using? What is that stack? There are clearly people who are getting things done using go, and finding generics aren't something they require. Dumping on a language you don't like is boring and gratuitously negative.

JacksonGariety 10y ago

I'm in a pretty weird place with Go. 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. On the other hand, I really, really hate using Go. It's tremendously boring and I never feel the code is that elegant. I've tried Haskell, but I end up messing around monads too much because there's so much IO. Rails is fantastic, but I'd prefer to experiment. I never grow as a developer when I use Rails. 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? Racket or Chicken Scheme look like good directions for me. Erlang looks interesting. Maybe I should give Clojure another shot?

JackMorgan 10y ago
Your comment is similar to how I feel about Clojure. It's "good enough" for me for most things. Whenever I need something fast, that's what I grab for first. But, it feels "mushy" after +10k lines of logic, and I'm wishing it was F# or Haskell. I think I just need to bite the bullet and only use Haskell from now on. If it's slower at first, meh, it'll catch up when it grows.

wtbob 10y ago

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. Remember when the Web was automatically adaptive? Remember when we preferred HTML to PDF because it adapted?

mrcactu5 10y ago

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. Originally I am a Python programmer. Any advice for people transitioning for Python? What are some of the advantages of Go?

deleted 10y ago
[deleted]
aryehof 10y ago
My advice is be demand rather than supply driven. Be driven by what paradigm and language is suited to a problem, rather than just what can I apply my new silver-bullet language to.

widdma 10y ago

Video here: http://video.fosdem.org/2017/H.1302/ http://video.fosdem.org/2017/H.1302/ (go_state.*)

kyrra 10y ago
Already on the Go channel on Youtube: https://www.youtube.com/watch?v=tY4UKkgb5IY https://www.youtube.com/watch?v=tY4UKkgb5IY