
Re: Moving from PHP to Go and Back Again - neoasterisk
http://blog.breakthru.solutions/re-moving-from-php-to-go-and-back-again/
======
throwaway2016a
Some background. I actually wrote a semi-popular book on PHP (published by a
major publisher) and have contributed to the core project. And I have spoken
at many PHP conferences. Perhaps tellingly, PHP is rarely my first choice
anymore. Which I think it a great language (contrary to many opinions) I just
find other languages a better choice.

Today my language usage looks like this:

\- Web services / APIs: Node.js [1]

\- Front-ends that require easily modifiable templates and quick command line
scripts: PHP [2]

\- When I need speed and low latency for a network connected app: Go [3]

\- When I need speed on an app that requires no network: C

[1] The promise chain asynchronous nature of Node.js makes it great for web
services in my opinion. And the ability to easily have global variables that
persist across connections for things like caching and pooling is a huge plus
over PHP.

[2] PHP is very good at spitting out HTML and making web service requests, the
performance is acceptable in most cases, and it is really easy for most people
to edit, even people without a CS background. Likewise, for quick command like
scripts PHP is unbeatable in my opinion. The tools it provides out of the box
means most common command line tasks can be done 100% with the standard
library. No package manager required. Though if you need to add packages PHP
is pretty good about that now. Incidentally the fact the standard lib does so
much is also one of PHP weaknesses. The standard library is a mess of
inconsistently named functions and classes that grew organically over 20
years.

[3] I've saturated my loopback network interface on a non-trivial app on my
Macbook Pro using Go. PHP and node don't even come remotely close.

~~~
chj
in latest nodejs there is no a single place to catch exceptions in promise
chain, which is very inconvenient.

~~~
Xeoncross
Not sure what you are talking about:

    
    
        Promise.resolve().then(() => Promise.resolve().then(() => {throw new Error('Problem')})).catch((e) => console.log(e.message));

------
robryan
> These are hard issues to solve with PHP, so hard that Facebook hand crafted
> a SPECIALIZED VIRTUAL FREAKIN’ MACHINE to deal with the performance issues
> inherent in PHP. Does that really seem like an “easy” solution?

It is worth noting that this was pre-PHP7. Post-PHP7 the out of the box
performance is similar or better to what Facebook did with the HHVM.

~~~
mschuster91
Also, very few projects will ever end up at the scale (user base/metrics) that
Facebook had.

99% of all PHP software will be fine with a quadcore server with 4GB RAM,
running a LAMP stack. This can be scaled as needed (eg moving off mysql,
adding a reverse proxy, real load balancing).

~~~
j0rd
I've always been really skeptical of those language performance comparisons
which refer to PHP.

As stated above PHP7 has similar performance when compared to HHVM which was
made by Facebook. Additionally PHP has an amazing performance debugger by FB
called xhprof.

PHP performance could always be increased hugely by making sure is cache
buckets have enough memory (opcode cache, realpath_cache_size).

Secondly with any web framework your app will most likely be limited by IO
(database, file lookups, networking) before it becomes limited by actual code
execution performance.

If anyone's ever worked on a project where the performance problem was the
language and not IO I'd be really interested in hearing about it, but in my
career of making websites I've never ran into this problem yet.

~~~
idoubtit
Being skeptical is a good attitude. I'm very skeptical of this Eldorado that
some posters see in PHP7. My experience is quite different.

> Additionally PHP has an amazing performance debugger by FB called xhprof.

xhprof is unmaintained for years. The official version does not compile with
PHP7. Various forks exist, but the only stable fork has been rebranded and
defaults to sending all the performance data to the branding company.

> PHP performance could always be increased hugely by making sure is cache
> buckets have enough memory (opcode cache, realpath_cache_size).

Always, really? The history of PHP opcode's caches is complex. Before PHP5.6
where Zend published their opcache+, I've seen the various solutions (APC and
others) cause vicious bugs.

> Secondly with any web framework your app will most likely be limited by IO
> (database, file lookups, networking) before it becomes limited by actual
> code execution performance.

I've seen quite a few PHP applications that were CPU-bound, and that were far
from Facebook's scale. For instance, the learning platform Moodle is popular
with universities, but getting it to handle hundreds of concurrent users
cannot be done on a plain quad-core server.

Another poster suggested load balancing as an obvious solution, but adding
this is not that easy. E.g. Moodle has to track various files, including
uploads. So once you add a load balancer and several PHP servers, you need to
use a network mount for most of your files, which has a big impact on IO
performance.

I'm not saying that other languages are better, because I can't compare the
exact same large application in two languages, but PHP7 isn't an Eldorado.

~~~
mschuster91
> So once you add a load balancer and several PHP servers, you need to use a
> network mount for most of your files, which has a big impact on IO
> performance.

That depends if you set up cachefilesd correctly. Many people think it's
enough to do the NFS mount and that's it, but it's not - NFS's mount
parameters have a big impact on performance, and having cachefilesd enabled
can make performance go through the roof, especially with big files. Without
cachefilesd the only caching is in-kernel memory, which can and will lead to
files being evicted from the kernel cache...

Same for MySQL - having configured it correctly (or incorrectly!) can make a
life-or-server-death difference.

All without having to touch PHPs configuration... there's a reason why a good
operations guy is worth his weight in gold.

~~~
leesalminen
I’ve given up on NFS entirely and just use one of the big 3 cloud file storage
services.

Out of 8 downtime events, 5 were related to NFS mounts.

~~~
mschuster91
Hmm. I don't trust any external CDN, to be honest. No matter which one you
choose, you lock yourself dead into the vendor - should it decide to kick you
off for whatever reason you're toast, but especially I'm afraid of doing a
tiny mistake in AWS leading to accidental disclosure of private data.

Such "hacks" have hit too many too big firms for me.

Out of interest, what issues have you had with NFS mounts? I run a fleet of
virtual servers with their disks on an NFS-mounted NAS share and backed by
cachefilesd, never had a problem with that setup.

~~~
leesalminen
Eventually, NFS ends up freaking out and consumes all I/O on the client
machine until it is rebooted. I suspect that this occurs when the underlying
network is saturated, but don't have evidence of such. CentOS 6/7, NFS v3/v4,
tuned every setting I could think of, and spent dozens of hours Googling and
reading.

It may be worth mentioning that we had decent throughput with NFS. Roughly 10
writes per second (from 100kb-250mb) and 20 reads per second (IIRC).

We use rclone to do a daily backup from primary -> secondary cloud file store,
and use a little wrapper function in app to switch which host we're pulling
files from so it's not too hard to failover during an outage.

I do agree with you about vendor lock-in though, it's nasty stuff. At the end
of the day it comes down to time allocation. I'm a one-man ops show with too
many other things to do than to wake up with a Pingdom alarm at 3AM because of
NFS.

~~~
mschuster91
Whoa. I have never hit this one, to be honest, in years. Maybe it was
something CentOS specific, I have everything I have control of at either
Debian or Ubuntu... but I will keep this in mind in case I ever do hit this
error.

Might have been worth a try to get a RHEL support contract, but if you're a
one-man show and happy with CDN, then that's the better solution for you
definitely ;)

------
maxpert
I have been writing Go, Node.js and PHP for quite a while now. I don't think
golang is overhyped; nor it's a silver bullet. There are systems like
Kubernetes, etcd, and so on that are implemented in Golang and they work
really well. I think problem is people trying to use __Golang for EVERYTHING
__! There are so many things I would disagree with in the article; but I won
't disagree with the fact that if you want language with dynamic nature (Ruby,
PHP, JS) and you expect to find those conveniences in Golang you are flat out
wrong. Reading original article this is the exact feeling I get, somebody was
like __" look look a cool new toy" __and the herd followed.

~~~
edem
If you look for an oop or fp language you are also out of luck. You are only
happy if you look for a better C which most people aren't.

~~~
cies
> You are only happy if you look for a better C which most people aren't.

I'd argue Rust is the "better" C. Go is a "simpler" C, at the expense of
expressiveness, features, speed (only noticable in very low level usecases)
and applicability for certain domains (Go is primarily for networked apps).

In the same way Java wanted to be a simpler C++ (which came with it's own
drawbacks).

And for me Go is more of a competitor to Java (as Java is mostly used for
networked applications) than it is to C.

~~~
jchw
To me, Rust is like C++, Go is like C.

Rust loves zero cost abstractions, and isn't afraid to be complicated. It
gives the programmer as much power as possible.

Go is simple and actually very fast. The garbage collector is probably the
biggest hurdle for performance and it's still best in class. Definitely higher
level than C, but not enormously so.

~~~
cies
> Rust loves zero cost abstractions

C was also king of the zero cost abstractions.

> and isn't afraid to be complicated.

C sure is not afraid to be complicated. But at the time it was huge
simplification. I'd say Rust's complexity is not there for it's own merit, but
has huge advantages (though not that visible in a very small project).

> It gives the programmer as much power as possible.

C, C++, Rust are all in that corner.

Go obviously isn't.

~~~
jchw
>C was also king of the zero cost abstractions.

C++ has static dispatch classes, templates, constexpr, and macros. C just has
macros. Any other abstraction costs machine code. C++ also offers a lot of low
cost abstraction like RAII-style scoping.

>C sure is not afraid to be complicated.

Not sure in what sense you're talking. C is not complicated. It's low level.
It's exposing complications in the underlying model of a computer. Example:
pointers in C are not complicated. Understanding how they work may be for
beginners, but that just reflects how hard it is to understand what's going on
in a computer.

C is accidentally complicated where it is flawed; the non-orthogonal behavior
with arrays and the syntax for function pointers are examples. Go fixes some
of these flaws, which is unsurprising since it was informed by people close to
the origins of UNIX and C (y'know, like, Rob Pike?)

>I'd say Rust's complexity is not there for it's own merit, but has huge
advantages (though not that visible in a very small project).

Sounds a lot like C++. It isn't accidental or coincidental that it is a
favorite for high performance but complicated stuff like game and browser
development. This is no surprise since Mozilla wrote it to replace usages of
C++ for memory safety and concurrency, not because C++ didn't offer enough.
C++ is flawed in ways Rust isnt, but that doesn't mean the two don't share a
lot of traits, and it was Not by accident. Complexity is one of them.

>C, C++, Rust are all in that corner. > >Go obviously isn't.

Since you've offered no reasons for why this would be true, I can't actually
refute it. But it doesn't make a ton of sense. Go and Rust both let you shoot
yourself in the foot literally as much as you want. Go directly facilitates
assembly code and allows direct memory access with unsafe. Rust also does
this. Go tries to be memory safe and provide concurrency primitives. Rust goes
about this in a different way. I don't see where they significantly differ.

Rust differs most in it's superior memory safety model and low cost
abstractions. Go differs most in it's simplicity and built-in concurrency. But
they both feel close to their own origins.

~~~
cies
Good points about C. Thanks.

> Go differs most in it's [...] built-in concurrency.

That was what I was driving at, as well as Go not being fit for writing a
kernel in. Sorry being so inarticulate.

~~~
jchw
Yeah, that is actually a pretty good point to be honest. Go is not ideal for
low-level components such as that. I suppose the analogy of Go and Rust being
successors to C and C++ is reasonably flawed, from that perspective.

On the other hand, I'm glad things are turning out the way they are. Rust and
Go are both filling niches that C and C++ didn't, in ways that they couldn't
have. I look forward to Rust-based OS kernels, for sure. It seems like with
time, we can build very resilient foundations with Rust that wouldn't have
been possible before.

------
klodolph
Everyone I know who uses Go complains about it. Every day you write Go code
you will come across some piece of code that would be shorter with templates
in C++ or using <algorithm>, or you could do it more simply in Python, or if
you were really clever it would be a single line of Haskell.

And yet we keep writing Go.

By comparison, I'm a bit put off by the Rust community's evangelism, but that
might just be my personal experiences with Rust community members.

~~~
noncoml
> And yet we keep writing Go.

What are the alternatives if you want something with type checking? Java? No,
thanks. Haskel? Where are the libraries? C/C++?

I guess Typescript is the only alternative

~~~
psergeant
I’d really like a strongly typed (or optionally typed) Python or Perl
derivative. Rust feels most Perl-like so far.

~~~
patricklouys
Modern PHP is very nice to work with. Ignore the haters that haven't touched
the language in 10 years.

~~~
Lazare
To be fair to the haters, even modern PHP _can_ be horrible. The old
nightmares are still around; we've just agreed to ignore them, and maybe
deprecate a couple of the worst. (And ternary syntax is still broken, and the
standard library is _anything_ but standard.)

But yes, if you're working on a modern PHP project, there's a lot to love: A
solid module system, an enormous sea of high quality libraries, type checking,
a _really_ nice deployment and scalability story, decent performance, good
tooling (IDEs, debuggers, etc.), a servicable C-style syntax. For many
purposes (not all!) it's ten times better than, eg, nodejs. (Which might seem
like a low bar, I admit...)

~~~
nurettin
Is it better than nodets?

~~~
Lazare
nodets, as in typescript on node? I haven't personally tried it, but I imagine
so, again depending on your particular use case.

I quite like Typescript as far as syntax goes, but I think PHP 7.1+ is
comparable. And PHP has a lot more support, libraries, and better tooling in
my view. For example, my experience in node land is there aren't really any
good ORMs; PHP has multiple, including one (Doctrine) which is easily the
equal in my view of the highly regarded Python SQLAlchemy. Similarly with
routing, frameworks, templating, etc., there's a huge amount of maturity on
the PHP side that's missing from node.

The big question is going to be in the process model. Node has an event loop;
PHP doesn't. For most purposes, I think an event loop makes writing good code
harder to no real benefit, but in some cases (eg, acting as the endpoint for a
ton of open websockets) it can be a big win. If you _do_ need that, then you
should probably lean towards node over PHP, and sure, why not use typescript?
But for the general case, I'd still lean towards PHP.

(Then again, there's also a ton of _other_ languages and frameworks. Just
because PHP - or node - might be better than the other for some task doesn't
mean there aren't a dozen more languages better than both.)

~~~
nurettin
In your view, if someone created an ORM for node which focused on creating
object graphs for tables and fields (a-la sqlalchemy) instead of focusing on
SQL building syntax (a-la knex) would it be popular?

------
warent

      Go is not OOP in any shape or form, no matter what “they”
      try to tell you. Go is imperative language with procedural
      style of writing code. Yes, you have objects and you can
      attach methods to them, similarly to Ruby where everything
      is an object, but that’s basically it. Never, ever, try to
      repeat yourself in Go. You will crash and burn.
    
      When it comes to Go, spaghetti code is what you want to write.
    

This was really funny. Definitely the rantings of someone who is used to too
many layers of abstraction and coded themselves into a corner before finally
blaming the language. I'm detecting a lack of self-awareness. Here is where
the author should have used the gif that was used at the start of the article

~~~
jstewartmobile
It is a fair enough point though. Even Go written by pros often does not fit
together easily. Adjusting one library to fit with another is often a non-
trivial task, and many package authors freely admit as much.

I must have links to at least five different gzip middlewares in my favorites,
and I'm sure there are more than that...

~~~
majewsky
> five different gzip middlewares

At which point is it easier to put the app behind an nginx reverse proxy?
Chances are that you have a reverse proxy anyway since one Go app is not
nearly enough to saturate a server CPU.

~~~
jstewartmobile
Point being that something which could be easily slipped-in with a more
dynamic language triggers a total re-wrap in Go, or punting to an outside
system like your example.

Not hating on it though. I _like_ Go for network-y things.

edit: And in your example, is it a clear win to centralize compression at the
proxy?

------
tluyben2
Not strictly about Go, but how is it supposed to impress that 'big company X'
uses language Y (in this case the author uses Uber as if that's some kind of +
for Go); I would be far more interested in the language + framework used to
solve what level of complexity and scale problem with how many servers +
people. If you can build & run something with less people and servers than
your competitor and which makes you make more money, I think you have
something in terms of framework and language. I think K/Q exists because of
that and Janestreet uses Ocaml for that reason.

Also one should not forget that a company with 1000s of engineers is probably
not you (yet); when you read that some company runs successfully on Node and
saves $n amount of money by using it etc; when they have 1000s of engineers
and devops on top of that it doesn't mean you can achieve the same (or any)
success with it with 2 people. PHP for instance might be a much better choice
with a small team; you don't need complex server setup, you don't need (or can
handle) middle of the night alerts that require you to dive in vs just reboot
the server etc.

~~~
heavenlyblue
How is restarting a go-based server harder than restarting a PHP-based server?

~~~
Can_Not
You'll need the go process to complete all ongoing requests before restarting
it. Whether that be RPC, HTTP, WS, etc. And this is behind a load balancer, so
did you just go offline, or are you doing this one at a time? With PHP, you
don't have to restart php-fpm or modapache. Just git-pull or FTP the new files
in and the next HTTP request will automatically user the new version. Zero
downtime. Honestly though, I expect something like AWS and GCE to already have
our to be building a solution to handle the go scenario efficiently for you.

~~~
_ph_
This would be easily achievable by having 2 processes: one, which accepts the
socket connections and relays them to the subprocess which does the actual
work. New subprocesses could be started any time for updates, without killing
existing connections. All new connections would be handled by the new
subprocess.

~~~
Can_Not
So, basically what you get for free in erlang and PHP, but not in golang?

~~~
_ph_
Right, as Go is compiled into a static executable, you can't do code updates
on the fly that easy. A small price to pay in a production environment. On the
other side, you do have all compiler checks run while building.

------
jaccarmac
Perhaps it's characteristic of all language discussions, but Go articles seem
to generate an extremely polarized set of comments. My other favored languages
(Common Lisp, Nim, Rust, Smalltalk) tend to do the same thing, but in Go's
case the passion seems so... misguided.

In my opinion, Go is just such a bland-in-a-good-way language. And I enjoy
writing it, for the record. Came back to it after a while not writing it and
discovered warts I had missed before, but it's still pleasant. Can't help but
think people just need to relax a bit when it comes to Go. Listen to Rob Pike
speak about it compared to Rich speaking about Clojure: Go's not the language
to get worked up about.

(Please put generics in Go 2!)

~~~
nine_k
When "bland" means "prone to copy-paste boilerplate", its starts to sound less
relaxing. It sounds more like tedious search-replace and looking for not
making a typo when adapting the boilerplate to the next similar-but-sightly-
different use case. It turns a developer back into a coder.

What Go takes away is mostly tools of abstraction. Some of them are removed
for a reasonably good reason (hard to implement in 1.x). Well, people end up
with codegen tools that replace not only templates and generics but also the C
preprocessor.

------
edem
I see no facts or genuine refutation in this article, just opinions. Therefore
I can only assume that truth hurts because the article you are trying to argue
with has a bunch of valid points. If you look at the history of Go you have to
realize that it was created for the reason which is in the original article:
to be a better C.

If you come from C it is good, sure. And you can write big projects in it like
in C (just think about Linux or Unix). But if you come from a high level
language like Java (which is also performant by the way) Go feels like wearing
a straitjacket! Go lacks the most basic tools which any seasoned developer can
expect from a language (like generics). Just look at [my
response]([https://medium.com/@addamsson/this-article-is-wrong-in-so-
ma...](https://medium.com/@addamsson/this-article-is-wrong-in-so-many-
ways-47c91584fd6)) to this topic elsewhere.

~~~
majewsky
Okay, let's say I agree with your arguments:

1\. Go "is still not as fast as Java can be" [1]

2\. "Go lacks the most basic tools which any seasoned developer can expect
from a language (like generics)"

3\. "Go does not have a de facto build system and you can’t handle dependency
management in an easy way" [2]

4\. odd error handling

5\. not a lot of libraries to choose from [3]

6\. possibly more arguments that I missed when summarizing your post

The way you paint it, people would be _stupid_ to use Go. However, thousands
of very talented developers use Go everyday. How can you explain this
disconnect?

[1] I like how you didn't say that Go "is not as fast as Java". That's a
subtle, but important difference.

[2] `go install` is the build system and I have solved dependency management
for myself with literally a small shell script [4], and an official solution
is in the works [5].

[3] I never had trouble finding libraries for use-cases both common and
obscure).

[4]
[https://github.com/holocm/golangvend](https://github.com/holocm/golangvend)

[5] [https://github.com/golang/dep](https://github.com/golang/dep)

~~~
Erlich_Bachman
It's not really stupid, it can be misinformed, or just a matter of taste. For
some people having a small couple of specific qualities of a language is more
important (because they "like" them) is more important than even some
objective overall quality/ease of use. Many people are just forced to used it
because the company uses it. And of course, all the people who actually ARE
looking for a "Better C" \- then they will of course use something like Go. It
would be very "stupid" to use Java in that case.

------
paxys
All of the points this article makes are already addressed in the last one.

Yes, Uber is running a production Go service with massive QPS. This is exactly
what the original author meant when referring to Go's strengths with single-
purpose, high performance, "nano" services with relatively little business
logic.

There is also the insistence that frameworks are bad and developers absolutely
_have_ to care about "granular control" and "manipulation of bytes and bits"
and packets and IO (unless they're writing a "glorified todo list") which rubs
me the wrong way. Why is it so hard to acknowledge that there are a large
number of perfectly good websites and codebases that do well with popular
frameworks?

We ourselves have a proxy layer and a couple other services written in Go, and
they work great, but the rest of our stack is Java and some Python. Developers
are free to choose the best tool for the job when starting new project, but
after a few days of messing around in Go every new service is undoubtedly
built using our existing web stack.

------
herpderperator
At my job, before I joined, I was told we were torn between using Go and Rails
and ended up with both. Now we have a Rails frontend (for web requests /
authentication) and a Go backend (for business logic), which communicate over
Thrift RPC.

I don't think it was a very wise decision because not only are you doing
things twice, you're doing it three times, because you have to
serialize/deserialize to/from Thrift for every request. It adds development
time, more tests, and Thrift's binary protocol makes debugging RPC almost
impossible.

This isn't really an argument for/against Go, but it just shows that you
should try to avoid using multiple codebases that have to be tightly
integrated. Personally, I would've gone with a Ruby-only codebase that used
Thrift RPC only if there was some backend task that was too slow in Ruby, and
that Go's concurrency and speed might be better at. Then I'd serialize it and
send it over to be processed by a better language. I wouldn't do it for every
request.

That being said, if I had the choice between writing an API in Go vs Rails, I
would do it in Rails for the faster iterative development speed and quick
debugging capabilities that is made possible by an interpreted language.

~~~
bm1362
Have you tried thcurl or yab for debugging RPC? I’ve found that most services
I consume using thrift have a yab template for easy testing and trace ids so I
can follow the request- I haven’t really missed hand writing JSON curls yet.

[https://github.com/yarpc/yab/blob/dev/README.md](https://github.com/yarpc/yab/blob/dev/README.md)

------
pmontra
I don't know Go and I didn't use PHP very much so I'm qualified to comment
only on this part:

> I’ve worked with RoR, and a variety of frameworks in the Node world – and I
> have never had a framework project where I didn’t end up fighting the very
> system that was supposed to make development “easy”.

This is not my experience with Rails, Django and Phoenix. Actually, I was
probably fighting Rails in my very first project in 2006 (or was it 2005?) but
I was writing it as if it were Struts (I was coming from Java.) Then I started
coding as if it was Rails and got a great speedup in terms of coding time. I'm
less proficient in Django. It seems that it doesn't really enforce a project
structure and one can do almost what s/he wants. I've seen projects that look
very different to a degree I never saw with Rails. Basically all Rails
projects look the same. Phoenix is somewhat in the middle.

So, if the author is wrestling with frameworks either he's not proficient with
them, but this doesn't seem to be the case, or he genuinely doesn't like to be
constrained by the requirements of those frameworks. This is not a bad thing
per se. If one feels like that, he's going to be a happier developer writing
code with the architecture he designs. I'm not sure customers will be happy
too, but I don't know what kind of projects and customers he has.

About me, I prefer to stick with standardized architectures that any developer
after me will be able to understand in minutes. I'm a freelancer and I just
don't have the time to spend a significant amount of my customers budget to
learn (and make learn) more clever and optimized architectures before doing
any real work. If I had my company running around one software product, then
maybe I would design it from scratch. Reality check: I wrote so many MVPs in
Rails, especially for customers. Given the usual outcome (failure to get
traction) it would have been a waste of money to start with a more clever
design.

~~~
zaarn
Frameworks necessarily limit what you can do.

For example, the labstack echo framework in Go is one of my favorite
frameworks, it does a lot of work for me. On the downside, I can't hijack HTTP
connections in the router, like for example, when I want to host something
under customs domains and redirect internally to a subURL. I have to hack
around the framework to do that, the solution is rather ugly. But there isn't
much I can do otherwise that doesn't have various amounts of bugs.

Frameworks will always limit what you can do, period, you will have to code
around them once you want to do something they don't allow out of the box.

On the other hand, the less the framework does for you, the less limiting it
is but in the same moment it also does less work for you.

~~~
camus2
> For example, the labstack echo framework in Go is one of my favorite
> frameworks, it does a lot of work for me. On the downside, I can't hijack
> HTTP connections in the router,

This isn't a problem with "frameworks" but a problem with the library you
specifically chose which is bad since it doesn't even fulfill your needs
apparently. I wrote my own go http router, and I have no problem hijacking the
connection and filter according to hosts, at all.

~~~
zaarn
Writing a custom http router is kinda contra to the point of using a library,
no?

I don't want to bother with writing my own router and this was one of the few
times I had problems.

I think even if I wrote my own framework, I would eventually end up having to
hack around it anyway when I inevitably need to do something the framework I
wrote just fundamentally can't and I suggest this will be the case for your
custom implementation too.

~~~
heavenlyblue
So don't evolve your project based on HTTP stack more than an HTTP stack may
allow you to.

Suddenly, you'd like to have real-time comm? Don't add WebSockets, simply
because they fit right above the whole of your stack based on HTTP. Use TCP.

There's a very gentle balance between using what you've already got and
introducing a set of newer entities into the system; and sadly this is not
always that clear, which one you should use.

~~~
zaarn
Yes and that's quite obvious. However, frameworks are stil a limiting fact in
code. If I use a framework it won't let me do certain things. Which means I
have to hack around or introduce newer entities/dependencies.

A balance must be found, in one of the earlier examples, a quick hack was
easier.

------
rakibtg
From my point of view PHP 7.2 is a great choice for startups and with a small
team, so build the product, make it run. If required then do some R&D to
switch to go, jumping straight into go should cause some issue.

------
maaaats
It's not a good start when you have to resort to gifs ridiculing the other
article.

~~~
tempodox
Yes, I wondered whether I was the only one that found this article a bit
patronizing.

~~~
adventured
It did come across as quite patronizing. Particularly in contrast to its
light-weight argument style that almost exclusively consists of one-sentence
opinions, stated as fact, with very little behind them.

------
comandillos
From My point of view. Go is a great language and this author is right when
talking about using Go is better than PHP in cases like Uber or Youtube. I
mean, Im not a fan of PHP, I like to use low level languages the most time but
web is complicated. First of all, I don't think that not abstracting all the
IO and network HTTP socketing or all this stuff 'helps' somehow developing a
'better' web app. Maybe for Uber, Youtube, Google, Docker, AWS, yeah. But for
the most of everyday-apps for small/mid-sized business? I don't think so. I
mean, it would be great but from my point of view, developing a Go web app for
this kind of business, but it could be a little bit overenginered. Using
PHP/JSP would be much more straightforward for the developer/s, and maybe for
maintenance. The entire cost of the app will be greather as Go developers for
Web Apps cost you more than any PHP/JSP programmer out there. Remember Ruby?
It's the same problem. From the point of view of engineering, right, take Go,
but I think sometimes, isn't necessary. PHP is not the solution but will solve
you some problems that could be great for even mid sized businesses. Just my
opinion.

~~~
powerslacker
I think JSP is a great contender, and I see your point about overengineering.
PHP with type-checking is alright, but if I'm going to use a scripting
language I'd prefer Python or Ruby.

~~~
patricklouys
Both ruby and python seem to encourage duck-typing. I worked with both of them
in the past and that's the main reason why I always came back to PHP. I need
my type declarations...

~~~
spdionis
Agreed. The way i see it for the web is PHP is just a better Ruby/Python in
terms of libraries, package management, deployment, language features,
performance, with the only drawback being a quirky standard library.

------
tcfunk

      > Would you rather?
      >
      >    A – Be able to write new code 50% faster
      >    B – Have 90% less errors in all new code you write
    

For my employer, this is the most important question of the 3, and the answer
is A every time.

~~~
wccrawford
I guess the answer would depend on how many errors you have in the first
place.

If you have a _ton_ of errors, B is going to be more important. If you have
relatively few, then A is going to be a lot better.

My employer would probably pick A, too.

But there's a hidden side to this: If it's that much easier to code quickly,
it's probably easier to understand the code as well. Which means fixing bugs
is faster as well. At least, in my experience.

------
huntedsnark
> I have never had a framework project where I didn’t end up fighting the very
> system that was supposed to make development “easy”.

Not always, but often, I find this attitude in developers who either refuse to
read documentation, or just entrenched in their ways and too stubborn to try
it someone else's way.

Is every project you're starting really so cutting edge that the problems
others have solved and come to a consensus on don't apply to you? Perhaps, but
maybe you should also be taking a look in the mirror and making an honest
assessment on just how difficult you are to work with.

------
cft
I don't know why the author bothered to even respond to that Medium article.
The Medium article starts with that Go shines as a systems programming
language. He lost me right there: how can a language with a garbage collector
and a runtime be called a "systems programming language"?

~~~
sidlls
"systems programming language" doesn't start and stop with bit twiddling one
step removed from assembler.

There's a huge fuzzy region between that extreme and "application programming
as a semi-skilled trade", and go seems to fill certain "systems programming"
needs adequately as far as that goes.

~~~
cft
Languages like C and Rust are true system programming languages, and they are
not one step removed from assembler. Rust has a very complex compiler. Go is a
low level applications programming language.

~~~
sagichmal
This pedantic terminology fight about what constitutes a “systems” language
hasn’t been worth having since 2009, when all of these arguments were already
aired and resolved. Please find another hill to die on.

~~~
BuckRogers
He is correct though, at least from the perspective of Go's own designers?
Wasn't "systems language" removed from the description at some point. I've
listened to interviews with Rob Pike who even outright said they got the
messaging wrong there.

I think it's pretty well accepted that no systems language has GC. Go is on
the same abstraction layer as Java/C#. Everything in text can be taken as a
slight, and to ensure that doesn't read that way, I am a believer in targeting
that level of abstraction most of the time. I think it's the sweet spot. I'm
not a fan of the dual language approach targeting high (Python) and low (C).
Java or C# makes more sense to me, for _most_ software. That's my opinion. If
I needed more than what those heavy hitters provide, I'd just go all the way
and reach for Rust myself.

So I don't necessary see the parent comment from ctf as combative. I think
he's just seeking accuracy.

~~~
sidlls
Java has been used as the implementation language for games, high performance
servers, message queuing systems, operating systems, and operating embedded
devices for goodness sake. It doesn't get much more "systems-y" than that. Go
is surely at least as suitable for these uses.

I think the other commenter is correct: it seems like a semantics argument,
and a rather pointless one at that.

~~~
cft
You cannot really write an operating system without manual memory management.
That's why Go is not a systems programming language. It does not diminish Go
advantages: I would personally prefer it as an application programming
language to Java.

~~~
pjmlp
Completely false, there are several research OSes with kernel level GC.

I suggest reading Project Oberon source code, it’s freely available.

~~~
BuckRogers
I can't speak for the parent but he did say "cannot really". I would assume
due to that he's aware you can write a research project in it. At one point, I
thought Windows was to move to .Net even and MS backed out in the end.

Back to Go, for anyone else reading this thread and wondering what Rob Pike
thinks it is, evidence of them removing "systems programming" off their
website is here. He explicitly states that he regrets it and that Go is not an
OS writing language[0]. Andrei Alexandrescu offers a litmus test shortly after
with a property of a systems programming language that Go also fails. If the
creator of a language says it's not a systems programming language, I'm not
sure how it can be argued by outsiders that it is.

If there's more damning evidence that Go is not a systems programming
language, I couldn't imagine what that would be. A shortlist of systems
programming languages that would pass any litmus test would include C, C++, D
and Rust.

[0][https://www.youtube.com/watch?v=BBbv1ej0fFo&feature=youtu.be...](https://www.youtube.com/watch?v=BBbv1ej0fFo&feature=youtu.be&t=6m44s)

~~~
pjmlp
> I thought Windows was to move to .Net even and MS backed out in the end.

If you bother to read Joe Duffy's postmortems, and talks he has made about
Midori, you will get it had nothing to do with technical issues, rather
internal political wars at Microsoft.

Also Microsoft did not fully backed out, the outcome of Singularity became the
MDIL compiler for .NET on Windows 8.x.

Midori influenced async/await, TPL, .NET Native used in UWP and the new low
level language features on C# 7.x.

> If the creator of a language says it's not a systems programming language,
> I'm not sure how it can be argued by outsiders that it is.

I don't have Go in much high regard, but it certainly can be used for systems
programming, and is being used as such today, regardless of what the anti-GC
systems language crowd thinks.

"G.E.R.T : Golang Embedded Run-Time"

[https://github.com/ycoroneos/G.E.R.T](https://github.com/ycoroneos/G.E.R.T)

"Fuchsia TCP/IP stack", all network requests go through it.

[https://groups.google.com/d/msg/golang-
dev/2xuYHcP0Fdc/tKb1P...](https://groups.google.com/d/msg/golang-
dev/2xuYHcP0Fdc/tKb1PgTXAwAJ)

[https://fuchsia.googlesource.com/netstack/](https://fuchsia.googlesource.com/netstack/)

"Fuchsia disk management utilities for file systems"

[https://fuchsia.googlesource.com/thinfs/](https://fuchsia.googlesource.com/thinfs/)

~~~
BuckRogers
In that case it sounds like you have a bone to pick with Rob Pike over Go. I
suppose you can find him on Twitter if you want to settle your feud. I'd
suggest to not bother when I have him on tape contradicting you.

I did read Joe's blog, years ago. Your takeaway there also leaves you with a
bone to pick with Microsoft, if it's just politics then you should be able to
find someone in management at Microsoft to set straight. It'd be a real shame
if there were no performance issues and it was shutdown due to politics alone.

~~~
pjmlp
It doesn't matter what Rob Pike says regarding Go and systems programming,
because Google, the company that employs him, has decided Go makes sense to
write system components of Fucshia in Go.

That is a fact, easily validated in Fuchsia's repository.

According to you, Rob Pike should call management and let them know it is not
a good idea to use Go for writing Fuchsia's TCP/IP stack.

You only read Joe's blog years ago, yet you missed the talks he gave.

Two years ago is not that long time ago,

[http://joeduffyblog.com/2015/11/03/blogging-about-
midori/](http://joeduffyblog.com/2015/11/03/blogging-about-midori/)

"My biggest regret is that we didn’t OSS it from the start, where the
meritocracy of the Internet could judge its pieces appropriately. As with all
big corporations, decisions around the destiny of Midori’s core technology
weren’t entirely technology-driven, and sadly, not even entirely business-
driven. But therein lies some important lessons too."

[http://joeduffyblog.com/2015/12/19/safe-native-
code/](http://joeduffyblog.com/2015/12/19/safe-native-code/)

"Over the course of 8 years, we were able to significantly narrow the gap
between our version of C# and classical C/C++ systems, to the point where
basic code quality, in both size of speed dimensions, was seldom the deciding
factor when comparing Midori’s performance to existing workloads. In fact,
something counter-intuitive happened. The ability to co-design the language,
runtime, frameworks, operating system, and the compiler – making tradeoffs in
one area to gain advantages in other areas – gave the compiler far more
symbolic information than it ever had before about the program’s semantics
and, so, I dare say, was able to exceed C and C++ performance in a non-trivial
number of situations."

"Safe Systems Programming in C# and .NET"

[https://www.infoq.com/presentations/csharp-systems-
programmi...](https://www.infoq.com/presentations/csharp-systems-programming)

"RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of
Computing"

[https://www.youtube.com/watch?v=CuD7SCqHB7k](https://www.youtube.com/watch?v=CuD7SCqHB7k)

Around minute 30 he starts describing the uphill battle to convince other
Microsoft teams to accept Midori achievements.

~~~
BuckRogers
A TCP/IP stack isn't a stringent litmus test for a systems PL. So you can
loosen your own standard for what comprises a systems PL, but Go fails more
rigorous standards. Everytime. Even Rob Pike says you're wrong and he's
certainly a sympathetic character towards Go.

All of this was hashed out years ago upon Go's release, and the Go team took
down the "systems language" moniker. That was the end of it. Google knows it's
not going to fulfill stringent litmus tests for a systems-language. We'll
review the subject again if the folks at Google are brazen enough to ever add
it back to the website.

Now Rob doesn't have to call management and let them know it's not for systems
programming, Rob & Google already know it's not. He said so himself. You're
the only one in the dark on that front at this point.

~~~
pjmlp
Unlike yourself I don't care what Rob says, because at the end of the day what
matters is what people on the street are using Go for.

Developers don't have to ask him permission or blessing for whatever they are
trying to do with Go.

Google is using Go in system components in Fucshia, and the new GPU debugger
for Android is also written in Go.

You are in the one in the dark about using GC enabled systems programming
languages. I have real life experience using them and have seen it works.

I lost interest on Go due to its spartan design, but certainly will encourage
anyone trying to use it to build an OS from scratch, regardless of what is
written in a web site.

"They did not know it was impossible so they did it"

\-- Mark Twain

~~~
BuckRogers
The reason Rob's statements matter is because he's the authority on Go. If you
had been a primary inventor of a new language, I'm guaranteeing you'd feel
entitled to decide what it is and is not. Not have "pjmlp" debate endlessly
over something you had already stated was simply not true.

A lot of things work, doesn't mean they meet strict litmus tests (which
matter, because definitions matter), nor does it mean it's a good idea.

~~~
pjmlp
When a language is set loose to the world it belongs to its users, and
whatever they decide to do with it.

Anyone is free to just fork Go and do whatever they feel like with it,
regardless of what Rob thinks. That is the beauty of MIT license.

So given that Oberon is accepted as a systems programming language in computer
science, with multiple published papers and books across two decades, heavily
used in OS research at a couple of European universities during the 90's and
an influence to Go, with hardware and compilers still being sold for systems
programming, although in small scale.

What are the actual technical features Go is lacking that makes it impossible
to be used for systems programming, given Oberon's influence on its design?

~~~
BuckRogers
Your concerns have already been answered. Most succinctly stated by two
points.

1) A lot of things work, it doesn't make them good ideas.

2) Go doesn't meet the strictest litmus tests of a systems language, never
did, never will. It's only a systems PL only if you relax your definition of
what it is. Go's own creator says it's not and if any one person is the
authority on this topic it's him. There are platforms that meet all
definitions, those are definitely systems PLs.

~~~
pjmlp
If people cared about litmus tests, whatever that means, JavaScript would
never have left the browser.

I only care about what Computer Science books and ACM SIGPLAN papers accept as
systems programming languages, not random opinions in online forums.

Thankfully both of our opinions are meaningless to Go users.

~~~
BuckRogers
It doesn't matter what people like yourself think or attempt with a given
technology. This is about technological definitions. Go is not a systems PL by
the strictest measures available, that's a fact. Designers of C++, Rust, D and
Go for the most part agree on that. You're the only odd man out. Redefining
terms or loosening the standards for quality is an intellectually deficient
venture. Some may partake in that, myself and others refuse to. It's best to
leave it at that, it boils down to intellectual honesty vs dishonesty to push
your viewpoint.

~~~
steveklabnik
Rust’s designers aren’t really interested in playing the “what is a systems
language” game, honestly. We are even considering abandoning the term entirely
when describing Rust, as we’re not sure it’s a particularly useful term.

~~~
BuckRogers
A strong litmus test as the one given by Andrei (creator of D for those not
paying attention), settles the definition well enough. I'll even back off that
claim because some absolutely refuse to accept a litmus test to meet
definitions of things, as they're so hellbent on not being excluded.
Unfortunately that's how language and the world works, not everyone gets their
way.

So we'll just settle on once there's a commercially successful operating
system built in a GC'd language then I'll eat crow but till then they're all
going to be C/C++/D/Rust or built on similar abstraction layers. Go ahead,
wash away Linux, iOS and Windows in the competitive landscape with something
written in Go. Let's see it, that's believing after all. It'll never happen
because it's unsuited and inferior for that purpose.

------
HeadlessChild
Wow, that's a first. The website is hijacking the "go back" button for Google
Chrome.

------
fimdomeio
I think this discussions are mostly pointless... Most of the times I can see
one side or the other being right depending on the size of the project, size
of the team, time to learn something new.

------
Annatar
He never went back to PHP and most of the article is spent on extoling Go, so
the title intentionally misleads. I feel jipped!

------
jstewartmobile
How many people here subscribe to the " _they 're all DSLs_" theory?

------
rmanolis
I use Golang for everything. For example I use GopherJs with polymer for the
front-end and gin for the back-end.

------
frik
PHP is unique in several ways: it's especially designed for the web, is a Web
framework itself, comes with everything inbuilt, has C/Java syntax, has a
shared nothing architecture, replaced VB as the most popular language for
beginners, is used by most websites, is easy to use just drop a php file to
Apache www dir. You simply can't objectively compare PHP to other languages
because it's different to all others, it's unique. And due it's wide spread
usage and earlier non-academic approach it still gets (rather unfairly) some
bad reputation. Anyway PHP 7.2 is great, and Go too.

------
Drdrdrq
I recently used Python for a project and was again reminded why PHP is still
the king of smallish web sites. With PHP I could rent a cheap service to host
a few sites, no problem, take FTP and just upload scripts. That was possible
15+ years ago and still works today.

With Python - not so much. Sure, I can rent a whole VPS but I don't want to do
server administration. And there are some options for hosting Django / Flask
apps, but not many. Is it any wonder people still use PHP? I have used it for
a long time and I hate the language - but it is hands down the best solution
for small web pages where hosting is concerned.

EDIT: thank you for the downvotes. It was nice having a constructive
conversation. But then again, I knew in advance it is unpopular to mention on
HN that PHP, MongoDB and similar technologies have their use cases.

------
musage
I know this is about the weakest critique possible, but currently using Go, I
know my next project won't be in it, simply for the impossibility to put an
opening curly brace on its own line. Other languages that don't require
semicolons at the end of a line have it, and even if they didn't, I'd rather
have to put semicolons manually.. Go is "opinionated" I guess, but so am I.
Whatever their target audience is, I'm not in it.

One thing I used to hate about PHP but then kinda grew to like was variables
being prefixed with a $, as it makes it real easy to distinguish between
functions and variables at a glance.

Other than that, it's just programming. For me, who is making really simple
things, 99% of the work is figuring out the pseudo-code and data structures,
if the language doesn't get into my way, they're pretty much all the same. I
haven't tried Rust yet, but from a casual glance I do like what I see.

~~~
donjoe
... curly brackets on new lines do work perfectly fine in case you're writing
code on your own. As soon as you start working in a team and each team member
starts to use their own formatting, it becomes super messy and unreadable.
Either you inforce a clear style guide which leaves you to explain the team
why your style is the best, or you leave this task to the language itself and
never ever have to start arguing about curly brackets, whether to use tabs vs.
spaces, ... (I'll stop here).

~~~
musage
But why should Go enforce it on behalf of everybody? A parser option to not
automatically insert semicolons would be all I need, but no.

To me, even with super short lines, braces at the end of the line _are_ messy,
and consistently messy is still messy.

> Either you inforce a clear style guide which leaves you to explain the team
> why your style is the best, or you leave this task to the language itself

Which then leaves the language to explain why that style is best. Did Google
ever do that?

~~~
thegeekpirate
Official response:
[https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s](https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s)

~~~
musage
Yeah, that's what I thought.

