24 ms·

Program your next server in Go

• avitzurel 10y ago
  I love Go. It has become the default Go-To (pun intended) language for me for almost anything that needs to be small and portable. However, I don't see myself writing a full server with it, I would still prefer a dynamic language like Ruby/Python for that and use Go for micro-services CLIs and the rest. For example: Our main application is Rails, it communicates with SOLR as the search index, in between the application and SOLR there's a proxy server that backups the documents onto S3 and also does Round-Robin between slaves. One other thing is that we use Go to communicate with all external APIs of 3rd parties, the application code is rails and it communicates transparently with a Go server that fetches the data from 3rd parties and responds to the main application.
  • asimuvPR 10y ago
    Likewise. I use for set and forget services. Once a Go application has been properly tested it runs quietly like a mainframe in the corner of a datacenter.
    • iagooar 10y ago
      Same experience here. Writing tiny, focused, small footprint services with Go has been a blast. It really has its niche. Especially since learning to write (and read) Go is a matter of hours, more than days (or even weeks).
      • aksx 10y ago
        I have been running multiple programs on my DO vps, my uptime is 305 days. 1 program was updated in Feb to accommodate an API change another was updated in Dec 2014. It's amazing how good they perform with minimal memory usage.
  • avitzurel 10y ago
    Also to add on this... All of my lambda functions are a thin Node wrapper on top of Go applications. The go application is simply a command line accepting JSON via stdin (from the Node wrapper). It is a Joy to test, you can run it locally/independently etc... [Edit]: Typos fix
    • ketralnis 10y ago
      Do you use a library or toolkit for this? Or is there an example of this that you can point me to? This sounds useful with or without Go
      • avitzurel 10y ago
        Let me open source something real quick. Wouldn't call it a toolkit but might be useful for some people.
      • avitzurel 10y ago
        Quickly open sourced as promised: https://github.com/KensoDev/sns-lambda-notifier-golang https://github.com/KensoDev/sns-lambda-notifier-golang It's simple enough to understand with absolutely no documentation. But here's the gist. You develop in Go, you can run tests or run it independent from the lambda and then, when you want to deploy you run `release.sh`. This is perfect for web callbacks, SNS notifications etc...
      • dcu 10y ago
        https://apex.sh https://apex.sh is nice
  • kingnothing 10y ago
    Given the low API limits on most services, what was the reason you went with Go for those integrations as opposed to ruby / rails?
    • avitzurel 10y ago
      I wrote a bit more in length about it here: http://www.avitzurel.com/blog/2015/06/13/scaling-gogobot-using-3rd-party-apis/ http://www.avitzurel.com/blog/2015/06/13/scaling-gogobot-usi... In this blog post the previous solution is presented using Nginx, now it's Golang similar to Templar (mentioned in the post).
  • spriggan3 10y ago
    Go type rigidity makes Go code tedious to write. Instead of thinking "How can we solve that problem" developers writing Go end up thinking "How can we make the problem fit Go type system". I'm not even talking about concurrency here, I'm talking about Types. Saying otherwise would be dishonest, unless one has never used anything but C... Anybody who doesn't believe me just has to look the reflect package. Reflection packages are usually a good indication of language capabilities when it comes to statically typed ones. It doesn't make Go a bad language,it has a some good percs, it's just frustrating that its authors conflated simplicity with rigidity. Also I hate when languages have hidden APIs, i.e. things the language can do that the programmer can't. Go is full of these (for instance append which is a parametric function since it knows the proper return type no matter what type of slice you pass it, but you can't write your own? ). It's good think that it requires very little investment to get started, but it becomes highly frustrating when one stumbles on its limitations.
    • eternalban 10y ago
      All languages require investment. Zero sum game, with some opting for syntactic simplicity that entails a long term investment of "idioms", subtle semantics, post-processing, etc., and others present a high initial investment and subsequent clarity, regularity, and possibly robustness. C/Go/Java/C# are in the former category. Scala, Haskell, Rust, for the latter. (C++ uniquely bites you at both ends :)
      • beders 10y ago
        It is not a Zero sum game. The moment you actually need to maintain a large codebase for years, strongly typed languages are much more cost-efficient. Finding out, with absolute certainty, which code calls which code under which circumstances is a life-saver. Any modern IDE for JVM languages accomplishes that. It's not enough for your code to be readable. It needs to be statically traceable.
        • AlisdairO 10y ago
          > absolute certainty I completely agree with your overall point, but typically reflection will inhibit truly 'absolute' certainty.
• satysin 10y ago
  The only place I would want to use Go is for a server tbh. It isn't all that great for anything else imho.
  • avitzurel 10y ago
    It is amazing for dev tools and CLIs. Perfect example for this is Hashicorps products, taking out Vagrant it is 100% written in Go. Having a single executable tool that you can download and run anywhere is super powerful. You develop once and you build it for every system. It's the definition of delight to me.
    • kasey_junk 10y ago
      I'd argue that CLI tools are really a better example of what Golang is good at. Most of the things purported to be major wins for Golang on the server side are available or better in other environments. For CLI programs that need to be a little more sophisticated than bash Golang is quite nice.
      • avitzurel 10y ago
        Agreed. Check out my comments on this threads...
• tokenizerrr 10y ago
  What about debugging? This is the major pain point for me. I've tried using GDB, but... > GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones. Moreover, it is not a priority for the Go project to address these issues, which are difficult. In short, the instructions below should be taken only as a guide to how to use GDB when it works, not as a guarantee of success. https://golang.org/doc/gdb https://golang.org/doc/gdb
  • woah 10y ago
    Visual Studio Code has a visual debugger that is close to being on-par with Chrome's JavaScript debugger, at least for me.
    • bboreham 10y ago
      And it works with Go, resolving some or all of the issues mentioned?
      • tokenizerrr 10y ago
        I just looked it up, and it integrates with Delve. So it looks promising.
      • inglor 10y ago
        I tried to get it to work the other day (with delve) for a few minutes and I could not. So even if it does it does not do so cleanly.
  • muraiki 10y ago
    Have you tried out Delve? https://github.com/derekparker/delve https://github.com/derekparker/delve I've only used it for simple cases, so I don't know if it helps with your criticisms, but it was designed for Go. I mention this because it seems like many gophers aren't aware of Delve.
• phpDie 10y ago
  You lost me at not being able to navigate your slides with my mouse. That a Go feature?
  • freyr 10y ago
    Just click the right or left edge of the slide. Bad UI, but it works.
    • phpDie 10y ago
      Not worth.
  • Jabbles 10y ago
    The instructions are literally at the bottom of the first slide.
    • phpDie 10y ago
      Oh didn't realize i had to read things to learn how to navigate things. Cool UX bro.
      • dang 10y ago
        We've banned this account for repeatedly violating the HN guidelines. If you don't want it to be banned, you're welcome to email hn@ycombinator.com.
  • harikb 10y ago
    You can also use left right keys to navigate. Just doesn't work with scroll wheel, if that is what you were expecting.
    • duaneb 10y ago
      How about on mobile? It seems incompatible with portrait mode.
• PeCaN 10y ago
  What are some cases where I would choose to write a server in Go instead of in Erlang?
  • freyr 10y ago
    When you want to hire developers.
    • macintux 10y ago
      Hiring good developers for Erlang is easy: just look for functional programmers. It is indeed hard to hire mediocre developers for Erlang: they stay away from FP.
      • 010a 10y ago
        Great meme bro.
    • davidw 10y ago
      The last place I worked, we built a system that included Erlang. When it was time to hire someone, we found a guy who was curious about Erlang, and although he didn't know it pat, he was a good hire, as he was a smart guy, hard worker, and curious not only about Erlang, but a lot of stuff. That's the kind of person you want to hire anyway, unless you are super crunched for time in getting someone up to speed.
    • im_down_w_otp 10y ago
      Never had a problem finding or training great Erlang engineers, and even had a few cases where the absolute best of the candidates were only interested because they'd get to use Erlang. (shrug).
      • deleted 10y ago
        [deleted]
    • rdtsc 10y ago
      > When you want to hire developers. When you want to hire good developers pick Erlang, Elixir, Rust, Haskell, ML, LISP. Because chances they went out of their way to learn the language as it is not taught in US universities in depth. They are probably curious, good learners and could probably learn or adapt to other new things thrown at them. I am at shop were we use Erlang and syntax has not phased new people that much. If typing . instead of ; is a big deal, then what are they doing to do when a netsplit hits or they have to understand other concurrency issues. I don't know, I find Erlang's syntax rather nice, if anything it tells my brain "this is not C anymore, don't think like C". Works for me, any way. There is Elixir of course if syntax is an issue. Elixir has other useful features as well but still runs on the same battle proven platform.
• fauigerzigerk 10y ago
  ">50% of code base changes every month" I wonder what unit is being counted here. I don't think it's possible to actually review and rethink 50% of what has been created before. That's just not sustainable.
  • robotresearcher 10y ago
    > 5000+ developers across 40+ offices That's an enormous amount of manpower.
    • fauigerzigerk 10y ago
      That doesn't matter. Only growth of manpower matters. The fundamental problem stays the same regardless of how many people you have. If you add code and revise 50% of it every month, the code base is bound to grow and the share of time spent on maintaining the old code grows as well until development of new code grinds to a halt. Unless of course there is massive growth in hiring. But that isn't sustainable. [Edit] Well, I forgot one possibility: Deleting code.
      • Jabbles 10y ago
        https://www.theatlas.com/charts/4ySTybWY https://www.theatlas.com/charts/4ySTybWY (Can't vouch for accuracy.)
    • Sajmani 10y ago
      And these numbers are 5 years old :-)
• squiguy7 10y ago
  > Clarity is critical. When you need to write high performance code this is a great maxim. I enjoy the simplicity of Go and the guarantees it provides. Being able to reason about code and not having to guess is a win for any development team.
  • ridiculous_fish 10y ago
    IME, clarity and reasoning are weak points of Go, relative to other systems programming languages (but perhaps not to dynamic languages): 1. Slices make it hard to reason about aliasing. bar = append(foo, val): does bar now alias foo? The answer is the worst possible: "sometimes." 2. Closure semantics make it hard to reason about thread safety. I converted this serial loop to parallel using goroutines; did I introduce a race condition? I have to look at each variable to decide. (Any sort of const capturing would go a long way here). 3. Goroutine leaks can be hard to reason about. For example, a channel that is not sufficiently buffered can result in a leak. 4. Nullable maps and channels reduce clarity. 5. The "redeclare" semantics means := sometimes does not introduce a new variable
    • squiguy7 10y ago
      I didn't mean to gloss over the go routine problems. You're absolutely correct, when there exist tools like the race detector it makes it evident that you can write incorrect concurrent programs. Becoming proficient at using the concurrency patterns in Go takes time but it is an advanced topic. Thanks for writing up these common mistakes.
      • colin_mccabe 10y ago
        Those aren't common mistakes, just things he dislikes about the language. For example, I don't care whether := sometimes does not introduce a new variable (have never had a bug related to that). I don't find the closure semantics any worse than Java's (sure Java requires captured variables to be final, but it doesn't require them to be immutable). I find append's semantics to be pretty intuitive. But then again, I'm familiar with realloc in C, which is where it came from. At any rate, slices are references to an underlying array. If you are making one slice from another slice in a way that potentially doesn't involve copying, you should expect the new thing to alias the old thing. People often complain about channels having limited buffer sizes. But if channels had unlimited buffering, they'd complain about memory leaks and inefficiency. A list of common mistakes in Go would be interesting. It would probably start with the "assigning a typed nil value to an interface leads to interface != nil" wart.
• nimmer 10y ago
  I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.
  • Cyph0n 10y ago
    Absolutely. It's unfortunate that Nim is relatively unknown - here's hoping it gets a large backer sometime soon to boost its popularity! I'd also add D (above C++, level with Java) and Rust (above C++, close to Go).
    • binki89 10y ago
      And Crystal (http://crystal-lang.org/ http://crystal-lang.org/).
      • Cyph0n 10y ago
        Definitely, but isn't Crystal still in its early stages? I heard it doesn't even have Windows support yet for example.
        • binki89 10y ago
          Yes, you're right that it is in an early stage of development and doesn't yet support Windows (to be fair, even Rust added full Windows support fairly late in their development cycle to 1.0). Crystal is probably in a slightly earlier stage than Nim, though not by much. Both are very interesting languages that I think would plot in similar locations on the chart. D is also a lot of fun. I think all are competing in this same native compiled realm that seems to be popular right now.
          • steveklabnik 10y ago
            Rust had "windows support" far before 1.0, though it was through minGW only for the first few years. MSVC support was added four days after 1.0 was released.
• robohamburger 10y ago
  I will have to try Go again. It seemed really awesome at first then quickly seemed like a regression in a lot of PL design things (which is good in some cases). I personally like rust but maybe I am a glutton for type based punishment. Solution: design the language for large code bases This seems crazy but whatever works. I would assume that would only buy you some wiggle room inside whatever order of magnitude of committers you have. It seems like eventually you would need to split up the code base if you are having contention issues.
• yanilkr 10y ago
  I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways of thinking and then you will have a place for it. Some people are not willing to take that leap of faith unfortunately.
  • kmiroslav 10y ago
    That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.
    • yanilkr 10y ago
      This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.
      • kmiroslav 10y ago
        > There is no universal best language nor there will ever be the one. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones.
        • yanilkr 10y ago
          javascript and python would disagree with you.
• aj7 10y ago
  Can't read on IOS
• fpgaminer 10y ago
  All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good for server applications, and I haven't looked back. It has been bullet proof from day one and I am overall happy with the development experience. That was the good. The bad? Garbage collection, dependency management, and lack of first-tier support in various libraries. Garbage collection makes the otherwise lightweight and speedy language a memory hog under heavy loads. Not too bad, but I have to kick the memory up on my servers. Dependency management is a nightmare; honestly the worst part about it. The lack of first-tier support in various libraries is a close second. AWS's API libraries had relentless, undocumented breaking changes when we were using them, all on the master branch of their one repo (breaking Golang's guidelines for dependencies). Google itself doesn't actually have any real API libraries for their cloud services. They autogenerate all API libraries for golang, which means they're not idiomatic, are convoluted to use, and the documentation is a jungle. We continue to use Go because of its strengths, but it just really surprises me how little Google seems to care about the language and ecosystem.
  • devsquid 10y ago
    You would like to write an entire server without using a GC?
    • asolove 10y ago
      Presumably he is complaining about the GC implementation's characteristics, not its existence. You can read a description of the team's design decisions here: https://blog.golang.org/go15gc https://blog.golang.org/go15gc but a simple summary would be: memory is cheap and getting cheaper, so focus on making GC fast rather than small memory footprints.
      • merb 10y ago
        actually thats what the Java G1GC (which will be the default in Java 9) does aswell. However I would still favor java instead of go
• sly010 10y ago
  Go is my secret and I wish less people used it, so I had an advantage over them ;) Edit: typos
• justinsaccount 10y ago
  > Lingo: Logs analysis in Go, migrated from Sawzall Would love to play around with this
  • mikecb 10y ago
    As far as I could find not open sourced, but talked about at the data science blog (which is generally awesome): http://www.unofficialgoogledatascience.com/2015/12/replacing-sawzall-case-study-in-domain.html http://www.unofficialgoogledatascience.com/2015/12/replacing...
• inglor 10y ago
  The slides are awesome and I really am fond of go, but the examples using channels are all more code to write considerably than I'd write in C# or JavaScript with async/await and not any more robust or safe. Go is great for actor based systems where you model things using channels and goroutines for what they stand conceptually - not when you use it to simulate Task.WhenAll/Promise.all with a timeout. I think _that's_ what they should be selling - that your server's architecture should typically be different.
  • weberc2 10y ago
    Yes, but in Go you don't have to deal with the [colored function problem][1], and the code to parallelize I/O is no different than the code to parallelize computations. I agree that these examples don't do justice to Go's concurrency facilities--the most compelling examples are probably too complex for a slide deck. [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
    • inglor 10y ago
      The code to make I/O concurrent _should_ in my humble opinion look different from the code to parallelize computations since well - in I/O you only care about concurrency and in computation you care about parallelism.
      • weberc2 10y ago
        It's not obvious to me why this distinction is useful. Could you explain?
  • zeveb 10y ago
    > The slides are awesome They look good, but completely failed to work on Firefox for Android.
• BooneJS 10y ago
  I use Go exclusively for command-line applications, previously using Perl (ducks). It's a fairly simple language, you can pick it up quickly, and gofmt/godoc/etc are useful utilities in reducing friction.
• callumjones 10y ago
  I think "Program your next server in Go" is a little too broad, the specific language features that Go explicitly leaves out makes it hard to build an extensive backend server. Go is best suited to use cases listed in these slides: simple services that do very focused things. I love Go and used it to build some very useful web hook and CLI tools. It just doesn't lend itself to something where you expect to have a vast set of APIs under one Go project.
• iagooar 10y ago
  One important niche I see that Go serves very well is in distributed, fault-tolerant deploy platforms (aka schedulers), like Kubernetes or Mesos. If you look at the amount of tooling that uses Go, you almost feel there just is no other choice out there. I would not adventure to say state-of-the-art schedulers would not have been possible without Go, but for sure Go fits the requirements pretty well.
  • supernovae 10y ago
    Mesos is c++ and marathon and other schedulers are based on jvm :)
  • simeonf 10y ago
    > I would not adventure to say state-of-the-art schedulers would not have been possible without Go, but for sure Go fits the requirements pretty well. AFAIK Mesos is mostly written in C++. Aurora - a Mesos framework & scheduler from the same folks is written in Java & Python.
    • iagooar 10y ago
      Yes, what I meant is that a lot of tooling around those is done in Go.
• yvsong 10y ago
  Any comment on Swift vs Go, potentially for server programming?
  • jsmith0295 10y ago
    I don't think Swift is particularly mature in this area yet, and it's concurrency depends upon Grand Central Dispatch. Go on the other hand is rather mature, especially for its age. Other than that, it really depends on what the server is for, but in general I would say Go is probably a better choice. If you're interested in something similar to Swift for the server, I think Kotlin w/ Spring Boot would probably be a safer bet at this point.
  • chris_7 10y ago
    Swift is most likely not ready for this until 3.0/SPM release, but once it'll be very competitive. Swift generics are very good and Go's are not. There's no language-level concurrency, but there's GCD and https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice
  • drivebyops 10y ago
    Swift would be more expressive, I certainly had a grand time writing in it. I wonder if it can get HKT ahead of C#
  • pjmlp 10y ago
    Swift is a much more expressive language, designed by folks that accept the world of programming paradigms in the mainstream has progressed and is sponsored by IBM for server programming. https://developer.ibm.com/swift/ https://developer.ibm.com/swift/
• matthewmacleod 10y ago
  Go has been great for me at providing things like simple microservices, network plumbing, CLI tools and that kind of thing. The C integration is also super simple and makes it easy to wrap up third-party libraries. It's also a bit tedious to write in practice. It's dogmatic, and that's obviously a benefit in some ways but comes with the cost that quite a lot of time in my experience is wasted fiddling around with program structure to beat it into the way Go wants it to work. Dependency management is better with Glide but still not perfect. The type system is quite annoying, and although it's a cliche the lack of generics is quite annoying. Lots of silly casting to and from interface{} or copy-and-pasting code gets old quickly. Still, it's a great tool for its niches and I really think everyone should pick it up and use it - the idea of simplicity it promotes is actually kind of interesting, in contrast to the "showy" features one might expect of a modern language.
  • ben_jones 10y ago
    Last night I was beating my head against the desk on some highly concurrent code that involved each co-routine satisfying a simple rate limit, among other things. Two hours later I had it working and the final implementation ending up half the size of the original (~1k LOC -> 500 LOC). I would upgrade your phrasing to: "frustratingly dogmatic in an ok way".
• thom 10y ago
  Holding up Perl and JavaScript as examples of languages that are 'fun for humans' makes it pretty clear I'm not the target market.
  • the_common_man 10y ago
    Can't speak for perl because I have only seen some horribly complicated code in it (which probably speak more of the author and not the language itself) but what's not fun about JavaScript ?
    • baby 10y ago
      especially with React Native, NodeJS and Electron... you can pretty much write anything you want, easily, that will run on a bunch of platform. I still prefer Python/Ruby/Perl... over JS. But I would pick JS anytime over Java.
    • jonathankoren 10y ago
      I used Perl for years, and it's still my go to language for quick text parsing. I stayed away from the bizzare "object oriented" syntax (They're not classes. They're packages, just called with arrow operators instead of like normal functions. But being Perl, you can just use the package and call the functions yourself because TMTOWTDI! (Blech.)) Also Perl's support (or at least Perl 5 (Does 6 even exist? It's like a unicorn like Duke Nukem Forever or Guns-n-Roses Chinese Democracy, only those eventually got released.)) for complex data structures (including multidimensional arrays) requires explicit reference instanteation and dereferencing, like C pointers. It's the biggest pain point.
      • sulam 10y ago
        I am no Perl apologist, but they DID finally release Perl 6: https://perl6advent.wordpress.com https://perl6advent.wordpress.com
    • codedokode 10y ago
      Bad parts of javascript: - many mistakes are silently ignored. If you mistype object field name, divide a number by zero, add number to a string, access missing array element, no error is raised - no proper OOP and classes - no type hints for variables, function arguments or return values (well, there is TypeScript but it is another language) - package manager (npm) loves to create deep hierarchies of folders
• naivepiano 10y ago
  I'm afraid HN has a serious problem with downvoters. Why -in heavens name- is the above a question that deserves downvoting? UPDATE: whoray - I got downvoted too. Gee man. Just not worth it. Buy and thanks for the fish.
  • fpgaminer 10y ago
    I'd venture to guess because it has an unnecessary negative tone to it. Specifically the "Sounds stupid" part. That two word postfix is unnecessary to ask the question and adds a negative and dismissive attitude to the discussion. A good gauge for any comment here is "Would you say this at a business meeting?" I believe the answer here is that the snide remark "Sounds stupid" would be left off when speaking amongst professional company.
  • dang 10y ago
    We detached this subthread from https://news.ycombinator.com/item?id=11856539 https://news.ycombinator.com/item?id=11856539 and marked it off-topic.
• moron4hire 10y ago
  I've been experimenting with this concept with C# recently [0], where I have a small backend written in C#, exposing a simple, RESTful HTTP server, that automatically finds itself a local port to run on and opens the default browser to a default page. It's actually kind of nice. Until I did this the first time, I hadn't realized just how much bullshit I had previously put up with, with setting up local web servers, trying to get configurations down, etc., etc. At some point, I think most web framework's configuration options just got too complex to be considered configuration options and became weird, poorly defined scripting languages for defining web servers. Having a real programming language to do that instead is just a wonderfully smooth experience. Some things I plan on implementing with it: * local file system access, to ultimately implement an FSN [1] clone in my WebVR project. * my own Leap Motion WebSocket service, because the default one doesn't use the latest Orion beta and its associate JS library is complete garbage. * A similar dude for MS Kinect data. * Ultimately, get the previous two to run over WebRTC instead (not easy, there is no WebRTC library for Windows outside of major browser implementations) to be able to stream their respective camera data. * Live raytracing of model textures for baked lighting in scenes in the WebVR session. Right now, it's just a source file I drop into a standard C# console project. I'm thinking about making it a full-on library, though at this point there isn't much need. [0] https://github.com/capnmidnight/HereTTP https://github.com/capnmidnight/HereTTP [1] https://en.wikipedia.org/wiki/Fsn https://en.wikipedia.org/wiki/Fsn
• shurcooL 10y ago
  I like slide 41 [0]. What just happened? In just a few simple transformations we used Go's concurrency primitives to convert a - slow - sequential - failure-sensitive program into one that is - fast - concurrent - replicated - robust. No locks. No condition variables. No futures. No callbacks. It's the ability to make these kind of transformations effortlessly at any level, whenever I need to, that make me appreciate choosing Go when solving many tasks. [0] https://talks.golang.org/2016/applicative.slide#41 https://talks.golang.org/2016/applicative.slide#41
  • brobinson 10y ago
    >No locks. I'm sure the author means there's no explicit locking done by the programmer, but readers should be aware that channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself).
    • mappu 10y ago
      >channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself). Is that for both buffered and non-buffered channels?
      • enneff 10y ago
        Channels are implemented using locks, but "4x slower" is a meaningless microbenchmark number.
        • brobinson 10y ago
          You're welcome to benchmark it yourself. I got it from [1] which is a pretty recent comparison. [1] http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ http://www.jtolds.com/writing/2016/03/go-channels-are-bad-an...
          • 10y ago
• hobo_mark 10y ago
  I might have strange requirements for a server, but I need rdma, verbs, libfabric... Is there any way to use them in an idiomatic way in go?
  • kkirsche 10y ago
    Not that I know of. That sounds like it goes against much of what Golang builds around and the areas I've had to hook into low level areas such as the kernel for NetFilter required me to go down to C
• capote 10y ago
  How do the bullet points in "Why does Go leave out those features?" address why Go leaves out the features on the preceding slide? All it talks about is clarity (important but not the only important thing) and I just don't see how any of the left-out things are inherently unclear. I think you can write clear and unclear code alike with all of those left-out features.
• zZorgz 10y ago
  I had a PHP program that processed HTTP requests and stored some data onto a local database, and decided I needed to rewrite it for various reasons so I decided to choose Go. Some points I recall: * Static typing is good. * As I expected, the standard library and other packages available had the http & routing stuff I needed, which is all good. * I like that errors are specified in function signatures, unlike exceptions in languages like ruby/python. * I don't like errors being easily ignored, and return values being assigned default or arbitrary values. I once may have also accidentally used the wrong equality operator against nil. * Defer is nice, but would be better if it was based on current {} scope. * Append on arrays? has very bizarre semantics sometimes mutating or returning a different reference. * Initially I ran into trouble reasoning how to use some sql package and ran into "invalid memory" deference issues or some such when passing a reference. Thus, I'm skeptical about "memory safety." This was only a simple program though and turned out to be worthwhile for me in the end.
  • xcombelle 10y ago
    memory safety imply that if you do something bad you will be stopped (with "invalid memory" issues for example), not that it is illegal to write something bad
    • zZorgz 10y ago
      Well I am also then interested in it being hard or illegal to write something bad :)
• Matthias247 10y ago
  The presentation focuses a lot on [web] servers and google scale, but I found that Go also works quite well for applications/services on embedded linux systems. Main pros for me there are: - Easy to cross compile and deploy - Daemons often need to do a lot of communication (some also for providing web APIs) and need to embrace concurrency. Both are covered very well by Go's ecosystem. - Compile-to-binary eases distribution concerns in cases where you want to avoid to publish all source code (and thereby know-how) compared to VM languages or scripting languages.
• dicroce 10y ago
  "Sometimes this means writing out a loop instead of invoking an obscure function." I can't help but think this is specifically a dig in C++'s direction. Since C++11 lambda's I've been using <algorithm> a lot more and I don't think you could get me to go back at this point... Yes I had to learn exactly what a few methods do, but now I have beautiful straight line code...
• chuhnk 10y ago
  Go is a phenomenal systems programming language and becoming quite useful as a general programming language too. It's clear from the projects that are now coming into existence that Go lends itself well to the world of distributed systems and from the language design you can see that it was created with network programming in mind. The fact that concurrency is built into the language and errors are treated as values that should be dealt with just highlights those facts. We used Go at Hailo for our microservices platform and it served us incredibly well. I've gone on to create an open source project called Micro https://github.com/micro/micro https://github.com/micro/micro that builds on those past experiences. It's just a joy to write micro services in Go.
• poorman 10y ago
  server is a pretty loose term. Most servers* these days require some sort of full stack, with frontend, ORM, etc... Go adds a lot of development time if you need all of that. ...On the other hand, one off tiny microservices, it's absolutely great!
• insulanian 10y ago
  Which kind of applications does one write in Go? Asking this from perspective of a developer working mostly on business apps with Angular frontend and .NET (C#/F#) backend.
  • spriggan3 10y ago
    If you use C#/F# you don't need Go, .net is coming to Linux by the way so you definitely don't need Go. With Go you'll basically have to rewrite asp.net from scratch if you're used to that, because frankly the ecosystem is poor if you don't stick to data transformation/ marshaling with an HTTP server. No full featured ORM, no good Logging library, no Razor like view layer, piss poor web frameworks and an extremely rigid language with a rigid type system if you are used to F# and C#. The only advantage of Go is the fact that you can deploy a single executable with no dependencies on a server. That's it.
    • insulanian 10y ago
      Oh, I definitely don't want to switch to Go :-) I did take a look at it once and decided that it is not for me. That being said, I still wonder what types of applications are so suitable for Go that people decide to use it instead of other languages?
• bfrog 10y ago
  Go is a fine language and a very good run time, though having written a large program with it I've learned its warts well enough to not want to use it again personally.
• oconnor663 10y ago
  > When writing code, it should be clear how to make the program do what you want. Sometimes this means writing out a loop instead of invoking an obscure function. For example instead of the obscure function a.reverse() you can use the clear for loop for i := len(a)/2-1; i >= 0; i-- { opp := len(a)-1-i a[i], a[opp] = a[opp], a[i] } :(
  • tagrun 10y ago
    The irony in your smug reply is, it echoes the broken leftpad mentality of javascript programmers. Go is statically typed, and this either requires generics or a new built-in for just reversing an array/slice. And I can't see how a trivial operation as array reversion is worth it, and there's just no end to adding such trivial operations. If you need a slice with reverse, just add a typedef and define reverse on it --it's just a trivial loop. What is it that you want to say? That array reversal too much for mortals and better be left to array experts? Array sorting is both important and nontrivial subject, and its place in the library is justified (similar to the situation with C). BTW, I don't understand why your for-loop runs backwards (which makes the code look awkward to me) or why you have to define opp in the loop body. Just define len(a)-1 as a variable in the initialization and be done with it.
    • oconnor663 10y ago
      Guilty as charged on the smugness, sorry about that. This reply is meant to be smugness-free. My example above is the semi-official one from https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks. The `oop` expression contains a reference to i, and so it needs to be in the loop body. I'm not sure why they opted to do it in reverse though. (Maybe they don't want to compute `len(a)/2` every time, and don't want to use a temp variable? Not sure if it would get optimized away.) In my head there are three reasons (apart from my own laziness) that I like having reverse() in a language's standard library: - Code is read more often than it's written. A for loop like this takes time to read, if you don't already know what it does. - Tricky loops hide bugs. If we forgot the `-1` term in the initializer, I'd probably miss it in a code review, and the bug would only show up for even-length lists. - Expert attention turns out to be useful here! In languages that check array bounds by default, you can gain a little speed by avoiding bounds checks in reverse(). Rust does this (https://doc.rust-lang.org/src/core/up/src/libcore/slice.rs.html#442 https://doc.rust-lang.org/src/core/up/src/libcore/slice.rs.h...), but I wouldn't want an `unsafe` block like that in code I had to copy-paste around.
• codedokode 10y ago
  Here are the problems I had when tried to write a simple CLI utility (tool to run any program in seccomp-bpf based sandbox) in Go: - using case of a first letter of identifier as a public/private flag. You end up with half names starting in a lowercase letter, half in an uppercase (the code looks inconsistent) and forgetting how to spell them. And having to rename the function everywhere when you decide to change it from private to public. - no official package manager. Unclear how to add external libraries to your project and how to set specific version you need. I ended up adding necessary files into a separate folder in my project. - Go manual suggests you have single directory for all projects and libraries. That was inconvinient because I develop on Windows and use Linux only to test and run code in /tmp directory, I do not keep the code there. And why would I want to keep unrelated projects inside the same directory anyway? - no rules how to split contants, types and functions into files and folders. For example in PHP there are certain rules: each class goes to its own file and you always know that class Some\Name is stored at src/Some/Name.php. Easy to remember. And in Go you never know what goes where. Large projects probably look like a mess of functions scattered around randomly - no default values for struct members, no constructors - no proper OOP with classes - standard library is poor - open source libraries you can find on github are not always good. I looked for library to handle config files and command line arguments and didn't like any. - standard testing library doesn't have asserts - easy to forget that you need to pass structures by pointer (in OOP objects are passed by reference by default). And generally use of pointers makes the code harder to read and to write. - weird syntax for structure methods. They are declared separately from the structure. - go has 2 assignment operators (= and :=) and it is easy to use the wrong one - having to check and pass error value through function calls instead of using an exception. So most of functions in your code will have two return values - result and error - no collections library - simple things like reading a file by lines are not so simple to implement without mistakes - static typing is good but sometimes you cannot use it. For example I wanted to have the options in a configuration file mapped to the fields of a structure. I had to use reflection and every mistake lead to runtime panic. And you cannot use complex types like "pointer to any structure" or "pointer to a reflect.Value containg structure" or "list of anything" or "bool, string or int". Of course Go has also many good parts that might outweight its disadvantages but I am not writing about them. For example I have not used goroutines but they look like a simple solution for processing async tasks or writing servers. I think Go is not ready yet for writing large applications. It might be ok if you write a small utility but I cannot imagine ORM like Hibernate or web application written in Go. Also I took a look at the code in the presentation. I wouldn't want to write such code. For example, here https://talks.golang.org/2016/applicative.slide#20 https://talks.golang.org/2016/applicative.slide#20 they use static methods (http.HandleFunc(), log.Fatal()) instead of instance methods. So you cannot have two logs or two servers. Using static methods everywhere is bad especially in large applications. Google itself uses Go only for small utilities like simple proxy servers.
• voltagex_ 10y ago
  Can anyone convince me to use Rust over Go, or the other way around? My target machines range from i7s with massive amounts of RAM to Raspberry Pi with slightly-less-massive amounts of RAM.
  • Drdrdrq 10y ago
    Well, I can't do that (haven't used any of them enough for that) but I find it telling that Rust is missing from the slide where they compare the languages... :)
  • FlyingSnake 10y ago
    > Rust over Go Rust: Best suited for writing OS, network stack, embedded systems, and webservers like Nginx. Go: Best suited for writing micro-services, CRUD apps, API servers etc pick your poison
    • egeozcan 10y ago
      I did write a CRUD app with Go and after that experience, IMHO, for CRUD apps, one is better off with a dynamic language (JS, Ruby, Python) or a static one which supports generics (C#, Java) or Macros (Nim).
      • fortytw2 10y ago
        Right on. Go is best suited for network-heavy, concurrent applications (infrastructure systems, databases, OS-tools), or software that needs to be dead easy to set up / deploy (single static binary, free cross-platform compilation). If you want to go build a CRUD app, use RoR/Django/Whatever(tm) and be happy with it
  • shadowmint 10y ago
    I think the tldr; of this (often raised...) argument boils down to: Don't use rust if you're asking that question. If you could implement your solution in go or rust, then go is probably a more appropriate choice; it's a good high level solution for high level problems. Rust is not a good solution for high level problems; it's a good solution for low level problems where go would be a terrible choice; and it's a good solution for high level problems where other choices are even worse (eg. C++). They're both good languages, and you'll learn way more from picking up rust than you will from picking up go, so if you're just screwing around and want to learn a language this year, absolutely, pick rust or clojure. Go isn't on the list for 'interesting programming languages'. ...but if you have an actual problem you're trying to solve, I would be hard pressed to enumerate the reasons why you would pick rust if the problem was solvable using go. Maybe because your C dependencies would be easier to call from rust than go? That's all I can think of.
• warcode 10y ago
  I always see Go promote Clarity/Readability and yet in the second example its already "fmt.Fprintln". That is not easily readable for humans.
• VeejayRampay 10y ago
  I wonder why on that fun/fast diagram, it appears as if Perl faster than Python, which is faster than Ruby. They're all about as slow.
• cryptos 10y ago
  There are some questionable statements: > Go differs from Java in several ways > Programs compile to machine code. There's no VM. This tries to imply that having a VM is a bad thing. > Simple, concise syntax The syntax is simple, but not overly concise. For example the lack of generics leads to a lot of repetition. > Statically linked binaries You can have them with Java, too. > Built-in strings (UTF-8) Should this suggest that Java doesn't have trings? > Built-in generic maps and arrays/slices Yeah! Some of the most awesome things about Go is the limited set of data structures and the limitation of generics for exactly this few structures. > Built-in concurrency It is questionable whether this is good or not. There are a lot of good concurrency libs for the JVM. > Sometimes this means writing out a loop instead of invoking an obscure function. This is completely strange! The lack of abstraction is sold as a good thing. Actually a lack of abstraction leads to redundant and error prone code.
  • wjagodfrey 10y ago
    In regards to your last comment, abstraction is a good thing but there's a conversation to be had around quality of abstraction. Good abstraction doesn't age, or at least ages very slowly. Lack of abstraction in languages leads to innovation and iteration, that then leads to good abstraction. We are general too quick to assume that a new thing is good abstraction. Better, in some cases, to leave abstraction discovery in userland, as good abstraction is rare. The cost of poor abstraction within a language is API and cultural lockin, when better solutions are found.
  • pjmlp 10y ago
    Java also enjoys AOT compilers to machine code, but the fact that only commercial JDKs support it makes many ignore that little fact. Maybe with the upcoming AOT compiler in Java 10, more people will become aware of it. Sadly it appears to be a commercial feature.
  • geodel 10y ago
    It is not that strange considering Java is frequently mocked for highly abstract / design pattern laden 'AbstractSingletonProxyFactory' code.
  • 10y ago
• epynonymous 10y ago
  golang is great, i use it to do 3 things thus far: restful api server (net/http, gorilla mux), dynamic web server (net/http, amber, sql), and websocket server (net/http, gorilla websocket, redigo/redis). the libraries are well implemented, the syntax is beautiful imho, and i'm able to quickly write code similar to interpreted languages like ruby, python, but scale much higher. i used to do lamp, then shifted to python tornado, ruby sinatra, nodejs/expressjs, but find golang to just be more compact and fast. my sinatra environment required rbenv, gems, and i just wasn't impressed with it. what i like the most about golang is that the end result is a binary where my production server doesn't need to have any dependencies except for the ability to run elf binaries. i like having this option, but in reality the binary size gets pretty unwieldy for upload, so i actually end up doing a pull on the source code, compiling and starting up. package management has not been a problem for me. i do find html template packages to be a bit deficient, amber, ace, there are ports of haml and jade, but they all seem pretty half baked. i had to have a lot of hacks in my code to get this stuff working. also sucks that there isn't a standard orm, but i can hang and keep up with raw sql. the language expressiveness is not as convenient as say ruby, but it's pretty close.
• moyok 10y ago
  I really like go. I just love that it compiles to a native binary and is so easy to distribute. I love the way interfaces work and that types specify interfaces automatically without explicitly specifying that. I love the "strictness" of the language - for example the code won't compile if you declare a variable and not use it, or import a library and not use it. I love that there is a standard gofmt which means code auto formats to a standard format. These features really help set some "discipline" when working in a team. I love the way concurrent code can be called easily and the use of channels. I love the performance - it has been more than fast enough for my use cases so far. I love that I can get started with an HTTP server using just the standard library, and the most popular web frameworks in go are micro frameworks. Overall, there's a kind of a simplicity about the language that underlies all of the above things, and that is what makes me excited about go. I have used go in some minor projects that have been running peacefully for months without any hitches, and am using it in a big project mostly in the form of microservices and scripts. It has become my favorite language now.
• sargas 10y ago
  The fast/happiness graph of languages is pretty interesting. Unrelated: Rust would probably be around the right-most area in the horizontal axis, close to C and C++, and a little below Go in the vertical axis.