
Why Go solves so many problems for web developers - 0xmohit
http://ewanvalentine.io/why-go-solves-so-many-problems-for-web-developers/
======
dham
Last time I checked, the problems facing web developers were(in no particular
order):

Rendering HTML templates / JSON

Asset compilation / Cache busting

Caching

Sending Email

Previewing/Testing Email

Background Job queuing(with failure/retry/backoff)

Reliable and easy integration/feature testing

Connecting to database and modeling data

Authentication / Account signup / Confirmation / Forgot Password

Security

Payment handling

PDF / Invoice rendering

Deployment

Making pretty good money over here and how many ROFL scale GO routines I can
run never really came up.

¯\\_(ツ)_/¯

~~~
twic
Don't forget binding posted form data to a model, and then validating it. It
seems like 60% of my web development time is spent getting that right.

~~~
webjunkie
Gotta love Django's ModelForms

------
austerity
As someone who is fairly enthusiastic about Go and has implemented a few
livelihood-providing production systems in it I am baffled by the number of
people who keep trying to use it for application (and especially web
application) development.

I mean it does feel like superpower when applied to tasks you'd previously
have to use C for. But have you tried any of the modern web development
stacks? They are like a zillion times more productive. Hint: PHP is not one of
those.

I guess some people just can't get by without the iron hand of the compiler :)

~~~
coldtea
> _Hint: PHP is not one of those._

Hint, PHP is 100% one of those. The bad rap is either because of hipsterism or
for issues that have been long solved.

The rest of its warts are no worse than the kind of BS any language has -- in
fact before JS got in fashion the same things was said all the time for it too
(for its bizarro coercion rules, only fp arithmetic, bs scope rules etc).

~~~
untog
I agree, but if someone were starting a new project I'm not sure why I'd
recommend PHP over any other stack.

~~~
contingencies
Things I like about PHP: it's not perl, which it replaced for webdev. It's
very optimized, and people with fat budgets pay for that (eg. Facebook). It
connects to everything. Most of its (useful to webdev type situation)
libraries are more mature than the equivalents in other languages, because
more people have used them for longer. It had working unicode from the early
days. It runs everywhere. Loads of people know enough of it to be dangerous /
collaborate, and they tend to be numerous in the young/cheap hire pool. It's
pretty much web-oriented, but can do scripting fine as well. It has a
relatively stable configuration. Honestly, I think it's a very Unix-like
solution to webdev problems, because it lets you roll your own solution, stays
out of your way (unless requested), and encourages you to code in higher level
languages. Yes, a lot of the code out there is horrible. Yes, most people code
on frameworks which replace half the language with ugly hanging half-
implemented abstractions. Yes, the function name thing is a pain. But mostly,
really always almost mostly, it just works ... quite fast indeed, and
everywhere. Yay PHP!

~~~
singingfish
Ooh, please don't badmouth perl. Modern perl (e.g.
[https://pragprog.com/book/swperl/modern-perl-fourth-
edition](https://pragprog.com/book/swperl/modern-perl-fourth-edition) ) is a
much more sanely designed environment than modern php is.

~~~
contingencies
I originally wrote a long comment about how I've written CPAN modules and
worked professionally in perl but will never do it again, explaining why
technical betamax superiority was irrelevant because perl's users left before
it got its act together, but I think in hindsight a simpler summary would be
this: _grep 'man perldsc' ~/.bash_history|wc -l_

~~~
singingfish
each to their own. I'd like to do more stuff in other languages, but my perl
skills are in too high demand, and it's fun.

------
codecurve
It feels like the author made the jump straight from PHP to Go without
spending much time actually using Node or Ruby and he's subsequently shocked
at how much better modern languages are when contrasted to PHP.

Many of these "solved problems" have also been solved with the other
languages, albeit not always at the surface level. For Node specifically:

WebSockets -> SockJS, Socket/Engine.io

Concurrency -> Generator Functions

Testing -> import assert from 'assert' and npm test

Syntax -> Some great improvements with ES6 and solid styleguides (airbnb,
standard) + eslint as an autoformatter

The major win here for Go is that as a new platform it was designed with
simplicity in mind. These features are probably easier to pick up in Go than
any of the alternatives, which is great. However, don't make the mistake of
thinking that Go is the first language to solve these problems.

~~~
vegancap
Author here, I have used both Node and Ruby fairly extensibly. I think I
touched upon Ruby's performance issues in the post. That's why I don't
consider Ruby a solid solution. Also, as far as I'm aware, Ruby doesn't have
built in concurrency like Go does. Yes, Nodejs is _close_ to being concurrent,
but it really doesn't hold a candle to Go. Yes Node has socket.io, something
I've used a lot and love. But Go has all of those features natively.

~~~
pjmlp
What about Java and .NET stacks? They do everything that Go does and more.

We are also web developers on those stacks.

~~~
IshKebab
I don't know about .NET, but Java definitely suffers from the enterprise
verbosity problem (no it still hasn't gone away).

I mean, tell me the equivalent Java code to this:

    
    
        resp, err := http.Post("http://example.com/upload", "image/jpeg", &buf)
    

I think that would be about 20 lines in Java. You've got to make a
`HttpUrlConnection`, then call `setDoInput(true)` (or is that
`setDoOutput(true)`), wrap it in a `try`, etc. etc. etc.

Go's standard library is amazing.

~~~
pjmlp
> I think that would be about 20 lines in Java. You've got to make a
> `HttpUrlConnection`, then call `setDoInput(true)` (or is that
> `setDoOutput(true)`), wrap it in a `try`, etc. etc. etc.

Nothing prevents you to wrap those 20 lines in a generic method.

Also there are other options in Clojure, Scala, Kotlin, Groovy besides pure
JDK API calls. Here Scala style, easy to mimic in Java 8

    
    
        val result = http.postData("http://example.comupload").header("Content-Type", "image/jpeg").responseCode
    

> Go's standard library is amazing.

So amazing that is doesn't have proper database drivers for the SQL databases
that matter.

~~~
tinco
I recently rewrote one of our services in Go and there was a SQL interface in
the standard library with backends for all SQL databases that matter. I don't
remember if the backend we used (for PG) was from the community or the
standard library, but that's rather inconsequential.

~~~
pjmlp
For our customers that means Oracle, SQL Server, Informix, DB2,... from the
database vendors themselves.

Not community projects that kind of work.

------
mjw_byrne
I've done real-life web dev using PHP and using Go, and have dabbled with
Node. Thoughts:

1\. Go's strict, statically typed, thou-shalt-check-thy-errors approach is a
breath of fresh air. The compiler does a whole load of checking which can (and
therefore should) be automated, which in many other languages is left to the
developer. Go code tends to have the property that if it compiles, it probably
works as designed. I love this.

2\. IMHO it makes more sense to think of a web app as a server application one
of whose functions is to listen for and respond to HTTP requests. So, the
question I'd ask is "is this a good language for server programming, and how
easily can I make it speak HTTP?" In Go's case I've found the answers to be
"hell yes" and "very".

3\. The tooling is really nice. go fmt takes a whole load of pain away from
everyone (no more effort required to format code properly, the tab/space and
where-to-put-the-{ debates are solved decisively, reading other people's code
is made easier), the package management is lovely, statically-linked
executables are easy to move around and go doc encourages proper commenting.

4\. Really good performance.

5\. The biggest drawback I've seen with Go is verbosity - although a lot of
the time it turns out that my verbose Go code is checking errors properly and
my compact PHP code wasn't.

~~~
codygman
> The compiler does a whole load of checking which can (and therefore should)
> be automated, which in many other languages is left to the developer. Go
> code tends to have the property that if it compiles, it probably works as
> designed.

As someone who works with Go daily, these statements are both very untrue.
Claiming "if it compiles it works" applies to Go code makes my eye twitchy.

For instance, type assertions have no exhaustivity checker. Interface{} and
liberal usage of it throws type safety out the window.

> the package management is lovely,

Go doesn't have package management per SE, just vendoring.

~~~
mjw_byrne
I did fudge a little - "tends" and "probably". Of course compilation is not a
guarantee of correctness, I just find that it gets me most of the way there.
JavaScript, by comparison, feels like it's trying to give you rope to hang
yourself.

Maybe I'm abusing the term "package management". I'm talking about go get, the
way imports function, the cute private/public lowercase/uppercase mechanism,
the recently-added vendoring support etc.

------
onion2k
_I also found myself relying on a lot of third party vendors in order to do
some more complex tasks, such as queuing, web sockets etc. I found myself
using Pusher, RabbitMQ, Beanstalkd etc, etc.

This felt kind of wrong._

And yet it isn't wrong. Standing on the shoulders of giants who built, tested,
and optimised applications that do complex things far better than anything an
individual could ever do on their own is how you build scalable applications
that don't fall over.

~~~
wpietri
Although I don't deny that tanker trucks are pretty amazing feats of
engineering, sometimes I just want a glass of water. Instead of figuring out
how to purchase one, drive it, and park in my back yard, it's pretty nice if I
can just turn on a tap, fill a glass, and turn the tap off again. The tanker
truck isn't "wrong", but it sure is a lot to deal with.

------
Matt3o12_
One thing that always seemed pretty hard to do in Go was security.

Most companies will stop at SQL Injections but I consider defense against XSS,
and CSRF attacks just as important. And that is something Go does not excel at
because I have not found any framework that makes adding these features as
painless as possible. (I have only toyed with Go for the web so I might be
wrong).

Django (a python web-framework), on the other hand, is pretty good at these
things[1] because they require little to no extra work, so that junior
developers like me will get it right. That is the reason I would always go to
Python for web development instead of Go, although, I like Go just as much and
it is so much quicker.

I'd be interested to hear how the big projects migrate these kind of attacks
in Go.

[1]
[https://docs.djangoproject.com/en/1.9/topics/security/](https://docs.djangoproject.com/en/1.9/topics/security/)

~~~
masklinn
I may be mistaken, but I'm reasonably sure with respect to XSS (in HTML
templates anyway), the built-in html/template autoescapes provided parameters
by default, much as Django templates do.

You have to mark "trusted" or "pre-escaped" parameters explicitly by wrapping
them in e.g. `template.HTML`.

------
jmspring
The post does nothing to compare and contrast approaches -- "In PHP I will
need to do X", show X, the post doesn't.

Seems to be upvoted because #Go.

~~~
hdra
Exactly! Many of the things mentioned in the post aren't really helpful in
building a web app from scratch. In fact, Go simply presents way too much
overhead for building a webapp from scratch.

I see Go as an optimization tool when concurrency is needed, the same way I
would consider using it to break some part of the app when it gets way too
big. It works very well for those purposes. But I would never consider Go for
building a web app from scratch.

------
merb
I'm still not get the go rant. I mean it's not bad, but it's not great either.
Programming in Java8 could be way easier than with go and has a better
Concurrency model (CompletionStage), it sometimes could be overly verbose
however that's not always a problem.

Go is just good for some things, not for all.

------
m00dy
Is it only me who thinks that parsing JSON is a totally pain in Go ?

~~~
bostik
Not total pain, but certainly loses in convenience to python. Deserializing
large and arbitrary JSON inputs is trivial with python's `json.loads()`.
Element access rules have no dark corners (as long as you don't have pickled
data in there).

In contrast, Go and its `json.Unmarshal()` aren't that well suited for parsing
arbitrary and/or complex inputs. However, if the expected input is well formed
and can be directly mapped to a predefined datastructure, the convenience
factor is pretty high.

So, from my limited experience, I would say that JSON parsing in golang is
more geared towards deserialising well defined transport formats than
ingesting arbitrary inputs.

~~~
lowmagnet
> In contrast, Go and its `json.Unmarshal()` aren't that well suited for
> parsing arbitrary and/or complex inputs. However, if the expected input is
> well formed and can be directly mapped to a predefined datastructure, the
> convenience factor is pretty high.

I think go revolves more around well-defined structures, and JSON is anything
but. For inter-process pipelines, protobuf (polyglot) and gob (go-only) work
better in my experience.

------
w84t1me
It includes the magic upvote string in the title: "Go". The content is
irrelevant, as long as it's positive.

~~~
vegancap
Author here, what were your issues with the content? Apologies for any
mistakes etc. Still getting to grips with the depths of the language.

~~~
w84t1me
My comment was more about Go posts on HN being upvoted like crazy whenever
they appear rather than any specific issue with your post. It's like a magic
recipe for upvotes around here.

~~~
vegancap
I was taken aback to see my post on front page HN to be fair! Considering it
was just a brief opinion post haha

------
eljimmy
I have spent a lot of time working with PHP and have also recently started
using Go. The comparison between the two in this article seems shallow and
kinda comes across as simply jumping on the PHP-bashing bandwagon.

Good on him for learning a new language, I guess.

------
pjmlp
Correction, web developers that never used Java, C#, Scala, Clojure, F#,
VB.NET, Haskell, OCaml, Erlang, or even languages like Ada or Delphi.

------
smt88
tl;dr Someone who doesn't understand his tools chooses PHP, and then he tries
Go and likes it. But he still doesn't understand his tools. For examples, he
"likes the idea of" typing, but never explains why (or why not) others should
feel the same way.

------
romanovcode
As a guy who writes web stuff in C# - Go solves absolutely 0 of my problems.
In fact it introduces problems rather than solves them.

Go is excellent but using it for webdev is stupid, sorry.

------
worg
"Or you can use channels, if you need a little more control." that means the
guy doesn't even understand the `share memory by communicating` model of go

~~~
vegancap
Author here, as I mentioned in the post I'm fairly new to Go still, so some of
the edicts are unfamiliar to me. So apologies for any mistakes. This post was
very much a 'why I really like Go over PHP these days'.

------
vegancap
Author here, thanks for all your (albeit brutal) feedback :)

------
agentultra
Golang doesn't solve any problems for web developers. Libraries solve problems
for web developers that web developers have. There are libraries to solve web
developer problems in every language used to write web applications. The
quality of those libraries and what they let you get done is what matters.

Golang solves the problems of moving bytes from one place to another with
certain semantics and guarantees.

------
bsaul
What about DB (sql) access ? The 90% user case for any webservice today is :

\- parse request (ok)

\- issue a serie of DB requests <\-- GO PAIN POINT

\- serialize result into either HTML (ok) or Json <\-- PAIN POINT

I'd say 2 pain points out of 3 is pretty bad IMHO.

I would recommend go only for very specialized and technical web services,
such as a websocket server. But really not for the average web developer task.

~~~
MoOmer
Where are the pain points in DB requests or serialization? I've written
several web apps with Go, and lots of ETL, and have yet to feel those as pain
points.

~~~
bsaul
Golang has nothing close to sqlalchemy, linq, activerecord or hibernate when
it comes de querying a database. Last time i used go i had to write every
single query and bind them manually to records in both ways.

For writing simple api endpoints, this is really not up to today's standards.

~~~
MoOmer
Well, for one, ORM doesn't quite fit Go's philosophy, but there do exist some
attempts to do this.

For me, it's a non-issue, as it doesn't feel right with Go.

------
digitalpacman
Sounds more like a "PHP isn't fun" post than about go. You ever try C#?

~~~
egeozcan
Exactly. I really think so many people happy with go would be way happier with
C#. I see one of the reasons people don't adopt C# is "because Microsoft",
which is sad, because it's such a great language.

~~~
baconizer
more and more clients specifically required Linux at the start of
conversation, this ruled out C# despite our 10+ years of experiences on MS
products in our industry. (also ruled out Mono, we decided to transform and
adapt and there are far better choices)

~~~
pjmlp
There is always Java instead of .NET, with several possible languages as
option.

------
cies
Go is as great for concurrency as Node.js: it forces one particular type of
concurrent programming on the programmer, which IMHO does not qualify as
"great".

Many languages give the programmer a range of options when it comes to
concurrency, including the options Go and Node.js offer. Some languages even
allow these options to be implemented as libraries (so they do not have to be
built-into the language; though can become part of the standard lib).

------
chalgo
No mention of the pain actually setting up PHP web servers? Knowing how to
tune apache/nginx fcgi etc?

~~~
vegancap
Good point! I'll add that in, seems an obvious one to forget. I've been using
nginx to load balance Go api's, so I guess I was still using nginx.

------
vasilakisfil
Have you looked at Elixir?

------
harryf
> In PHP I'd have had to use either some thread execution hack, delegating a
> task to a new thread using shell_exec()

That's not a thread, that's a child process. Very different model of
concurrency...

------
omaranto
The title is strange: the article is actually about _how_ Go solves problems
for web developers, not about _why_.

~~~
vegancap
Sorry, shitty grammar. I've changed it now, good spot!

------
lightyrs
This was one of the more accessible Go articles I've found through hn but it
would really help me if these types of examples included well-written
implementations in other languages and frameworks (including third-party
library implementations, if required). Does anyone have a link to an article
or tutorial like that?

Thanks.

------
girishso
The real pain for me to share variables from different handlers in the chain
(middlewares). I know some frameworks and libraries provide "contexts", but
it's something that should have been part of the standard library.

------
wtbob
I sure wish Go would solve the problem of blogs which hide content unless
JavaScript is enabled …

Seriously, why is this even a thing? Why gratuitously prevent Firefox +
NoScript from working?

------
muloka
What about Lapis and Moonscript for web development?

~~~
jasonm23
I like Moonscript and Lapis seems decent enough, but the community is still
microscopic.

