Hacker News new | comments | show | ask | jobs | submit login
Web Development in Go (inburke.com)
139 points by kevinburke 166 days ago | hide | past | web | 102 comments | favorite



>Compared with Ruby, PHP, Python, or Javascript, you're going to get great memory and latency performance, and libraries that do what you expect.

Isn't picking a language to solve memory/latency issues a pre-optimization? Also I'm not sure if one can argue that libraries from one particular language are better at doing what you expect than libraries from another language.

Disclaimer: I'm trying to understand how much of what people are saying about Go is hype. People are telling me things like you can cross-compile on different platforms and output a binary, but I fail to see how these things are important for most API's and web apps.


I've written about this [1], but in brief, my opinion is that selecting a high-performance platform is extremely reasonable, all else being equal (equal familiarity with Go and Ruby, for example). Opting for a high-performance platform allows you the freedom to build your application code in a genuinely low-friction deferred-optimization manner.

Put another way, a high-performance platform provides a very high ceiling, allowing your application to be more brute-force with its implementation. You don't have to be sub-consciously worrying about performance gotchas while implementing your code because a high-performance platform gives you freedom to be inefficient within your application domain.

Not only that, a high-performance platform postpones your first scale event, and in some cases indefinitely defers it. I've found that applications on high-performance platforms tend to be easier to deal with on a day-to-day basis because they do not collect the various deployment performance-oriented cruft that you typically see with low-performance systems. High-performance platforms have simpler system architecture (fewer external processes, less monitoring overhead, etc.)

A bonus is that the user experience will be just that much better thanks to low-latency responses.

[1] https://www.techempower.com/blog/2016/02/10/think-about-perf...


Development performance is arguably more important. Developers are way more expensive than servers.

You shrug off the established players but all else is very much not equal. Until Go has its own mature Django or WordPress projects, you're spending a lot more time reimplementing the wheel.


One of the main beautiful things about Golang is that the community prefers libraries to frameworks. There may well be a MVC framework developed in/for Golang, but it probably won't be used that much by Golang devs.

A framework gets you going real quick, but at some point, probably 3-6 months in, you'll need to do something that the framework doesn't like. At that point the framework suddenly becomes a hindrance rather than a help. You spend more and more time fighting the framework and writing more and more code that lives outside the framework. After a few years you've wasted way more time than you ever gained from using the framework.

Libraries are built to provide capabilities to your code. Until you've experienced a good standard library (like Golang's) then this makes no sense. It's common for newbies to Golang (like I did) to try and create supersets of the libraries and create their own framework. But every new project comes back to the simplicity and ease of using the standard library.

I like the OP's approach of having repos full of useful middleware and handlers. This makes much, much more sense for Golang development than a Django clone.

Try it, you'll like it.


Your description of frameworks' opinions and limitations limiting development has just never —after years of development— really applied to Django. Much of it is configurable or even interchangeable, and it continues to receive serious improvements on a regular basis.

The fact Django is batteries-included, and everything is well documented in a single place, developers aren't wasting time working out what they can or should use for URL routing or handling database connections.

So no, I stick by my comment. A good framework saves time by being easier to learn, creating a more homogeneous product that is easier for other <framework>-developers to pick up, not forcing developers to form opinions about architecture they just need to work.


PHP, Nodejs, Go are languages and have communities that prefer libraries (not exclusively). First it needs a language with batteries included, so the language offers already so many features out of the box.

It's great not to have to worry about frameworks, that often last just for a few years, than you have to rewrite or migrate to a newer partly incompatible version.


YMMV. In my experience, developers are equally productive (and in many cases, more productive) on high-performance platforms for a variety of reasons. These include the aforementioned reduced friction of avoiding subconscious performance debt, the increased productivity of a typing system (many high-performance platforms have stronger typing systems), and the reduced mental burden of a simplified system architecture.

Yes, some platforms (e.g., WordPress) give you certain functionality off the shelf, but if your application isn't a CMS or blog, then the utility of that functionality is low. When building a custom REST or REST-like server for an application, a CMS platform isn't necessarily a reasonable starting point.

As with anything in technology, many variables need to be evaluated to make a decision. My point here is that performance is a consideration—more significant and valuable than many people understand—and it at least somewhat objective. Developer productivity is more difficult to objectively measure and varies by team on matters such as previous experience.


The same argument can be made about C/C++, Java and Rust. These languages are even more performant than Go in general. Why not choose them? Why Go?


For C/C++, don't use a memory-unsafe language to speak to networks. (The fact that so many things already do is no excuse and adequate demonstration of why. Also arguably more true of C than C++ but I'm not particularly impressed with claims that C++ is safe if you just "do it right" because that's the sort of gap you can drive a truck through.) Rust is still a bit shy of web libraries, and may be overkill for some use cases, but otherwise, go for it. Go for it with Java too.

However, the performance gap between Go and Rust is much smaller than the gap between Go and a dynamically-typed language, even one JIT'ed to the n'th degree, and the gap between Go and Java generally lost in the noise [1]. Between Go, Java, and Rust, you've probably got a good case that you'll get to more-or-less production-ready code fastest in Go. (And yes, "more-or-less" is a gap big enough to drive a truck through too. I preemptively pretty much agree with everything anybody might care to write about that issue in reply. :) )

[1]: I suppose I should point out that a perf gap of 2 or 3 is "generally lost in the noise". In the real world what tends to control which such language has the better implementation of something for most tasks is who has taken more time to write an optimized version. It's when you start getting up to the 10x-25x range that the gap between Go and a dynamic language can be that it's not really "lost in the noise" anymore; in that case, the faster language can end up simply faster than the slow language even if the slow language is given a lot of extra love (assuming no "change to a different language" shenanigans).


To be clear, I am not suggesting Go specifically, although it is certainly a very good choice and the article this thread is linked to makes its own good arguments in favor of Go. Java 8 also has some very high-productivity modern web application frameworks, as do several other high-performance platforms. I generally advise selecting anything within the top third—what I loosely call the high-performance tier—of our benchmarks project. There are a bunch of options there, Go included.

Making a platform selection that is informed, in part, on the language/platform's performance is a reasonable thing to do. As long as you can be equally productive (or even if you are a little less productive) with a high-performance platform, you will likely endure less pain during the initial several months once your system goes live and considerably less pain over the long haul.

Plus, it's really great to have a wicked-fast web app with very little performance-tuning effort.


Because Go is a fast, fun and productive language. It is important to have all the three :-)


TL;DR; Go promisses interpreted language developer productivity with C-like performance of the code and it delivers.

Longer version:

- I've been writing almost exclusively Go code as my full time job for the last 2.5 years

- I've coded in Python and PHP full time before - each at least as long as Go (and neither of them was my first or second programming language)

- I was able to pick up Go significantly faster than either of the two (0 to push to production in less than 2 weeks)

- I'm at least as productive (measured in problems solved / features delivered in unit of time) in Go as I was in Python

- standard library is great and very often replaces the need for 3rd party libraries (performant, production ready HTTP server for example) and makes dependencies "flatter"

- deployment of a single static binary vs virtualenv hell (pre-docker) is bliss

- it's actually very fast for free - you'll start worrying about (and start spending time on) performance way later

Negatives: - dependency management is bad

From web app/api perspective:

- just using http server from standard library gives you concurency go is known for - each request is a goroutine which is cheap: minimal overhead

- you can delay worring about performance (at least from the app part - not db obviously) more. It's easier to throw hardware at the problem when you need 1/10 of the hardware

- deployment is easy - single static binary that just works

- multiple CPU cores are simply used: you don't have to run multiple processes (node)

- http server in standard library is production ready: no need to stick it behind something else

- you get all that without sacrificing productivity


I've had a bit of exposure to it (writing some HTTPS audit tool using Go\Crypto & some third party library - from CloudFlare) and I agree mostly, what struck me as a guy with 10+ years of PHP background is the speed at which I got the first versions of my tool out, really impressive. Definitely keen to may be transition to it if I can find stuff to do to better my knowledge of it.

Have you found a decent way to deal with the dependency management, I found it a bit clunky...


Govendor + vendored dependencies in repo


Godep is also fine, no real issues with dependencies here.


I've ran into some pretty gnarly issues vendoring both helm and Kubernetes in the same project. Your luck really depends on the dependency graph for the stuff you are vendoring.


Ah yes. Vendoring things that themselves vendor other libraries gets very hairy.


Probably an unpopular opinion but I don't think pre-optimization is a bad thing specially in use cases where you will need to optimize the application later, as refactoring things for optimization later is much more time consuming.

That being said, it all depends on the use case. And about your point on binary output, its not just about being able to get one binary and running it in different platforms, its also about being able to run it without much setup in the future. For example, I had a hard time getting a nodejs app that I built a few years ago running again since so many libraries were deprecated and I had a lot of broken packages, but if it was built using Go, it would just be one binary with all the dependencies packaged in and I would be able to run it without any issues.


Does GO have a dependency manager yet? last time i checked it out it was only things like go get which did a git checkout? I doubt anything would keep working on active libraries without version locking composer / yarn seem to do this a lot better.


I am not sure about the situation of dependency management on Go atm (havent used it for a few months), but in my case if I had a pre-compiled binary, I could just fire it up without having to worry about compiling from source. I was not a big fan of the way Go handled dependency a while ago, but I am sure there are better tools out there now.


dep is being adopted as the officially "blessed" tool of choice.


Yes, not really an official solution yet, but they're getting there.


It will be in 1.10. Details and roadmap: https://github.com/golang/dep/wiki/Roadmap


I think people have come to interpret the pre-optimization mantra in different ways, which leads to some confusion.

Personally I think it's fine to have optimization goals, particularly around things like performance, cost and security (or even your ability to hire engineers). Maybe you park some of them while you prove another point, but you can (and should) measure and adapt along the way.


this is why i only use pure JS in nodejs. then it will always work for that version of nodejs. you cant asume that binary version of nodejs will work forever though.


I'd say that it's a pre-optimization if you're debating between python and c++. Namely, expressiveness vs performance. In the case of go, a lot of people feel like it gives you about the same amount of expressiveness, while also giving a shit ton of performance. So, in this case, I wouldn't say it's a pre-optimization. It's just being smart about the tool you select to solve the problem at hand.


> Isn't picking a language to solve memory/latency issues a pre-optimization?

Yes it is, but if there are no perceived downsides then it's no biggie. I.e. Go is well supported by tooling, it has a good and growing open source ecosystem, it appears to support a level of day-to-day developer productivity comparable to other high-level languages, and so on.

In other words, the hidden corollary to the standard "premature optimization" meme is that optimization always has negative side effects (such as complex or difficult to maintain code). But sometimes, these negative side effects can be negligible and choosing a particular language over another is often one of those times.


You mean premature-optimization?

That depends on the outcome. Would you call using C++ for developing a videogame as premature? Or just picking the right platform up front to meet the goals?

Performance, especially efficiency, is way too often overlooked these days, and provides incredible benefits both for your own development, operations and end user experiences.


Not really.. Picking the right language in my opinion is very vital based on your use case. Especially if memory / latency and throughput are very important for what you are building.

For my project after a month in golang, I had to switch to C to avoid the GC pause. It also gave me total control over memory and made best use of CPU.

Will I choose C for every project ?, definitely not but based on what you are building, it is good to make that choice early on in the project.


Shipping self-hosted APIs is painless with Go thanks to how easy it is to cross-compile. Especially if your customers are enterprise and run Windows internally.

Previously, we had to ship virtual appliances to our customers which then involved debugging their wacky network setups, their wacky version of VMWare etc. etc. Now it's just one liner build, upload to s3, send out a link, done.


"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"

I'd say picking a platform is not, as it is definitely a critical part of your program, especially if it does not greatly increase the complexity of your code.


There are a lot of studies correlating response time with e.g. the percentage of users that complete an online checkout.


Theres lots of reasons to use Go. Mine is the language is really stupid simple.

Theres nothing fancy in the syntax, you can pick up a project you put down months ago and easily start working on it again


I personally prefer whatever language/framework gets value out the door quickest on the side of handling HTTP requests (e.g. rails or laravel for the front-facing items) and something like Golang for plumbing or work that requires speed/CPU optimization - queue workers, file manipulation, data streaming, whatever.

Golang (and NodeJS) both feel really kludgy to me when getting into things like handling form submissions (validating input, redirecting with error/success messages, and all those tedious things that the popular frameworks abstract away the best they can).


This. After using Go, Nodejs (Express, Koa), PHP (Laravel), Java (Spring) and C# (Asp.Net Core), I realized that nothing beats me in productivity when I am using Spring or Asp.Net core when building a web app. Little things like form validation, route management, templating and a ton of little under the hood stuff are much much easier with older frameworks that have been around for a while.


Try Elixir + Phoenix ;) All the little things you've mentioned plus more (like good asset management out of box, super easy to use channels, migrations, clustering, deep system inspection etc)


Can you expand on how Spring or Asp.Net are better than Laravel with respect to form validation, route management and templating which are generally regarded as PHP's fote?


Laravel actually was great at form validation, route management and templating, probably one of the best, however performance is what made me move away from Laravel. With Spring and Asp.net Core, I got the best overall development experience compared to the other ones I mentioned.


I think you have to use each tool for what it's for. Golang is useful for high performance stuff, yet it's easy enough to handle an HTTP request and parse JSON, for example.

Of course if you compare it with other options, you will find solutions that provide better expressiveness with less code (development speed), at expense of execution speed, type safety,...


I would say that while it is easy to parse json, it only remains easy if your json is straightforward and/or "well formed". If your json is... less well formed, you're going to have a much harder time parsing it with Go (and parsing it with good performance).


What do you mean by "well formed"?


I mean one which doesn't have many similar, but variable, content structures, and/or which depending on the attributes of one of the elements.

I had to deal with large volumes of json (think log streams) that while they shared many top level attributes, also had had accreted many "optional" components with "types" that depended on the values of certain attributes (each with different nested elements too). While awkward to deal with in python (lots of `if x in y['thing']` checks), this was very cumbersome to deal with in Go. It required lots of reflection and ended up being comparatively slow (python json parsing is actually pretty zippy).

It just isn't one of Go's stronger suits in my opinion.


OK. Interesting. One of the benefits of JSON is that it is ad-hoc extensible. Otherwise why not use an efficient binary format? When more strongly typed environments add JSON support they often screw this up, which is unfortunate.

Maybe an opportunity for someone to write another library to better support more idiomatic usage of JSON.


Yup. I agree with pretty much everything you said.


I've been doing Node for a while and wasn't sure if I should take some time to learn Rails, you've just helped me to decide to do so. Thanks.


NaCl's secretbox for encrypting the session cookie - nice


What's lacking in the HTTP library? The stock router isn't great, but it's pluggable. Also, serving static files has never been a problem http.StripPrefix("/tmp", http.FileServer(http.Dir("/tmp"))) (or something like that, I forget the details). I guess I didn't find it very hard to get into web development in Go with the standard library; I'm not sure there's enough friction to justify diving into third party libraries. :/


> serving static files has never been a problem

I address this in the post; there's no problem with it, but it requires that you (or your end users) come up with a solution for deploying static assets to production, figuring out the relative paths between the working directory and the asset directory, and ensuring that the right version of the binary loads the right version of the assets. An example of the type of difficulty here is that you couldn't remember how to do it off the top of your head.

If you compile them into the binary, you (or your users) don't have these problems.


I thought compiling them into the binary was a very clever idea!


I've always assumed that compiling assets into the binary meant the http.FileServer can't use sendfile. I guess this means lower performance at scale, but I've never verified if this actually happened or its effect.


When you serve files over https (which you always should) you can't use sendfile anyway. The data will have to be encrypted, so you can't have the kernel send the data straight into the socket.


I hadn't considered this before but it seems to make sense. If I have nginx configured with ssl and sendfile (X-Accel-Redirect) and my app sends an X-Accel-Redirect response to nginx, you're saying that it's not actually using sendfile under the hood?


Sendfile is just a kernel feature for directly sending a file to a socket. If you are doing literally anything other than just sending the raw bytes of the file over the network, it can't be used.


Yeah I'm aware that it's a system call that only knows about file descriptors. It's just that it just now hit me that a consequence of that is that a web server configured to use ssl _and_ sendfile isn't really using sendfile, short of some hairy hack of writing/encrypting the response into a file (maybe in-memory with something like memfd_create) and using sendfile on that, which would defeat the purpose of avoiding user-space entirely.


Looking at Linux’s sendfile [1], it should be possible to use it like that in principle (but not with the standard http.FileServer, I guess).

[1] http://man7.org/linux/man-pages/man2/sendfile.2.html


Ah, I misread. Thanks for clarifying.


What about templating, middlewares, security, authentication, authorization? Do I need to glue this from custom libraries to the web server myself every time I start a new project?


- there's a templating example in the project

- there are middleware examples in the blog post and in the project

- depends on what you mean by "sucurity". there's an example of secure cookie encryption in the blog post and the project

- depends on what sort of authentication or authorization you need. If you just need basic auth you can try https://godoc.org/github.com/kevinburke/handlers#BasicAuth


- ok, i did not look at example, sorry - for logging, but thats not enough - thanks for pointing out typo in an interesting way, yeah but blogpost just mentions custom library that should be glued to your webserver - custom library again glued to the server on every project

I would go for new projects with something different than go. Like scala. Go is great for rest apis, but once your app becomes more "complete" in terms of requirements go becomes more and more painful in my experience.


> I would go for new projects with something different than go.

You should probably write your own article then.


Is the flash message setup a standard way implement that type of functionality?? Encrypting the cookie with a key that is delivered client side anyway seems like it doesn't buy you anything.


The key isn't sent to the client.

You can set the flash message in plain text, but I'd rather avoid the possibility of tampering, and it lets me reuse the same cookie code I use to encrypt e.g. session tokens.


What kind of tampering are you thinking about here? Aren't those messages sent from the server to the client? Thus, in-transit tampering should be prevented by TLS.

If the key isn't sent to the client, how is the client supposed to display that message? Why are these messages encoded into a cookie in the first place? I don't think I understand the concept.


The message is read on the server as part of the next request and then displayed in the appropriate spot in thr UI


This kind of scheme is used by flask. If you have access to the cookies you can decrypt and read then but you can't change any of the content.


How good are the ORMs options in Go? One of the reasons Rails is my go-to for web development is how easy Active Record it makes configuration and changing databases.


We've started building Bugfender using GORM and it was good for the initial job, but we now decided to remove it completely and continue on a lower level.

We've summarized our whole experience with Go here: https://bugfender.com/one-year-using-go and we're just wrapping up another blog post with the Go pros and cons (from our point of view), which should be out soon as well.

The biggest problem with go is, that it is still a very fast and changing ecosystem. Which is great for a new language, but didn't serve us too well for building something stable.


In which universe is Go a part of a fast-changing ecosystem? It certainly isn't this one! The Go language abides a strict compatibility guarantee. Libraries, perhaps due to the poor dependency management situation, tend more than other language ecosystems to avoid breaking changes, or at least hide them behind different import paths. Go has arguably the least dynamic, most boring ecosystem among popular languages today!


Compared to Java or PHP? Or did you mean "trendy" rather than popular?


Yes, controlled for age, I think Go is even more static and boring than Java or PHP.


I don't know much about the Go ecosystem but this makes me want to try it. You can't really control for age though... how does it compare to Rust in terms of stability (a language of similar age and scope)?


Vastly vastly more stable. Incomparable; night and day.


I'm not a big fan of Active Record (https://kev.inburke.com/kevin/faster-correct-database-querie...) and tend to just write queries by hand. The benefit of this is you can Prepare them, which alerts you to syntax errors earlier and means the database doesn't have to parse the query each time you execute it.

You also don't need to return every column if you know you only need an email address.

I know people that have had success with gorm or sqlx.


Imho, not good. They feel like a hack.

It's the main reason i wouldn't use go for building a webapp that needs to discuss with a moderately large sql backend.


This weekend I played with the Buffalo framework [1] which includes "pop" [2] which an ORM of sorts.

I really enjoyed working with both. It's nowhere near as magical as Rails, but it totally reduced the amount of code/boilerplate I needed to set up databases, migrations and to get Go "model" structs to and from the database.

[1] http://gobuffalo.io/docs/getting-started

[2] https://github.com/markbates/pop


How many times have you changed databases in your production apps or are you building and selling software and wanting users to be able to pick their own database?


I don't think that is the only reason to use ORM's. They definitely help me be more productive while building apps where super-high performance is not an issue.


I really like the flexibility of being able to swap around dbs during initial development. At some point along the way once almost the whole major systems are working, I'll need to decide if I need FTS, sharding, to work on a shared host that already has MySQL / interact with a wordpress site, etc.


You are coming from the opposite side. Go is leaner, like Nodejs and PHP can be used without any frameworks as batteries are included.

Asking for ORM means you are comfortable in your framework world. You will have to adopt, if you want to go a leaner way, with direct SQL or NoSQL API. Or find an ORM library (but learn about pro/cons).


On the subject of Go web development, I'll plug one of my favorite libraries: https://goji.io. It's a super-fast HTTP router that supports middleware and pattern matching.


This is, IMHO, the PHP/Javascript problem showing up in Go.

All 3 languages have so much bundled in for web development out of the box that it's too easy to create frameworks...so there are lots of them without any type of rallying standard.

That's one of the reasons that I'm really averse to Go for web development that isn't just API based because you gain a lot from a complete, primary framework for web projects.

It's one of the things that makes Elixir so appealing because you've got a clear next-gen-web winner in Phoenix with a language that brings you so much of what's good about Go due to it's Erlang/BEAM underpinnings.


This +100. I'm not sure who, other than fanboys, would argue that Go is on par with other languages when it comes to building a standard web app. Just take html templating as an example. Go feels like a kludge when it comes to this.


What problems did you run into with templating in Go?


You're just looking at one set of trade-offs and mistaking it for the best.

Since people do not unanimously use large batteries-included frameworks, you must realize that some people prefer some batteries a la carte.

Rails and Phoenix may win the large framework space, but they certainly don't win the web space.


Never said it was the best, just that there are a lot of pain points that come from trying to use Go for a full stack development experience.

Command line, workers, network and api layers are GREAT. If you have something that needs a custom solution...great. But the experience around managing a polished view layer, assets, routing, middleware, sessions, routing, redirects, migrations, database access, etc can get fragmented and tedious when roll-your-own becomes the defacto mode of operation.

When a language doesn't have all of the web-native stuff built in by default (like PHP, JS and Go) the community around the language tends to organize around a framework experience that will eventually lead to a common development experience that people can further develop tooling around.

It's not a knock on Go itself, it's just something that creates a noticeable side effect in the community in terms of fragmentation. People clearly WANT frameworks, because they keep rebuilding them. Doesn't mean you always need one, but it does mean that having a "winner" could be good for the community.


And Go does? What does "win" mean in this case? Productivity....market share??? 'cause, um no.


Vestigo is another very good choice

https://github.com/husobee/vestigo


I used to use http://goji.io/, but once 1.8 hit and context was part of the request object there was little use for this library. Also, maybe it was just me, but I couldn't do very advance routing with goji. So I switched back to gorilla mux


Does go have any advantage over other compiled languages, like say, swift?

For example: https://vapor.codes


That's a question with a pretty broad answer. Each language has its own set of tradeoffs and things that it values most highly.

In particular Go is shaped by the experience of needing to run high-performance servers at a company with thousands of engineers; it was designed to address a lot of the problems with running C++ or Python in that environment.

Swift came from Apple, and was designed to address a lot of the problems with writing mobile apps in Objective-C.


>it was designed to address a lot of the problems with running C++ or Python in that environment.

Where have you heard/read the part about Python? Not saying you're wrong, just haven't heard of it. I had heard about the C++ part. I know of some general issues (e.g. static typing, perf), of course, but interested to know which ones Google had (with Python).

Edit: The issues I've read about with C++ at Google (in Rob Pike's article) were, IIRC, C++'s complexity and long build times, even with distributed builds.


I don't think Swift was designed to address the problems of writing mobile apps in Objective-C.

It seems more like a compiler/language developer's idea of what a good modern language should be.


http://carlosicaza.com/swiftbooks/SwiftLanguage.pdf

Swift was designed for writing apps on the mac platforms, primarily on iOS, and although somewhat debatable as a replacement for Objective-C due to it's quirks. If you want proof of that, just read between the lines in the original documentation.

Not to mention, many of the features that were called out originally are direct responses to issues with Objective-C: Optionals, Typed containers, Generics, modules, real first class functions instead of just blocks, final classes, let, etc.


>If you want proof of that, just read between the lines in the original documentation.

Those things were obviously requirements for roles it should fulfill.

But no things in its design hold it back from being a modern language that's even more expressive and fast than Go. Except some concurrency love perhaps.


There are roughly a million different compiled languages throughout the history of computing. Every one of them has some sort of advantage over other languages. And of course, there are plenty of interpreted languages too.

So the question is, what problem are you trying to solve? Does the language you choose address those problems effectively?


I don't keep up with Swift, but last I checked it didn't have a mature, lightweight concurrency story. Speaking generally, I find that Go is easy to write (like a scripting language), but with static typing. I'm also not familiar with another language that is as easy to get up and running with (Go projects don't require you to learn a new project configuration file language, for example--just run `go build` and you get a binary).


Can't speak for swift, but go is writing with asynchronous applications in mind.


go has very well established ecosystem to do low level networking in a very efficient manner. that is based on my experience. you can use go for different problems, but then tooling/libraries around that are not so great/stable. like gui programming for example, auido/video encoding/decoding.


> You should write your next web server in Go

Are people writing their own web servers these days? is that a thing? Seems like everyone uses nginx.


“Your own web server” here doesn’t mean “your own program that reads from sockets and parses HTTP” — that is taken care of by Go’s standard library.

“Your own web server” here means “your own program that serves HTTP requests”, and yes, people write programs like that all the time.


I read the post. The language is just confusing. You shouldn't have to tell me that "You should write your next web server in Go" doesn't mean what it says on the tin.

A web server is Apache, Nginx, Lighttpd, etc. What you just described is a Web Application, which I develop all the time on python -> uwsgi -> nginx stack.

For the record, I'm not blaming you, but the author for the confusing language. The title says "Web Development in Go" -- web dev is traditionally web applications/html/css etc, not typically including servers. Then their opening sentence is "You should write your next web SERVER in Go"

/pedant


I don't think the language is the slightest bit confusing. I also think your definition of "web server" is wrong. I would say a web server is a program that processes HTTP requests and optionally responds with something (commonly HTML, but can respond with data of any format).

That includes apache, nginx, etc. It also includes programs written in X language that process HTTP requests.




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: