6 ms·
Go is PHP for the Backend
- spleeder 14y agoPHP is for the backend too.
- ihsw 14y agoPHP doesn't support multi-threading -- or concurrency of any kind at all because it's not thread-safe.
- encoderer 14y agoNo 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).
- randomdata 14y agoPHP is generally geared towards the application, not the backend. The backend is comprised of things like database servers, message queue systems, etc. It is, of course, not impossible to implement those services with PHP, but I don't think it is very common. Java, C, and C++ have been the traditional languages for that level with a few other more esoteric ones mixed in on occasion for certain tasks.
- phillaf 14y ago>PHP is horribly inconsistent, breaks all the rules about programming language design, and is infuriating. I stopped reading upon the first bold statement.
- M4N14C 14y ago>PHP is horribly inconsistent, breaks all the rules about programming language design, and is infuriating. Can't read, didn't try.
- mylittlepony 14y agoI 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 14y agoThanks 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 14y agoAnd yet somehow you couldn't resist playing along...
- drivebyacct2 14y agoI 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?
- Jabbles 14y agoGo 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 14y agoFrom 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 14y agoFor 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 14y agoYes, and those are pretty solid points. Too substantial to just sweep under the rug.
- charlieflowers 14y agoYes, and those are pretty solid points. Too substantial to just sweep under the rug.
- deleted 14y ago[deleted]
- StavrosK 14y agoI'm a die-hard Python/PEP8 fan. Non-significant whitespace, I could take or leave, but tabs as indentation just make sense. You're separating form from content, which, as programmers, we should be all for. As a pedant and an anal retentive person, I love gofmt. It's a big part of my coding peace of mind.
- klearvue 14y agoRarely 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?
- james4k 14y ago>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 http://www.youtube.com/watch?v=5kj5ApnhPAE
- duiker101 14y agoWoo 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...
- dokem 14y ago> Everyone has it's own way, just because one does things differently and not your way doesn't mean it's wrong. Did you read the article? That was exactly his point.
- gummydude 14y agoPHP is weak for long running back-end services.
- encoderer 14y agoTrue, but if you have to: https://github.com/shaneharter/PHP-Daemon https://github.com/shaneharter/PHP-Daemon
- chrismsnz 14y agoInteresting - hadn't seen that before. My own attempts at brewing something together with PHP's posix and pcntl libs were feeble. Thanks for the link.
- gummydude 14y agoFrom 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 14y ago
- oofabz 14y ago>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.
- azth 14y agoSee Scala futures and promises.
- swift 14y ago> There are only two ways to handle this - return values and exceptions - and they differ in style more than in functionality. "There are only two" is a bit strong. Off the top of my head I can think of conditions and restarts in e.g. Common Lisp (to be fair, these are a generalization of exceptions) and monads in e.g. Haskell. I'm sure there are others I'm forgetting.
- jrockway 14y agoI 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.)
- jfaucett 14y ago"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 14y agoI 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.
- deleted 14y ago[deleted]
- adrusi 14y ago> [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.
- charlieflowers 14y agoI 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.
- hereonbusiness 14y agoI've run a symbolic analysis on this article, it came out empty.