Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Re: Moving from PHP to Go and Back Again

blog.breakthru.solutions

Post reply on HN
Print view View original

121–130 of 281 posts

Re: Re: Moving from PHP to Go and Back Again

#121

Post by jstewartmobile »

cft wrote: post #84
pjmlp wrote: post #80

Earlier quoted context omitted.

Since Xerox PARC, UK Royal Navy, DEC, HP Labs, ETHZ, Microsoft Research have implemented full stack OSes in GC enabled systems programming languages. At ETHZ Oberon workstations were used during a couple of years by several users across the department. Most of those attempts failed due to losing the political and financial wars of bringing them into the wider market, not because of lack of features.

very interesting. I would have thought that any practical kernel written in a language with a GC would either have unpredictable slowdowns or be exceedingly complex.

We already sacrifice some silicon for TLBs and other memory management features. Many older architectures sacrificed bits for tag information as well. Perhaps one day we will sacrifice a little more silicon to get performant hardware-assisted GC?

Or not.

Re: Re: Moving from PHP to Go and Back Again

#122

Post by barrkel »

j0rd wrote: post #86
mschuster91 wrote: post #61

Earlier quoted context omitted.

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).

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…

> 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.

Latency is additive; it's a sum() operation, not a max() operation. Yes, a large fraction of most web requests get eaten by blocking on IO, but everything on top of that adds up, and small numbers add up surprisingly quickly. And the more you try to be smart about that stuff, whether it's optimizing what you query, do extra caching, try to turn multiple DB roundtrips into a single trip, you often just trade IO time for CPU time (albeit lower). You still care about CPU performance.

Re: Re: Moving from PHP to Go and Back Again

#123

Post by lwansbrough »

mjevans wrote: post #108
noncoml wrote: post #104

Earlier quoted context omitted.

Aren’t JVM language equally simple? Just a fat JAR.

You're forgetting Java.

Java isn’t required for the JVM of course. Scala is pretty great. I’ll throw my hat in the ring for C# on .NET Core. Just need the dotnet binary to init, build, install, restore, run. It’s like if node included npm in the same binary.

Re: Re: Moving from PHP to Go and Back Again

#124

Post by royge »

pjmlp wrote: post #91
royge wrote: post #89

Earlier quoted context omitted.

This is not always true. Static linking with other language doesn't always have similar experience with Go. One of these is the compilation speed. With other languages you'll still have time to get a coffee break before its done.:)

Which other languages? Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go. There are lots of languages with modules support, with static linking and native compilation to choose from.

:D You're comparing turbo pascal with Go today? You're gonna write microservices and web applications with Turbo Pascal?

Re: Re: Moving from PHP to Go and Back Again

#125

Post by spdionis »

idoubtit wrote: post #98
j0rd wrote: post #86

Earlier quoted context omitted.

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…

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 bra…

> 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.

First of all realpath_cache_size is unrelated to opcache and has always worked well. The only problem with that configuration is that the default is waay too low for modern frameworks.

Also I think GP meant that now you can always finetune the opcode cache. The current opcache is built into php 5.5+ and just works. It works so well that there are almost no competitors because there is no need.

Re: Re: Moving from PHP to Go and Back Again

#126

Post by spdionis »

blowski wrote: post #100
j0rd wrote: post #86

Earlier quoted context omitted.

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…

Depends on the use case. I've definitely worked with projects that required a ton of capacity, because the realtime search functionality was booting the full Symfony framework every time someone typed in a letter. To get rid of those performance problems, someone builds a fragile mess of PHP. In that case something like Go or Node.js is a much better fit to the problem. But if you're building a big old MySQL CRUD app…

> fragile mess > or Node.js

/s ?

Re: Re: Moving from PHP to Go and Back Again

#127

Post by 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.

Re: Re: Moving from PHP to Go and Back Again

#128

Post by adventured »

tempodox wrote: post #59
maaaats wrote: post #10

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

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

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.

Re: Re: Moving from PHP to Go and Back Again

#129

Post by jstewartmobile »

edem wrote: post #79

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 (jus…

I came to it from embedded C, and would not call it a better C. Not that it is bad. It is just a wildly different use case.

The lack of a preprocessor alone (as ugly as that may be) rules it out for a great many embedded and cross-platform scenarios. The binaries are also fairly enormous. 10M for a shell util on a desktop may be good enough. Beneath that level, it is a deal-breaker and a scandal.

Agree with the straitjacket part though. Comparing it to something like Clojure, the best I could say for it was, "At least I don't have to deal with the JVM..."

Re: Re: Moving from PHP to Go and Back Again

#130

Post by pjmlp »

jstewartmobile wrote: post #121
cft wrote: post #84

Earlier quoted context omitted.

very interesting. I would have thought that any practical kernel written in a language with a GC would either have unpredictable slowdowns or be exceedingly complex.

We already sacrifice some silicon for TLBs and other memory management features. Many older architectures sacrificed bits for tag information as well. Perhaps one day we will sacrifice a little more silicon to get performant hardware-assisted GC? Or not.

That is one area RISC-V guys are looking into, with Jikes RVM.

"Grail Quest: A New Proposal for HW-Assisted Garbage Collection" (PDF)

https://people.eecs.berkeley.edu/~maas/papers/maas-asbd16-hw...

Also Intel did have hardware GC with i432, but the chip suffered from many design errors that made it quite slow.

Post reply on HN