
Go is PHP for the Backend - vectorbunny
http://skife.org/go/2012/11/18/go_part_1.html
======
Jabbles
_Go has a way of programming. Go is totally optimized for that way of
programming, in fact. Programming any way other than Go’s way, with Go, will
be that recipe for frustration I bounced my skull against. Go’s way is not
pretty to someone indoctrinated with the modern functional aesthetic, but it
works, and works well. Really well._

A good summary of programming in Go.

However I would like you to give some examples of inconsistencies in Go. And I
believe that leaving features out ("anything a modern programming language is
supposed to include") makes Go cleaner, safer and more understandable than any
other language I know of (IMO).

~~~
dsl
From what I was able to gather, the authors gripes tend to be with the lack of
meaningful whitespace and "tabs".

Both the goto arguments of someone who lacks enough understanding of language
fundamentals to point out any actual flaws.

~~~
mischov
For the sake of accuracy there was also some stuff in there about a conflict
between first-class functions and the type system, and some stuff about errors
being easy-to-ignore return values.

~~~
charlieflowers
Yes, and those are pretty solid points. Too substantial to just sweep under
the rug.

------
jfaucett
"Go has a way of programming. Go is totally optimized for that way of
programming, in fact. Programming any way other than Go’s way, with Go, will
be that recipe for frustration I bounced my skull against."

I think this is something a lot of people think when they first come to Go.
Especially if you come from a higher lang like ruby or js or something since
on other places on the net its kind of being marketed as a nodejs alternative.
However, in my experience the "frustration" hasn't been there at all. I came
from c and I think you get basically just a vamped up "better" (I know bad
word) c. I love having multiple return vals and error handling in my returns
and message passing and threading to any types is so easy in Go it just makes
life nicer.

These are all my biased opinions as an avid Go user of course, but honestly I
find the language extremely expressive and powerfull, and not really that it
forces you to do something the Go way, other than the sense that yes you need
to know the syntax and not have type errors etc, but this is the case with
every language.

~~~
Jabbles
I quoted the same paragraph, and I'd be interested to know how much people
think it applies to other languages.

Obviously there are languages using whole other paradigms that you would
struggle immensely in, try writing Prolog like Java! But I wonder if the "Go
mindset" is really any stronger than the "Ruby/erlang/lisp mindset" - or
whether it's just the proximity of Go's appearance to C,C++,Java that causes
new Go programmers to try to port incompatible idioms.

------
duiker101
Woo Woo Woo...Am I missing something or isn't PHP also a back-end language?

About the article, I think you are just doing it wrong. I personally never
used Go, like I never used many other languages, but I tried many. Everyone
has it's own way, just because one does things differently and not your way
doesn't mean it's wrong. It means is different. You know...taste...

~~~
gummydude
PHP is weak for long running back-end services.

~~~
encoderer
True, but if you have to:

<https://github.com/shaneharter/PHP-Daemon>

~~~
gummydude
From your link.

"Note: For many reasons PHP is not an optimal language choice for creating
servers or daemons. I created this library so if you must use PHP for these
things, you can do it with ease and produce great results. But if you have the
choice, Java, Python, Ruby, etc, are all better suited for this."

Possible but not recommended.

~~~
encoderer
Yeah, it's my project. It's OSS so I figured a shameless plug wouldn't hurt
anybody.

------
oofabz
>Idiommatic Go is to have several lines of boilerplate after every single
function invocation which can possibly fail.

This is an issue in every language. If you want to do something that might
fail, you have to handle the possibility of failure. There are only two ways
to handle this - return values and exceptions - and they differ in style more
than in functionality.

So what is this guy suggesting? Does he want Go to have exceptions? Or does he
want every function to magically succeed somehow? I don't enjoy writing error
handling either but I see no way around it.

~~~
jrockway
I think he wants a non-boilerplate way of doing operation b only if operation
a succeeds. Instead of writing:

    
    
       result = operation_a()
       if not result:
           return ERROR
       result = operation_b()
       if not result:
           return ERROR
       return result
    

He wants to write:

    
    
       operation_a()
       return operation_b()
    

This is a logical thing to want, because the program is not semantically
correct if operation b executes after a failed operation a. It is correct,
however, if a failing operation_a causes the entire routine to fail by bailing
out early. So it would make sense that that be the simplest thing to write,
and then make the case where you ignore errors from operation_a be the thing
that's a lot of lines of code.

Ultimately, it's a problem of not enough abstraction. Users of traditional
programming languages are held hostage by the control-flow abstractions that
the language designers put in place. But if they weren't, then they'd simply
write the top code block and call it "combine_failing_operations" or something
and they'd write their program in terms of combine_failing_operations:

    
    
       combine_failing_operations(
           operation_a,
           operation_b)
    

Of course, combine_failing_operations is itself a failing operation, so one
can also write:

    
    
       combine_failing_operations(
           combine_failing_operations(
               operation_a,
               operation_b),
           operation_c)
    

The reason why people don't is because the resulting code is ugly and it's not
encouraged by the langauge's style guide (which usually says, "I'm the
programming language designer, if there's missing functionality it's because
the functionality is wrong").

In languages where function application is the only syntax, though, this
pattern shows up all the time.

For example, in Haskell, you normally combine two functions with the .
operator. (f . g) x = f(g(x)). It follows that if you want to combine two
functions that can fail, you'll just write that function. Haskell does exactly
this and even gives you some syntax sugar: if you call your function >>=, then
you can write:

    
    
       do
         operation_a
         operation_b
    

instead of "combine_failing_operations operation_a operation_b", which means
you get both pretty code _and_ context-specific only-written-once correctness.

Semantically this is what Go does, but the syntax isn't as nice. (Exceptions
are certainly irritating when applied to Go's concurrency model, but at least
they are fail-safe. I don't trust myself to get every line of code 100%
correct, and I _want_ my program to crash when it gets into a state I didn't
write code to handle. Go makes this harder than it should.)

~~~
rogerbinns
The error handling is the single thing that annoys me about Go. If you look at
every hello world tutorial, the error return of println is ignored. In
languages that use exceptions an error would not be ignored.

A happy medium for me in Go would be if you ignored the error then an implicit
"return error" is added at that point. That way errors you handle locally get
handled, and those not get passed to the caller. This is somewhat semantically
similar to exceptions, but is a lot less code to write. And as a bonus all the
hello worlds will have error handling.

(Yes I am aware there are some implementation details.)

------
james4k
>PHP is horribly inconsistent, breaks all the rules about programming language
design, and is infuriating.

Some say that rules are made to be broken. In the context of Go, Rob Pike
argues exactly that in this short talk on why they made Go:
<http://www.youtube.com/watch?v=5kj5ApnhPAE>

------
klearvue
Rarely do I get to read articles that are that low on substance, facts or
concrete examples. What is a "Go's particular way" and how does it differ from
the author's way? What are these 'particular' structures and behaviour? What
is this "particular way", and again "particular way", of solving design
issues? Is it like Fight Club?

------
phillaf
>PHP is horribly inconsistent, breaks all the rules about programming language
design, and is infuriating.

I stopped reading upon the first bold statement.

~~~
mylittlepony
I didn't even click on the link, I knew I was going to find hollow statements
like that one.

After reading the fantastic article from patio11 that was reposted today, I
can't read this kind of ----.

~~~
drivebyacct2
Thanks for taking the time to write this insightful comment.

You guys should go find some corner to sit in and be negative. Jeering with no
actual feedback is tacky and makes you look childish.

~~~
knieveltech
And yet somehow you couldn't resist playing along...

~~~
drivebyacct2
I had had some hope that there would be some actual feedback and a discussion
about why Go is bad or why PHP deserves lauding.

And you were expecting what with your reply?

------
charlieflowers
I enjoyed the article but came away frustrated by one thing -- it offers
_specifics_ about the problems with Go, but only _generalities_ regarding what
is good about Go.

I haven't tried Go, but I'm aware of things that seem like short-comings to me
(most especially, the lack of exceptions). So I understood the first part of
the article.

The second part was vague ... I could tell that the author decided that all
those problems were OK, but I don't really know how that happened. He chalked
it up to the "way of Go". I'd really like to hear some concrete descriptions
of what that is.

------
adrusi
> [go] gets out of your way and make building [services] easy

> stop programming _my_ way, and start programming Go’s way

These are inconsistent assertions fundamental to the point the article tries
to make.

------
spleeder
PHP is for the backend too.

~~~
ihsw
PHP doesn't support multi-threading -- or concurrency of any kind _at all_
because it's not thread-safe.

~~~
encoderer
No threading is accurate, and that makes it less ideal than many languages.

But it does provide thin wrappers over process forking and
implementations/wrapper of libraries necessary for IPC (eg SysV queues, shared
memory, semaphores, pipes and sockets).

------
hereonbusiness
I've run a symbolic analysis on this article, it came out empty.

