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

111–120 of 281 posts

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

#111

Post by jstewartmobile »

majewsky wrote: post #102
jstewartmobile wrote: post #43

Earlier quoted context omitted.

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

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

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?

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

#112

Post by LOLOLOLO1 »

didibus wrote: post #29
noncoml wrote: post #9

Earlier quoted context omitted.

> 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

Scala, or C# ? There's Nim and D too, but I get the lack of big commercial backing could disqualify them.

Scala is a perfect example of how NOT to design languages.

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

#113

Post by fileeditview »

lloeki wrote: post #109
fileeditview wrote: post #95

Earlier quoted context omitted.

Even then you can go wrong. I've learned that first hand while trying to write some lower level networking stuff in Go. Also OOP in Go is perfectly fine.. it's just by composition only and without inheritance.

Many people were taught OOP the UML and Java way†, to which the concept of prototype-based inheritance is completely alien, while composition is not even on their radar. † Although they have their fair share of issues, this is not a jab at UML nor Java themselves, but the way things have been taught, terribly, for so many.

Yes that's true. When I was at university we learned about the concept of composition but the reference language for this 'software engineering' course was C++. The whole composition idea felt contrived at that point.

Some time later I learned Lua for fun and almost instantly understood what this whole prototype based programming / composition was about :)

TLDR: While I learned about composition at university, they failed to really show how it is used and what it is good for..

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

#114

Post by shak77 »

bsaul wrote: post #106
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).

In cloud time performance is simply a matter of cost saving. No matter what your needs are, if you're able to serve more request per cpu cycle or Mo of memory, then you'll save on server costs.

And yet we see web applications written in Python

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

#115

Post by coldtea »

noncoml wrote: post #9
klodolph wrote: post #3

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 , 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 experien…

> 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

Because Typescript (or Javascript) has more quality libraries than Haskell?

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

#116

Post by dom96 »

tobbyb wrote: post #46
klodolph wrote: post #3

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 , 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 experien…

A slightly different perspective. For the end user Go apps are by far the easiest to setup and use. Usually it's just a single binary to download. That is a huge advantage that can't be beat. Other languages usually need a large number of dependencies, with Ruby and Node, often an entire build environment, with plenty of potential for dependency hell and hours wasted. Some may advocate containers at this point, but i…

As far as I know this is only true for code written in Go. As soon as you try using C libraries you're going to have a non-trivial time statically linking everything. Isn't that the case?

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

#117

Post by dom96 »

psergeant wrote: post #16
noncoml wrote: post #9

Earlier quoted context omitted.

> 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

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

Have you looked into Nim?

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

#118

Post by mschuster91 »

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…

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

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

#119

Post by exikyut »

lloeki wrote: post #109
fileeditview wrote: post #95

Earlier quoted context omitted.

Even then you can go wrong. I've learned that first hand while trying to write some lower level networking stuff in Go. Also OOP in Go is perfectly fine.. it's just by composition only and without inheritance.

Many people were taught OOP the UML and Java way†, to which the concept of prototype-based inheritance is completely alien, while composition is not even on their radar. † Although they have their fair share of issues, this is not a jab at UML nor Java themselves, but the way things have been taught, terribly, for so many.

What would you consider solid references to learn sane OOP?

I have a vague working model of object orientation but a lot of the finer details go straight over my head.

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

#120

Post by barrkel »

fileeditview wrote: post #113
lloeki wrote: post #109

Earlier quoted context omitted.

Many people were taught OOP the UML and Java way†, to which the concept of prototype-based inheritance is completely alien, while composition is not even on their radar. † Although they have their fair share of issues, this is not a jab at UML nor Java themselves, but the way things have been taught, terribly, for so many.

Yes that's true. When I was at university we learned about the concept of composition but the reference language for this 'software engineering' course was C++. The whole composition idea felt contrived at that point. Some time later I learned Lua for fun and almost instantly understood what this whole prototype based programming / composition was about :) TLDR: While I learned about composition at university, they f…

JS mixin / Ruby module / C++ mixin style composition are less than excellent, mind - throwing all the methods from multiple locations into a single scope is a recipe for implicit dependencies. There's an assumption that you won't define any methods that the mixins also define, not only today, but in the future; and even more, you assume that a same-named method won't be defined in multiple mixins, not only today, but in the future.

IMO it's much better to explicitly reference all mixins, and compose by reference rather than by direct inclusion, unless the composition has strong reliance on the identity of 'this' / 'self' in its implementation.

Post reply on HN