18 ms·

Building Web Apps in Go

• brightball 11y ago
  Looks like a great contribution to the community. Major props for freely releasing it. Most of the Go references that I tend to come across tend to focus on code, concurrency and API's without much attention to the full stack web app side. This definitely helps to fill that gap in the community. Just flipping through the contents and skimming the chapters, the IDE section alone is really impressive.
• sna1l 11y ago
  This is amazing!!
• bpicolo 11y ago
  In multiple languages even. Very cool : )
• Vendan 11y ago
  Note, in the IDE section: LiteIDE has gocode bundled, and in most cases, you can leave the GOROOT and such alone. I have yet to need to change it on either linux or windows.
• aladine 11y ago
  Great book. Thanks
• echelon 11y ago
  I'm so conflicted by Go. If I want to write a website quickly, I'd use Python. If I were concerned about performance, I have Java. I write my systems stuff in C++ (Rust now). Is there a compelling reason for me to even learn Go? Is it better than Java in some measurable way? Should I take the time to learn it? Honestly curious.
  • nkozyra 11y ago
    At least for the Web, Go will match the conciseness of Python with the performance (almost) of Java. It takes a lot of cajoling to make Python a great backend for the Web. Since confounding downvotes, a tldr: closer to Python than Java.
    • TheSwordsman 11y ago
      I'm not sure I fully agree it'll match the conciseness of Python. Go will be more verbose, for sure. If you start having to Marshal/Unmarshal JSON, it'll get pretty annoying pretty quick depending on the JSON format.
      • nkozyra 11y ago
        Go's JSON marshaling can be heavy if you tie it to a strict struct versus, say, an interface. You can make it light, but yes, sometimes some reflection is necessary to utilize that data. For most web applications, JSON in or out is of a known schema, so this generally impacts other servers moreso than web applications.
        • TheSwordsman 11y ago
          Oh absolutely. I guess I was trying to call out that, depending on the API you are supporting, it can get hairy. If you are designing it from scratch, when starting the Go project, you can structure your JSON in a way that's easy to work with. If you're coming in to something that was easy to use in a language like Python, it may not be that easy in Go.
          • nkozyra 11y ago
            I guess my point is it will be more concise than Java, certainly closer to Python.
      • stephenboyd 11y ago
        And if you have to marshal/unmarshal XML, it gets worse. Go's XML library is buggy and its documentation recommends using JSON instead.
  • TheSwordsman 11y ago
    I wouldn't personally compare it to Java, having written it for some time. I too am not too fond of writing web apps in Go. It's doable, and you can do things to make it easier, but it can be painful. It took me some time to get in to the groove. I see it being used for system tools, to some degree, because it requires no runtime at all (static binary). It also seems to be pretty popular for different newer data stores. Again, if it's pure Go it'll run anywhere... so it makes development (and portability) much easier. I like its concurrency model, to a point. That said, I hope they really improve some things about in Go 2 (like working with channels and goroutines). I'm not sure when that will be. I use Go for a lot of things, most of which are command line applications. Whether it be interfacing with some sort of REST API, taking actions on the local system, or some sort of network client for devices on my LAN. It works well for quite a few cases. It seems to fit well with my mental model quite often, so I use it. And it's a simple language, so it was easy to get started with it. At the end of the day, it's a tool like many others. I think it's up to the creator to choose the tool that feels best to them.
    • e12e 11y ago
      > I see it being used for system tools, to some degree, because it requires no runtime at all (static binary). This is something I haven't seen discussed much recently. Do people generally think static linking is a good idea for things other than self-contained system-level daemons? (Where that daemon and supporting libraries might be the only thing you deploy to a server/vm/container)? As I recently read in a (rather poor microbenchmark article) [1]: "The C assembly code I got with the following command is just 40 lines long. (...) The Go assembly code is 161.021 lines long which must be due to the static linking of Go.". As everyone (should) know(s) any kind of language that lets you write a useful program in a page or two of code, will include a runtime of some sort (or be depressingly machine- and kernel-specific assembly code, and probably slower than anything a modern half-decent compiler produce). But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found. [1] Just included for reference, I don't really mean to pick on the author, but it's rather standard fare in the "quickly do a microbenchark; prove only that I'm wrong"-vein: http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-pypy-vs-Python/ http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-p...
  • brightball 11y ago
    It's a language that when compared to other languages it's the 2nd best at so many features that it gets the title of the most well balanced language. For the most part, it seems to have gained traction in the Ruby/Python/PHP world as a backend optimization language. IMHO that's where it currently fits best for most people.
  • stephenboyd 11y ago
    It's good for when you want to write something quickly and you're also concerned about performance. It's a deliberately simple language, it's designed so the most naive simple choice is often the best choice, and you can learn enough in one day to start developing productively. I've never tried to make a whole web app with it, but it's great for making microservices.
    • d1ffuz0r 11y ago
      Most of the time database is the slowest component of any website
      • collyw 11y ago
        Don't know how this got downvoted as it seems to be the case for most applications I have worked on.
  • viach 11y ago
    Go is less verbose than Java and more statically typed than Python, here you go.
  • ihsw 11y ago
    Some people think Java is icky and other people think the JVM brings too much baggage for their comfort. Warranted or not, it usually fills the space where fast microservices are necessary. Personally I think Go's closest competitor is Scala. Coming from Python, Ruby, and TypeScript -- Go is a fair bit more verbose, and Java takes that a step further. So Go is a nice go-between from scripted environments to compiled.
    • jpliska 11y ago
      Have you seen kotlin? Its a cross between java, python and scala for the JVM (and JS - with wrinkles)
      • xaduha 11y ago
        Everyone should seriously consider using Kotlin, it's here to stay.
        • minionslave 11y ago
          The only thing I hate it the extra symbols. How to they justify using : val companyName: String = "JetBrains". Instead of string companyName = "Jetbrains" ?
  • latch 11y ago
    I wrote The Little Go book [free], my first Go blog post was in 2011, and a few of my Go libraries are used by people other than just me. But Go's not my goto language. I'm a staunch believer in the productivity of dynamic languages. In my opinion, Go's less than stellar type system and weak reflection capabilities exasperate this gap, even moreso for most websites / apis (which deal with impedance mismatch at two boundaries). But, to answer your question. Consider first that Go's very simple to pick up. So the investment is small. Second, where I differ from you is on your second point: Java. I dislike it. It's complicated and verbose and gets in my way. Rust and Go are both proof that we know how to build better languages now. So, when I need to share memory across multiple cores and performance is a concern, I switch to Go because it's fast and simple.
    • bogomipz 11y ago
      Hi, could you elaborate on you comment about Go's "less than stellar type system"?
      • latch 11y ago
        Lack of generics (stick, meet dead horse) is at the forefront. Lack of very basic functions (map, filter, reduce) against slices. map[string]interface{} is pain to work with (one of the moderately popular libraries I mentioned helps: https://github.com/karlseguin/typed https://github.com/karlseguin/typed) Lack of immutability. I don't want to get into errors vs exceptions, but I've never heard a pro-errors argument that wasn't hand waving. I think the decision makes sense given Go's genesis (system programming), but given how Go's actually being used, it's a step backwards.
        • bogomipz 11y ago
          Thanks. Right, generics is a big one. But isn't Go actually being used for system programming? At least that what I think of when I think of Golang. Maybe the scales have tipped and writing api/microservices is the larger use case now?
          • 11y ago
  • deleted 11y ago
    [deleted]
  • biomcgary 11y ago
    Should you take the time to learn it? Yes. It is a very small language, so learning will not take long. Go is a nice tradeoff in development time and performance that is only slightly slower to write than Python (for web servers) but comes with good performance out of the box.
  • dominotw 11y ago
    > Is there a compelling reason for me to even learn Go? Yea if you are doing any devops and want to contribute to or use consul/docker/swarm/kubernetes/terraform.... curious if rust has a hit project like one of those above.
    • tomphoolery 11y ago
      Servo? :-) https://github.com/servo/servo https://github.com/servo/servo I mean, eventually...hopefully...
      • coalescence 11y ago
        That's the browser engine, for webapps, look here - http://arewewebyet.com/ http://arewewebyet.com/
        • steveklabnik 11y ago
          Please use http://www.arewewebyet.org/ http://www.arewewebyet.org/ , the .com has been abandoned.
  • tomphoolery 11y ago
    It's not better than any of the languages you described, but it's certainly different. Go was created in order to build large-scale distributed systems (like the largest search engine in the world), and the problems that Go makes easier to solve may not be the ones that you have. Unlike Rust, Go wasn't created to replace an existing language...it was created to replace an existing way of going about doing things. Unlike Python, Go wasn't created to make code easier to read in general, it was created to make incredibly complex code less ugly. So no, you shouldn't learn Go unless Go solves the problems that you need to solve. That said, as others have mentioned it's a pretty simple language and I found it quite easy to pick up and start writing programs in.
  • iamgopal 11y ago
    My strategy is to write very modular web app in python and when performance needed replace a module with go. Not only at that time specifications are mostly final, but most bugs are also covered. That way I get speed up the development of dynamic language and when needs a raise, use running speed of go language.
  • dcu 11y ago
    I'd say go is just slightly harder to write than python and as fast as (or faster?) than Java. It takes a lot of less memory than Java and Python for sure. Easier to read than both. here's an interesting article: http://www.whitesmith.co/blog/why-i-started-to-use-golang-more-than-python-or-ruby/ http://www.whitesmith.co/blog/why-i-started-to-use-golang-mo...
  • andersen1488 11y ago
    Go compiles to native binaries, and requires no overhead like the JVM.
    • echlebek 11y ago
      Like the JVM, Go programs have a runtime that has overhead.
    • jonathanoliver 11y ago
      Sure it compiles to native binaries which doesn't require a separate VM install, but that doesn't mean it doesn't have overhead.
  • NateDad 11y ago
    Go uses a lot less memory than Java, according to most comparisons. There's a lot of work going on in the cloud space with Go applications (docker, kubernetes, etc), so there's a lot of new libraries for networked webservers getting written. But mostly, you may find you just enjoy writing Go more than Java. It writes a lot like python... I switched from mainly writing C# to almost exclusively writing Go, and whoo boy, I'm not going back. No more huge class hierarchies, no more "everything has to be in a class"... no more "anything I call may throw and jump me out of my function in the middle and I have no idea if it will or not". There's just a lot of niceties of writing Go that don't exist in Java. Sure, there's a ton you can do in Java that you can't do in Go, but once you stop focusing on what Go can't do, you realize, it still can do pretty much whatever you want.
    • vvanders 11y ago
      Java memory usage is not really that high if a bar to beat. Dropbox just rewrote parts of their Go infra into Rust explicitly because of the memory savings they needed.
      • NateDad 11y ago
        Well.. yes, exactly. The question was "why should I learn Go if I know Java?" That's a pretty good reason.
      • ngrilly 11y ago
        Yes, but the rewrite would have happened ever sooner if the original code had been written in Java instead of Go. The Dropbox case is really very specific and very low-level.
    • golergka 11y ago
      Anything you call in go can panic, what's the difference?
      • danieldk 11y ago
        And nearly anything you can call in any language could theoretically exit(3). The difference is that exceptions are a normal control structure in C#, Java, or even C++, while the use of panic should be exceptional. It's not considered the regular way to report an error. Of course, if you have checked exceptions (which are for some unfathomable reason considered bad nowadays), nothing just throws an exception. Moreover, you don't know for sure whether a Go library correctly handles errors, because it's so easy to ignore them.
  • echlebek 11y ago
    Go has concurrency features that the other languages you mentioned don't have. The select construct is a very nice language feature and allows a surprising amount of power. Go's compiler is very fast, which saves a lot of time in aggregate. Go exhibits good design in many areas, including the core language, the compiler toolchain, and the standard library. You can write a complete server-side web application using only the standard library, and it won't be terrible. Go is generally easier to learn than C++ or Java, and requires fewer concepts and fewer steps to produce a working program. A person who has written programs in Java or C can probably learn Go in about a day. Go's spec can be read in one or two sittings. The way to write "good" code in Go is usually obvious. I've spoken to some detractors of Go and can understand where they're coming from. Erlang and Elixir users tend to not find Go's concurrency features compelling. Functional programmers will not find that Go provides much in the way of expressive power. Java programmers have expressed concerns about the Go garbage collector, although I think a lot of those concerns are now at rest. For those that enjoy the set of tradeoffs that Go makes, it's a nice way to engineer software. edit: typo
    • pjmlp 11y ago
      Java programmers also know a thing or two about java.util.concurrent, parallel streams, futures and Quasar. The only thing Go concurrency has over them is that it is easier to start with, but it isn't easier to use any other pattern, because Go doesn't allow library code to be first class in the type system.
      • brightball 11y ago
        Go also has much lower RAM overhead with that concurrency.
        • pjmlp 11y ago
          Assuming a JIT/AOT compiler that doesn't do escape analysis, which varies across JVM vendors. Also Go's advantage in using value types will vanish when Java finally gets to have them, although we still need to wait for Java 10 for them, while Go is available now. So Go does have a few more years to gain developer mindshare. Still Java isn't the only game in town, and there are other alternatives with GC, value types, more expressive type systems and battle tested concurrency frameworks.
  • dgacmu 11y ago
    There is - Go is a terribly fun language in the domains that it's good at. Like some other fun languages, if you take the time to get into 'the go way' of doing things, you'll get a new perspective on some kinds of programming that'll help you in general. Go is drastically less bloated than Java. Stupidly fast compilation and running lets you use it almost (but not quite) like you might Python for some things. A recent example for me: Writing a quick & dirty server that talked to a device that was spouting a stupid binary serial-over-TCP protocol. Goroutines made handling the bidirectional communication trivial, and go being a bit on the low-level side makes it easy to cope with binary protocols without worrying that your chars and bytes and unicode characters are getting all mixed up. You can do all this in Java - but it's so clean in Go. My current playbook looks something like: Network servers: Go. Go go go and more go. Things that talk to lots of other things and involve interesting communication are a natural match. I rewrote my pi searcher in Go a year or so ago, for example - http://da-data.blogspot.com/2013/05/improving-pi-searchers-speed-by-moving.html http://da-data.blogspot.com/2013/05/improving-pi-searchers-s... - and this year was able to run the thing through Pi day on only a single (larger) AWS instance. Woot. We use it for research, such as writing Paxos derivates. Great stuff. Go's also pretty amazing for little utilities if you want them to be faster than Python -- particularly if you want the launch time to be faster than Python. Which can be great for utilities you build to use in loops in shell scripts, etc. The fact that they're purely statically linked makes a lot of otherwise hairy cross-platform nastiness just go away. The fact that it's statically typed and includes great, easy-to-use parsing support for itself also makes it much better for refactoring than Python is. The tools aren't as mature as those for Java, but the language is well-designed to support it (think "go fix" -- which can automatically port forward much old code to newer versions of the language). The tooling for this kind of thing is great for Java, good for C and Go, and absolutely horrible for Python. As a consequence, Go can more roubustly handle being worked on in very large codebases and teams. What would be a slightly scary regexp replace in Python can be a much more syntactically and semantically safe change in Go (at the cost of a little more writing of the replacement code). Tensorflow (and most things numeric): Python. Because it was pre-decided. :) But, more seriously, Go's lack of generics hurt it here (you can't express matrix/tensor manipulation natively, and saying A * x is about as right as it gets when you're talking math). The ML community has adopted Python to a pretty strong degree, particularly because of NumPy, and so it fits in really well there. I still get grumpy about it -- I've lost count of the number of times I've messed things up that static checking could have caught, requiring quite a long time for tests/running it to finally do so. But I do like Python, to the point of: Beginners: Python. I pushed hard to switch CMU's intro course for non-majors to it, and succeeded with a lot of help from others. It's awesome seeing what a bunch of motivated, smart first-years can accomplish in Python in one semester. Damn. And they can 'take it with them' -- scientists/engineers and numpy are a pretty good match, for example. Fast as hell: C++, light on the ++, heavy on the C. A lot of our research code is very low-level. I'm still finding Rust incredibly annoying, but I may just be a slow learner, and it's on my list to take a really serious look at it after I'm back from Google. (You'll note that nothing that I do involves a UI. I'm a unix & systems person through and through, which helps explain the utter lack of Java, C#, Swift, etc. in my life.)
  • beefsack 11y ago
    I actually find web applications a fairly weak use case for Go, it's never incredibly pleasant to do. Network services in general are very compelling, mainly because of the strong standard library.
    • out_of_protocol 11y ago
      I'm totally ok with building services and cli tools using Go but it's not gonna work for web apps - situation is dire and that's ideological position - i.e. don't expect changes there :/ Basically DIY everything outside standard library ( e.g. section 9.1 building CSRF) Personally switched to http://www.phoenixframework.org/ http://www.phoenixframework.org/ for json apis/web apps
  • buro9 11y ago
    I write in Go, and for me it is the sweet spot between all that you've said and only required a single language and a single tool chain. There is little more to it than that.
  • wfsfw4w44 11y ago
    Since go is a compiled language, you get the benefit on zero startup cost, which you pay when using JVM or NET, or even Python.
    • pjmlp 11y ago
      > which you pay when using JVM or NET Except Java and NET developers worth their salt are aware of ways to AOT compile their code to native, thus enjoying the same startup time as Go.
      • jjnoakes 11y ago
        Is there a non commercial cross-platfornlm way to aot compile Java?
        • pjmlp 11y ago
          There used to exist GCJ, but its development died when the main developers joined OpenJDK development or moved elsewhere, back in 2009. There is still the RoboVM version before it got acquired by Xamarin. There are also Avian and JikesRVM, but it depends a bit what features you are using. The problem with Java non-comercial AOT compilers is that the majority of the Java shops that really care about AOT compilation don't mind to pay for it, so there isn't a real effort to invest on a free AOT compiler. The lack of community support for RoboVM was a good example of it. Even the upcoming AOT compiler in the official JDK will be a commercial feature, at least it was announced as such.
      • jjnoakes 11y ago
        Is there a non commercial cross-platfornlm way to aot compile Java?
  • twic 11y ago
    If you (and your team, if applicable) already know that set of languages, then there's no reason for you to learn Go. Indeed, if you already know Java, the only reason to learn Go would be if you had a burning need to produce self-contained statically linked binaries. For example, at my company, we have a habit of producing command-line clients for our services, and Go is a good choice for that. Go has been most useful for people who know a dynamic language like Ruby or Python, but who are encountering problems where they need more performance, better concurrency, or stronger static guarantees. Go improves over dynamic languages in those respects, and it's pretty easy to learn, so it's a great addition to their toolbox.
    • ngrilly 11y ago
      > If you (and your team, if applicable) already know that set of languages, then there's no reason for you to learn Go. Google is the perfect counter-example to your argument. C++, Java and Python were the 3 main programming languages in use at Google, and despite that, they designed Go and started using it instead of C++/Java/Python in some projects. Go can be used instead of C++ when you need and can tolerate a garbage collector, and you don't need things like a custom memory allocator. Go can be used instead of Java when you need a native executable, statically linked (like you wrote), when you need a better control over memory layout (especially to reduce pressure on the garbage collector), and when you need async IO without callbacks/promises/futures.
      • FordPrefectAO 11y ago
        Well one reason [1] Google made go was because of how many junior engineers they had who couldn't be trusted with java/python/etc. Instead of letting them struggle, they created go as a more simple and easy to use language. [1]http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...
  • freyr 11y ago
    > Is there a compelling reason for me to even learn Go? ... Should I take the time to learn it? One thing to consider is that the language is purposefully small, and you can learn the basics very quickly. Spend a day with it, and you'll get a feel for the language syntax and maybe some exposure to the standard library. You'll have a sense then whether you want to pursue it further. So if you're curious, the compelling reason is that you can satisfy your curiosity without much effort, and that will ultimately be more satisfying than asking strangers to convince you one way or the other.
• tbiehn 11y ago
  The security section, specifically on encryption, is dangerously misleading. It really needs an overhaul. To start with - DES is broken, you cannot use it. It also totally blasts over important details like -not re-using the same IV- for AES. Really, it should be updated to use a better higher-level general purpose encrypt/decrypt library, which handles all the happy primitives in a way that you can't shoot yourself in the foot. As for 'base64' being a good encryption algorithm? All the nopes & I can't evens. The password stuff is pretty bad too. IDK, needs a re-write.
  • elithrar 11y ago
    A fix is unlikely—I raised an issue on this over a year ago and my recommendations were rebutted: https://github.com/astaxie/build-web-application-with-golang/issues/354 https://github.com/astaxie/build-web-application-with-golang... Web apps/services should use gorilla/sessions[1], securecookie[2], and Go's bcrypt/scrypt libs. [1]: http://www.gorillatoolkit.org/pkg/sessions http://www.gorillatoolkit.org/pkg/sessions [2]: http://www.gorillatoolkit.org/pkg/securecookie http://www.gorillatoolkit.org/pkg/securecookie
    • tbiehn 11y ago
      Interesting. Not sure why you'd keep them intact. What's the hip solution for keeping a session-scoped, server-side data store? Recently dove into that for Hapi.js, found out that many people encrypt these and stuff them into cookies, ASP style - with all the same patterns of fail. Also - the developers claim this is a feature (after all, you don't have to worry about load balancing or distributing your state information on the backend. sigh )
      • elithrar 11y ago
        gorilla/sessions (for which I became a maintainer last year) has Redis/BoltDB/Postgres/etc. backends: the cookie stores an opaque ID, and all the data is in the server side store (allowing you forced expiration, etc). Cookies are also supported, and everything is HMAC'ed at a minimum. You can optionally encrypt, but since you should only be transmitting over TLS, doing so can be redundant.
• nobullet 11y ago
  I would expect something like Go On Rails (no pun intended). That's where history repeats.
• deleted 11y ago
  [deleted]
• tuananh 11y ago
  Offtopic: Is there any decent Go boilerplate for building API?
  • mholt 11y ago
    net/http: https://golang.org/pkg/net/http https://golang.org/pkg/net/http I'm not trolling. It seriously is easy enough to crank out a basic web app in less than a hundred lines of code that runs very well with just the standard library.
    • staticint 11y ago
      While I completely agree that the standard library is all you need in quite a lot of cases, the parent seems to be asking from more of a "how do I structure my application" perspective. A tool that generates the boilerplate necessary to use the standard library effectively in a complete application. Not just http handlers, but think of the persistence layer, for example. The standard library does not assist much with the engineering aspect of the job.
      • tuananh 11y ago
        true. I have problem when it come to structuring the application so i want a boilerplate so that I can see what everybody has been doing.
  • dsies 11y ago
    As someone above already replied - net/http is enough to build something that's good enough. In addition, there is also: https://github.com/gorilla/mux https://github.com/gorilla/mux , which complements net/http very well.
• BinaryIdiot 11y ago
  This seems pretty good. Two huge red flags in my skimming: 1. The password storage section where it gives MD5 as an option. MD5 should never be an option, not even in a simple testing / prototype application. 2. It actually calls base64 encoding encryption / decryption. This is really dangerous and outright wrong. So if you ignore security related sections this guide overall seems good.
  • TheSwordsman 11y ago
    This comment thread indicates these issues were called-out and downplayed by the author: https://news.ycombinator.com/item?id=11372463 https://news.ycombinator.com/item?id=11372463
  • Vendan 11y ago
    Also, it talks about salting, but it's NOT a salt, or at least it's a horrible salt. A true salt should not be reused at all, it should be unique to each password hash. Generally you see something like '<storedhash> = salt + hash(salt + password)' so you can recover the salt automatically.
    • kyrra 11y ago
      A global salt for all your stores passwords at least prevents generic rainbow tables from being used against a stolen password database. Salts per password prevents the same password from having the same hash result in your database.
      • bschwindHN 11y ago
        There's really no reason to ever use a global salt, it's not like it's hard to generate a random one for each user. If you're already putting in the effort to use salts, might as well go all the way instead of saying "well it's better than nothing ¯\_(ツ)_/¯" (I'm not directing this at you in particular, just at anyone who intentionally takes half-measures when it comes to security)
        • 11y ago
• deleted 11y ago
  [deleted]
• deleted 11y ago
  [deleted]
• la6470 11y ago
  Awesome
• douche 11y ago
  I've got to be honest, when these language shootouts come up (and it feels like I've read a lot of them this week), it reminds me why I'm pretty happy working in C#. I've got great tooling, generally good libraries, a pretty decent core language, and generally, shit just works so I can get shit done. Is it super sexy, no. Does it win me Internet Geek Points™, no. It's pretty much still Windows-only, but fine, that's the world I live in. The foot-guns are relatively small-caliber, and I've learned enough to avoid pointing most of them. I can do OOP, I can do functional (maybe not super pure ivory-tower monad/ADT/pattern-matching sorcery, but whatever - still have F# on my todo-list...), I can write straight procedural code if I really wanted to. I've even got a REPL and can use it as a scripting language. Plus, I have generics :-)
  • johnny_reilly 11y ago
    I know what you mean :-) Incidentally the Windows-only days will one day be a memory: https://get.asp.net/ https://get.asp.net/
    • scruple 11y ago
      Yeah, well, I've been hearing the "one-day we'll be on Linux" claims long enough to grow tired and move on. Developing on Windows, after having had some experience developing in a Linux/Mac environment, feels like second class citizenry. That's without even talking about nuget, etc...
      • manigandham 11y ago
        .NET has been available on Linux for years via Mono (with various compatibility issues but it works). And the next official version with cross platform support already has a Go Live license which means Microsoft will support any production app. "one-day" is today.
        • scruple 11y ago
          What production application are you deploying in .NET on Linux today? edit/ I'm not letting you off this easily. Mono never really worked and never really had Microsoft's support. Where's the ecosystem?
• gy0857478 11y ago
  thanks for sharing
• bsaul 11y ago
  Sad to see things haven't changed much on the sql front. Many web apps don't care about performance for the language, since the cost of querying the db will be orders of magnitudes higher anyway. What they want is a simple one liner to persist object graphs into a DB, because 90% of the code will be glue code around insert from json, and select to json types of features ( i'm talking list & forms types of web apps, not the fancy video chat over webrtc demo). The fact that this books advertize "build your own orm" solution, with the one given not even able to select 1-many objects makes me really wonder how in the world one could recommend go for web apps. Ps: to get a benchmark on what is the current level of productivity expected today for enterprise-like web apps, just have a look at a loopback.io demo. Yes, it's node.js which sucks, but you have to admit that we're pretty far away from manually mapping result columns to struct properties.
• buro9 11y ago
  The lack of example code in the security section should be a worry to all. It isn't hard to prevent SQL injection if you use parameterized SQL statement rather than using string concat, and whilst examples of this are trivial they shouldn't be skipped. In the XSS section it mentions filtering and checking inputs, but does not mention sanitization and does not give any examples. In the aversion to use any non-standard package it also does not mention https://github.com/microcosm-cc/bluemonday https://github.com/microcosm-cc/bluemonday or anything similar (I am the author of bluemonday - a HTML sanitizer in the same vein as the OWASP Java HTML Sanitizer). There is some sample code, in the Filtering section, but this only demonstrates the use of a fixed range of inputs in determining a filter, and then a regexp to check the input matches a format. Beyond the security, where the theory is at least known even if a demonstration on how to implement it is lacking... the entire guide misses out on demonstrating templates to their fullest, and specifically using a map of functions to provide the equivalent of Django's TemplateTags. In fact, the missing link for most Go developers who are building web apps, and for those coming from outside Go, are template tags. Most Go devs I know (who seem more systems focused) don't even realise that this stuff exists: https://golang.org/src/text/template/examplefunc_test.go https://golang.org/src/text/template/examplefunc_test.go
  • brightball 11y ago
    Templates are definitely the most lacking aspect of Go in my experience. Templating exists and works but in my usage at least has felt very clunky. It could be that I just haven't come across any resources that do a good job of explaining their strengths. I see so many comments from people who seem genuinely excited about Go's built in templates that my assumption is always that I'm doing something very wrong.
    • buro9 11y ago
      They are woefully undocumented. Well, that perhaps isn't fair... fairer would be to say that there isn't an authoritative set of examples showing how people can achieve things similar to something like Django templating or Rails templating. It is actually fairly effortless to nest templates, extend them with custom functions, and all of the things one would need to do. Probably one of the best resources is Hugo: https://gohugo.io/templates/go-templates/ https://gohugo.io/templates/go-templates/ and the funcs (template tags) they ship. That isn't too bad at all, but the snippets and examples are so small that it's hard to really see what the value is and how it all glues together to create nice readable templates. Anyhow, the key place to look at template tags would be: 1. Hugo's source code for template funcs: https://github.com/spf13/hugo/blob/master/tpl/template_funcs.go https://github.com/spf13/hugo/blob/master/tpl/template_funcs... 2. Hugo's creation of the func map: https://github.com/spf13/hugo/blob/master/tpl/template_funcs.go#L1644 https://github.com/spf13/hugo/blob/master/tpl/template_funcs... 3. Hugo's documentation on the funcs: https://gohugo.io/templates/functions/ https://gohugo.io/templates/functions/ Those three things, viewed as one, should allow any Go dev to extend templates to do whatever you want them to do. Hugo have been very "functional" in their choice of template tags, but there's huge scope for new packages to deliver more aesthetic tags, or tags for localization, to humanise time and plurals, basically to provide a core resource of tags similar to https://docs.djangoproject.com/en/1.9/ref/templates/builtins/ https://docs.djangoproject.com/en/1.9/ref/templates/builtins... so that each dev doesn't implement their own.
• melle 11y ago
  This book is open source: https://github.com/astaxie/build-web-application-with-golang/tree/master/en https://github.com/astaxie/build-web-application-with-golang... To those with suggestions related to e.g. security pratices, step up and contribute!
  • brazzledazzle 11y ago
    If the author is rejecting security concerns (as noted elsewhere in the comments) there's not much point in offering help there right?
• rajeemcariazo 11y ago
  The author is the maker of Beego
• jayflux 11y ago
  Are people who are using Go (for web apps) using it with Apache or Nginx? Or is every go app just using a DIY server? I'm genuinely curious
  • chvid 11y ago
    That is a good question; I also wonder what a real world production environment looks like. A Go program listening directly to port 80 running as root? What about virtual hosting, https, load balancing and so on?
    • andreynering 11y ago
      Actually, you choose. I like to use https://caddyserver.com/ https://caddyserver.com/ as reverse proxy for the easy setup and buildin Let's Encrypt support. You can also use Apache or Ngixn if you want. But you can also bind directly to port 80 if it's a simple app.
  • Vendan 11y ago
    I wrote my own reverse proxy in Go to route stuff to other Go processes based on hostnames, and made it so I could listen to port 80 without root. At first, that was via `setcap 'cap_net_bind_service=+ep'`, but that was a little fragile, as I'd have to remember to do that on every recompile, so I switched to just listening to port 8080 and using iptables to forward 80 to that.
  • dejawu 11y ago
    Like Vendan, I run my Go webapps on port 8080 (so I don't need root) and then have a very simple HAProxy setup that forwards port 80 to port 8080. Then I write a simple service for my Go app so I can control it with systemctl.
• dsies 11y ago
  Another project that was posted on HN se months back: http://go-bootstrap.io/ http://go-bootstrap.io/ I think it serves as a good example of how one can use go for webapp development. With that said, after a year+ of writing go in my day to day job, I still gravitate towards dynamic languages for web application development and leave go for most systems programming tasks.
• joeblau 11y ago
  Over the previous few weeks, I've seen multiple projects including one internal project drop Go. There was the widely publicized story [1] where Dropbox was switching from Go to Rust. More recently one of our backend engineers who built a prototype in Go told us that they pulled all of the GoLang code out in favor of C++/Python citing a huge overhead (I don't remember if it's CPU or Memory footprint). I know a lot of people are touting the concurrency model, but I've seen so many technical analysis of unfavorable technical analysis of Go that I'm starting to question whether I should learn Go or invest my time learning something else? [1] - http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/ http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amaz...
  • IshKebab 11y ago
    While the concurrency model is nice (especially waiting on multiple channels - I haven't found a way to do that nicely in C++), I think there are other bigger advantages to Go: * The standard library is really nice. It has almost everything you want and it's written in a clean non-enterprisey way * It generates a single statically linked binary. Doing this is very difficult in most other languages. * It's really really easy to cross-compile. Again, often very difficult in other languages (you might even have to compile your own compiler). * It comes with a built in battle tested HTTP2 server, and a sane TLS library. * It's a very simple language so it is easy for beginners to pick up, and also easy to read other people's code. Don't underestimate the importance of this - there's nothing worse than writing something awesome in a language that your coworkers find difficult, and then perpetually having to support it. * The tooling is pretty good. * Performance is good, and they've done really good work on minimising GC pause lengths. Of course I wouldn't pretend there aren't downsides (cough generics), but they're mostly minor and certainly no worse than you'd have in any other system (C++/Python sounds like it would have more than its fair share of issues!). Edit: Aside from generics, my biggest complaint is the impossibility of RAII. It's too easy to forget to `close()` things. Most languages suffer from this though, and at least Go makes some attempt to improve matters with `defer`.
    • cm3 11y ago
      > it generates a single statically linked binary. Doing this is very difficult in most other languages. For AOT platforms it's difficult mostly due to glibc. e.g. on FreeBSD and Linux musl it's trivial to build fully static binaries. Otherwise all valid statements and Golang is an improvement over other mainstream languages. So here's some future items for improvement that would make it even better and well suited for wider use: * a nicer error handling mechanism, though this may be hard * dead code elimination. Golang's static binaries are huge compared to fully statically compiled executables for other languages. I suppose the new compiler passes and backend might provide a basis to solve this. * restore compile speed, which of course was mostly due to previously missing optimizations and simple compiler passes, which were added now and made it slower. Still the Wirth'ian language design allows for much faster compile times than C or C++.
• farslan 11y ago
  The vim section is obsolote. There is no `misc/vim` anymore.
• anderspetersson 11y ago
  What's the current state of web frameworks for Go? Is there something similar to Django or Rails out or in development?
  • wiremine 11y ago
    I can't speak to that, but I have seen a few Sinatra/Express like frameworks. I used Gin [1] for a production project and it held up well under load. [1] https://gin-gonic.github.io/gin/ https://gin-gonic.github.io/gin/
• sandra_saltlake 11y ago
  development time and performance that is only slightly slower to write than Python
• zaroth 11y ago
  There's so much good content here, but it's also very surprising how much of it is truly a "roll-your-own and hope you get it right" approach. If you have to write explicit code in each of your postbacks to check a CSRF token, it's going to happen that not all your posts will end up being protected. If you have to hand-build SQL queries, it's going to happen that you'll have injection vulnerabilities. If you are manually generating and signing cookies, and having to write explicit code to sign them and check signatures... These are all features that should be done in a core library which makes sure these things happen all the time, not just when you remember to, what, copy/paste the code into each of your functions to do it? There's the overall structure of the code, which seems like it would quickly devolve into chaos. Looking at Section 4.4 there's a 'login' function which handles rendering the GET as well as processing the POST just by if/else on r.Method. You wouldn't want to actually structure a code-base like this, right? Later on, they do show a 'Beego' based router, which seems a bit more sane, but I'm really not a fan of 'showing the wrong way first' as a learning tool. The particular techniques being used seem very home-grown and not particularly best practice. To prevent double-submit they add a hidden field with token=MD5(time.Now) and also save it to "a session cookie on the server side"? Not quite sure what that means, but I think it's trying to say save the token on the back-end linked to the session, and then verify a POST, from that page, on that session, has that token. And then presumably clean up the storage... The majority of which is not actually coded in the example, making it just a high level roadmap of what you could do, not a practical working starting point. But anyway, if your goal is to prevent multiple POSTs per GET, and you already have a transactional session state for the user, then you do it with a server-side counter, not a hidden field, and certainly not a "obfuscated" MD5(time.Now). Even if you have no session state, then the simple answer is to create session state, not to create another token which does exactly the same thing as session state, but in a completely insecure manor. So overall I have a ton of respect for the work that was put into this document, it tries to cover a lot of material and is very easy to read. But I think the details also matter and 1) I can't believe this is idiomatic Go for how to actually route and manage requests, and 2) the entire proposed tool-set for actual secure processing of Sessions, SQL, CSRF, XSS, etc. seems to be totally home-grown and not at all production ready.
• aryehof 11y ago
  I find Go to be a concise and productive language for computing infrastructure applications, but struggle to apply it to problems with complex domains in business and industry. For those, other languages like Java and C# that better support encapsulation and data/information hiding for the modeling of real-world concepts remain suited. I think the problem with a lot of language discussions is really about the need for many to find the "one true ring" that can be learned and applied everywhere. Instead, a polyglot approach surely is the best one?
• konart 11y ago
  Needs much of the proofreading. I'm arrays\slices part, and there are a couple of mistakes already Like // define a slice with 10 elements whose types are bytes var ar = [10]byte {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j'}