Live data from Hacker News

Re: Moving from PHP to Go and Back Again

blog.breakthru.solutions

241–250 of 281 posts

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

#241

Earlier quoted context omitted.

One could equally remember that Java was a niche language in 2000 used by a few dot-com startups, and even today it has not replaced C++, COBOL, or Fortran. Languages don’t get replaced, people just don’t use them as often for new projects.

> One could equally remember that Java was a niche language in 2000 used by a few dot-com startups, and even today it has not replaced C++, COBOL, or Fortran. Ouch, the lack of historical accuracy of your comment is painful. Just a few points : - Sun Microsystem was founded in 1982, it's far from being a dot-com start-up. - Java was already ubiquitous by 2000, it was embedded in your phones, your credit cards, in you…

Well the size of industry was much smaller than it is today. Java kind of replaced or used in first place where people would have used C/C++ etc. Same is true for Go as lot of container/devops, cloud etc infrastructure is written in Go which would most likely be in Java.

Among the languages that came in last 10 years Go is most popular with exception of maybe Swift.

So compare to marketing juggernaut Java with billions sunk in by leading enterprise vendors Go is nowhere. But among non corporate driven language Go is definitely on top.

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

#242
post #213

Earlier quoted context omitted.

> If anyone's ever worked on a project where the performance problem was the language and not IO I'd be really interested in hearing about it, but in my career of making websites I've never ran into this problem yet. Our company's product is CPU bound, and our language (Python) is definitely inhibiting our ability to meet basic performance goals. I've done a few crude benchmarks and I'm confident that a rewrite in Go…

or alternatively break out the big CPU bound bits into an FFI language, i.e. C, Rust, Etc. That's why Python has these bindings. You can almost sort of do it with Go, but it's not easy, since Go has a VM as well.

Unfortunately, the bottleneck is largely traversing a massive, poorly-defined data structure. If you leave the structure in Python, then FFI doesn't help you much (probably doesn't justify the maintainability cost of FFI). Porting the data structure is a comparable amount of work to rewriting from scratch, so FFI doesn't gain us anything except maybe an iterative avenue toward rewriting.

In any case, the application is still CPU bound, thereby making it an example of a web application which is not IO bound, per the OP's request.

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

#243
post #213

Earlier quoted context omitted.

or alternatively break out the big CPU bound bits into an FFI language, i.e. C, Rust, Etc. That's why Python has these bindings. You can almost sort of do it with Go, but it's not easy, since Go has a VM as well.

What do you mean by VM? I don't think there's a virtual machine in Go.

Go doesn't have a VM, but it has a garbage collector and scheduler (its runtime) which makes FFI more difficult than languages like Rust or C, to the OP's point.

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

#244
post #213

Earlier quoted context omitted.

or alternatively break out the big CPU bound bits into an FFI language, i.e. C, Rust, Etc. That's why Python has these bindings. You can almost sort of do it with Go, but it's not easy, since Go has a VM as well.

What do you mean by VM? I don't think there's a virtual machine in Go.

There isn't I meant GC(Garbage Collector). Sorry.

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

#245
post #213

Earlier quoted context omitted.

or alternatively break out the big CPU bound bits into an FFI language, i.e. C, Rust, Etc. That's why Python has these bindings. You can almost sort of do it with Go, but it's not easy, since Go has a VM as well.

Unfortunately, the bottleneck is largely traversing a massive, poorly-defined data structure. If you leave the structure in Python, then FFI doesn't help you much (probably doesn't justify the maintainability cost of FFI). Porting the data structure is a comparable amount of work to rewriting from scratch, so FFI doesn't gain us anything except maybe an iterative avenue toward rewriting. In any case, the application…

Of course there are CPU bound web-app's. That the OP thinks otherwise is just ignorance. But most web apps are not CPU bound, most are IO bound.

You can start with things like Cython which will give you a modest boost over plain python. I agree it may not be useful in your case, but doing full-rewrites are generally awful, abysmal and a nightmare all combined. Sure, there are cases where you must for various reasons, but they should be avoided if possible.

That's the beauty of doing something like an FFI with C/Rust/etc. You can iteratively move that direction, get code deployed faster and get your performance gains, while also slowly moving into a full-rewrite, but it can happen gradually and you get all the perf enhancements during the re-write, plus you get code deployed in production faster, so you can get all the code tested, and make end-users lives much better in the process of your re-write, instead of making them wait until the bitter end and then finding out that X, Y and Z undocumented features customers were using didn't get included in the re-write.

Anyways all that said, it sounds like you know what you are doing for the most part, so my advice here may not apply to you directly at all, and that's certainly plausible. But I think in general it's fairly obvious to experienced devs that re-writes are an awful plan.

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

#246
post #233

Earlier quoted context omitted.

> I thought Windows was to move to .Net even and MS backed out in the end. If you bother to read Joe Duffy's postmortems, and talks he has made about Midori, you will get it had nothing to do with technical issues, rather internal political wars at Microsoft. Also Microsoft did not fully backed out, the outcome of Singularity became the MDIL compiler for .NET on Windows 8.x. Midori influenced async/await, TPL, .NET N…

In that case it sounds like you have a bone to pick with Rob Pike over Go. I suppose you can find him on Twitter if you want to settle your feud. I'd suggest to not bother when I have him on tape contradicting you. I did read Joe's blog, years ago. Your takeaway there also leaves you with a bone to pick with Microsoft, if it's just politics then you should be able to find someone in management at Microsoft to set str…

It doesn't matter what Rob Pike says regarding Go and systems programming, because Google, the company that employs him, has decided Go makes sense to write system components of Fucshia in Go.

That is a fact, easily validated in Fuchsia's repository.

According to you, Rob Pike should call management and let them know it is not a good idea to use Go for writing Fuchsia's TCP/IP stack.

You only read Joe's blog years ago, yet you missed the talks he gave.

Two years ago is not that long time ago,

http://joeduffyblog.com/2015/11/03/blogging-about-midori/

"My biggest regret is that we didn’t OSS it from the start, where the meritocracy of the Internet could judge its pieces appropriately. As with all big corporations, decisions around the destiny of Midori’s core technology weren’t entirely technology-driven, and sadly, not even entirely business-driven. But therein lies some important lessons too."

http://joeduffyblog.com/2015/12/19/safe-native-code/

"Over the course of 8 years, we were able to significantly narrow the gap between our version of C# and classical C/C++ systems, to the point where basic code quality, in both size of speed dimensions, was seldom the deciding factor when comparing Midori’s performance to existing workloads. In fact, something counter-intuitive happened. The ability to co-design the language, runtime, frameworks, operating system, and the compiler – making tradeoffs in one area to gain advantages in other areas – gave the compiler far more symbolic information than it ever had before about the program’s semantics and, so, I dare say, was able to exceed C and C++ performance in a non-trivial number of situations."

"Safe Systems Programming in C# and .NET"

https://www.infoq.com/presentations/csharp-systems-programmi...

"RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing"

https://www.youtube.com/watch?v=CuD7SCqHB7k

Around minute 30 he starts describing the uphill battle to convince other Microsoft teams to accept Midori achievements.

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

#247
post #41

From my point of view PHP 7.2 is a great choice for startups and with a small team, so build the product, make it run. If required then do some R&D to switch to go, jumping straight into go should cause some issue.

Good luck hiring actual software engineers and not the ones who just managed to get into IT during the SEO boom. They are probably less expensive than the Py ones, but they probably don't have much of a future either.

Still parroting that old trope, huh? The quality of an engineer is rarely dictated by their tools. You can be an excellent engineer with a shitty language, or you can be a terrible engineer with a great language.

I'll be the first to admit that PHP certainly has it's share of really bad developers, but what language doesn't?

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

#248

Earlier quoted context omitted.

I’ve given up on NFS entirely and just use one of the big 3 cloud file storage services. Out of 8 downtime events, 5 were related to NFS mounts.

Hmm. I don't trust any external CDN, to be honest. No matter which one you choose, you lock yourself dead into the vendor - should it decide to kick you off for whatever reason you're toast, but especially I'm afraid of doing a tiny mistake in AWS leading to accidental disclosure of private data. Such "hacks" have hit too many too big firms for me. Out of interest, what issues have you had with NFS mounts? I run a fl…

Eventually, NFS ends up freaking out and consumes all I/O on the client machine until it is rebooted. I suspect that this occurs when the underlying network is saturated, but don't have evidence of such. CentOS 6/7, NFS v3/v4, tuned every setting I could think of, and spent dozens of hours Googling and reading.

It may be worth mentioning that we had decent throughput with NFS. Roughly 10 writes per second (from 100kb-250mb) and 20 reads per second (IIRC).

We use rclone to do a daily backup from primary -> secondary cloud file store, and use a little wrapper function in app to switch which host we're pulling files from so it's not too hard to failover during an outage.

I do agree with you about vendor lock-in though, it's nasty stuff. At the end of the day it comes down to time allocation. I'm a one-man ops show with too many other things to do than to wake up with a Pingdom alarm at 3AM because of NFS.

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

#249
post #245

Earlier quoted context omitted.

Unfortunately, the bottleneck is largely traversing a massive, poorly-defined data structure. If you leave the structure in Python, then FFI doesn't help you much (probably doesn't justify the maintainability cost of FFI). Porting the data structure is a comparable amount of work to rewriting from scratch, so FFI doesn't gain us anything except maybe an iterative avenue toward rewriting. In any case, the application…

Of course there are CPU bound web-app's. That the OP thinks otherwise is just ignorance. But most web apps are not CPU bound, most are IO bound. You can start with things like Cython which will give you a modest boost over plain python. I agree it may not be useful in your case, but doing full-rewrites are generally awful, abysmal and a nightmare all combined. Sure, there are cases where you must for various reasons,…

I agree--rewrites are painful, and most web apps are not CPU bound. FFI does permit iterative translation, which is a great bonus, although I don't want to end up owning a bunch of C or Cython. Rust appeals to me, but I don't think my peers would agree. Not sure what we will end up doing, ultimately. :/

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

#250
post #127

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

This is brilliant satire because I can’t tell if it is truly satire or if it’s not. Leaning towards “satire” based on your last sentence. Let us all know if I was right.

Why can't I have my own outlook and priorities? Why can't I like what I at a casual glance at the Rust docs? When I say casual glance, I mean casual glance, and if I missed something really horrible, I'll find it soon enough once I started actually using Rust; but I'm not going to feel silly for something you can't even be bothered to point out.

People actually sit there and say not even having the option saves them discussions, and that's not satire? I program entirely for my own utility and artsy experimental purposes, so I don't care what is useful for teams, that is 100% irrelevant for how useful or comfortable a specific language is for me. Which is what my comment referred to, how much I enjoy, or not enjoy, writing in Go so far.

I didn't call the language bad, I even said I'm too much of a simpleton coder to to have much use for arcane differences. I just said that after not even having finished my first project in Go I can already tell you, without any irony, that this brace style being enforced is a deal breaker for me. I'm still finishing the project, you know. If people have all these great reasons for not minding the lack of an option and not even having a choice, why are they so insecure about one individual minding it? My comment went to +5 shortly after posting and is now at -2, I think that's just hilarious ^^

Post reply on HN