Sometimes your app just stops working because of some typo in your code
I don't know of any programming language that will auto-correct typos for you.
or the spaghetti code becomes just too unreadable.
If you don't write spaghetti code, you won't have a problem
PHP just doesn't seem exciting for me anymore. There doesn't seem to be anything exciting happening.
PHP isn't some 0.6-pre-alpha release software that douchebag developers use for production apps and get excited about when the core API changes every 3 weeks.
not much has been happening with the language and nothing interesting as far as apps or frameworks.
so you, as a developer, are complaining that no interesting apps are being developed in a specific language..?
Since I'm not a sysadmin, I prefer to pay extra to have my code managed by someone.
Sysadmin's don't manage code. You are a developer, you should be managing your own code.
Interfaces and reflection are awesome.
both of which PHP has.
Go helps me write cleaner and more maintainable code
I doubt it. You claimed that your code "becomes" spaghetti. Which implies that it starts out "clean and maintainable". I'll wait with baited breath for how long it takes your new code to also "become" shit.
Thanks you for writing this, I'm on my tablet so it would have been difficult. My thoughts EXACTLY!!! In fact this seems like Google trying to take advantage of PHP getting some bad PR recently and pointing people to use Go and inadvertently, Apps Engine.
>I don't know of any programming language that will auto-correct typos for you.
I know of many compilers that will point them out to you, and IDEs that will offer to auto-correct them (Eclipse, XCode and Visual Studio for example).
>If you don't write spaghetti code, you won't have a problem
Yes. And if you don't make any memory allocation errors you don't need a GC. Hell, if you don't make any errors period, you can just program in hex, building the executable code directly and skip assembly.
The thing is, different languages have different inherent characteristics (syntax, features) and different cultures (pertaining to libs, common practices, frameworks, etc), so one can tend to create more spaghetti code than the other, the programmer being equal.
"The thing is, different languages have different inherent characteristics (syntax, features) and different cultures (pertaining to libs, common practices, frameworks, etc), so one can tend to create more spaghetti code than the other, the programmer being equal."
That's simply not true. If you are organized, you will use whatever structures the language you are using provides to you (classes, modules, namespaces, etc.) to NOT write spaguetti code.
Spaguetti code it's not inherent to the language, it's inherent to the programmer.
It's interesting and I guess this just reflects what one of the founders said in a speech (which was re-published onto the 'tubes), that though they went out trying to make a systems programming language that would attract system language programmers, they've been picking up a lot of us dynamic "script kiddies" (I didn't mean that term seriously, lighten up).
I'm a PHP/Ruby/JS developer, I dabble in iOS/ObjC and it's ok, but the language which has me most excited is Go. I've watched screen casts and read things but still haven't got around to building anything serious in it, but when I get the time/need to build something really performant, I will. It could just be because it's new, but it seems to have an energy about it and the developers have made a real effort to provide great docs and make it accessible to us mere mortal, non-cs educated dynamic folk. I thank them for that.
Go is advertised as feeling scripty and light but I don't think it really shakes the systems programming feel. Idiomatic Go has a lot of error checking which adds verbosity.
It would be nice to have a language you can do scripty stuff with but also build high performance systems, but I doubt Go will be it. Clojure seems closer but somewhat less performant.
I mean, you should be handling errors, that's the point. But if you want to ignore them, it's almost always the last return value so you can just write:
I think you made a decision to use Go without explicit reason beside that you've been hearing about it and now you are coming up with reasons to back your decision.
In other words, you are moving backwards from decision to made up reasons.
> "I won't consider Ruby because I tried Rails once five years ago and it had scaling problems."
Looks like he didn't seriously consider Python or Ruby at all.
Agreed. I'm not one to push my language preferences on others, but "it had scaling problems" more likely means "I read about Twitter's unique scaling problems".
I don't think Go is a bad choice for web apps, though; perhaps, if anything, the ecosystem is a bit immature and therefore can make deployment a bit more of a chore.
I get the point about the ecosystem being small, but not how it relates to deployment. Because Go executables are statically linked, deploying Go apps is very easy.
I'm the author of the original article. I do like Python and I didn't say I had an adversion to rails or ruby. I was just giving a statement as to my previous experiences. I did state "Most were brief enough that they shouldn't be taken too seriously."
Your comments regarding Python and Ruby initially drew my ire, but I realized that they're not really "reasons". I'd have omitted them entirely, because they're not really reasons at all. You don't have to have exclusionary reasons for not choosing another language. The ones you've listed are so flimsy as not to detract from the positive reasons you listed. The simple desire to try something new is plenty good enough to try a new language.
Rails can't scale ...blah, blah, blah. That's repeating 2008 rehash bullshit. Build something that enough people are using then he can't bitch about a problem he'll probably never have. Besides, with proper SOA, scaling problems are on par with other languages. It tires me to no end when people (as in the original poster) makes claims they know nothing about.
I always looked at PHP as the sane alternative to ASP. Not sure GO is ideal as a drop in replacement by design. Seems like chap just wanted an excuse.
Now I'm doing a project which leans towards python and in some aspects C - that does seem to be more pandaring towards doing it in GO. But if it was a production project and not a fun project then I'd hold back from looking at GO, but it's a fun one so I'm looking at it and finding it very suitable alternative to python/C in this case. Still sussing out a nice IDE but I'm in no rush.
But for a PHP project I'd say PHP may be a better fit for cases were you use PHP as a ASP alternative. Lets that how I see it, though I'm no PHP guru, let alone ASP.
PHP is a sane alternative to ASP? Do you mean ASP.net written in VB, or using webforms or something? I take it you haven't actually experienced firsthand the glaring inconsistencies and bizarre behaviour present in PHP's core language features, because it's a far cry to call php 'sane' in comparison to ASP//C#.
Title says "Dumping PHP For Go"... then the article says: "Why no more PHP? First, I should probably clarify that I will continue to use PHP"... hmm, is this a contradiction or not?
Why do you think Go is no suited for web apps? At the end of the day web apps are just servers, and Go is very well suited to create reliable and efficient servers. Go is also one of the languages supported by Google App Engine to create web apps.
Languages specialize. PHP is suited for the web because it is a dynamic language, stuff is compiled right when it is accessed, and there is no memory sharing between requests.
Go, C, C++, etc. are static languages, stuff needs to be recompiled for even a minor change, and of course, memory is shared for each request.
And that's just the tip of the iceberg.
Obviously you can bring all functionality that the web demands to Go. A jit compiler might help, maybe some loose typing, a few other widgets ... and then, guess what? You turned Go into PHP.
> PHP is suited for the web because it is a dynamic language. Stuff is compiled right when it is accessed. Great if you need to quickly make a change here or there
I don't think this is really a problem. Although dynamic typing vs strong typing advantages/disadvantages are a whole 'nother argument, the reason you might choose (say) Python over Clojure for a web app is the ecosystem (libraries, frameworks, deployment), performance (is this a concern for your design?), the syntax (do you like it?) and tools support (IDE's, etc.).
> Obviously you can bring all functionality that the web demands to Go. A jit compiler might help, maybe some loose typing, a few other widgets ... and then, guess what? You turned Go into PHP.
You could say the same about Ruby or Python. Both built up a lot of web-centric libraries and packages. But neither have "turned into" PHP.
Yes, some languages reduce the barrier to entry for certain tasks. But that doesn't mean other languages are a bad choice; they likely have other benefits worth considering.
When you use Go with the AppEngine SDK your program is automatically recompiled on a request if it was changed. And you don't even realize it because Go compiles blazingly fast.
What does this even mean? Something like an Apache module (as an example in C) may or may not share memory depending on how it is written, but there is nothing that means it must share memory.
All sensible web programming environments have a stateless programming model (if that is what you meant). Some add state on top of that using sessions etc, but that can be in any language.
All sensible web programming environments have a stateless programming model
By default, Go doesn't. The default HTTP server in Go works by calling into your code via a callback, and you are free to maintain any state you wish across requests.[1]
I don't consider this a problem in Go, because the good module system and scoping rules mean that global state is explicit and obvious, and a good concurrency model means that accessing global state can be done safely. Global state can be useful and performant, so I'm glad Go lets you take advantage of it, but it might rule it out as a "sensible web programming environment" by your definition.
Yes, that is a fair point. Perhaps I could have better said that all sensible web programming environments give you access to a stateless programming model.
Yay, parroting a line about statically typed languages saving them from themselves. Typing and ahead of time compilation are fantastic tools for optimizing your executable, but I wish people would stop insisting that they write code with less bugs because the compiler made sure an apple was not an orange. Every statically typed language I've worked in had some form of generics to step around the inflexibility of static typing.
