Hacker News Reader

Comment by that_guy_iain | Hacker News Reader

> But, really, I suggest using other tools. We have nicer tools now.

Debatable really. Within the web development space the options are rather limited in my opinion.

Options:

* Spring based apps - Downside JVM is a Resource hog

* Python, Ruby, etc - The web frameworks are in my opinion not as full featured. Same with CMS systems. Also requires more resources. Also have limited OO features.

* Go, Rust, etc - Really good choices for APIs but their web frameworks are also really lacking.

The tooling around PHP is really good and stable. The language itself, the downsides are very limited and the main one that remains valid is inconsistency of function parameters. The issues with bad code are generally the same ones that can be done in another langauge.

View on HN

> Downside JVM is a Resource hog

I have to disagree. The JVM is one of the biggest pluses and might be one of the most battle-tested pieces of software out there.

> The web frameworks are in my opinion not as full featured.

Again, have to disagree here. Django is by far one of the most full-featured, well-documented web frameworks out there (IMO).

> The tooling around PHP is really good and stable. The language itself, the downsides are very limited and the main one that remains valid is inconsistency of function parameters. The issues with bad code are generally the same ones that can be done in another langauge.

I agree here and I think with PHP 8 incorporating JIT compilation, I think the future looks bright for PHP. I think the biggest foot guns these days are to be found in the JS ecosystem...but again, IMO.

> I have to disagree. The JVM is one of the biggest pluses and might be one of the most battle-tested pieces of software out there.

Your points don't seem to conflict with the fact you need more resources to run a mimimal Spring Boot application than you would a Go application, a Python applicaton, a PHP application, etc. Because the JVM by default by the nature of how it operates needs more resources. I'm not saying anything other than that.

We use Asp.NET and it is a giant surprise how good it is. We are unix ppl, Linux & MacOS so not a MS shop at all. We deploy to on-prem and AWS so no Azure.

It's been so long since I've done ASP that it just when .NET was coming out. I would be interested in checking it out nowadays. WHen I last used it all the cool features were heavily coupled to MS products, is that still the case?

Not at all. We actually use it from F# with Falco. I am not sure which features you are interested in particular but the ones we like are the basic HTTP handling (requests, responses, etc.), a high performance HTTP server (Kestrel) and we use Falco's html engine as well. On the top of that there is a decent authentication and authorization solution.

Same here, the latest asp.net is definitely one of the best performing options out there (maybe except rust in this list), and C# is a great general purpose language to code in (despite the legacy that's in there, like the reflection going on in the framework. unfortunately).

Kotlin + IntelliJ is a neat mainstream option too. For those preferring a bit less legacy.

Do you deploy to Linux images on AWS?

I'm actually very interested in your dev setup. Do your devs use Linux machines? What IDE?

Great questions. I am going to write a detailed article about it because you are not the first person asking these.

We have two deployment modes:

- lambda

- ec2 instance

Depending on how you would like to target Lambda you have multiple options. On ec2 too.

We use VS Code on both Linux and MacOS. The tooling is kind of meh at the moment, Ionide is not ready for prime time we run into issues frequently with it. We are considering to switching to Rider soon.

https://www.jetbrains.com/help/rider/F_Sharp.html

* I do not have time to write your a detailed answer but I promise to get back with an article sometime this month.

Terrific, thank you!

I still use EC2 for everything, I haven't explored Lambda yet. I look forward to your article, thank you. Is dev.l1x.be where it will be posted?

Yes I am posting it there. Probably after a bit of a design update.

Java, .net, C#, typescript (not my favorite) are all commonly and often used for Web Development.

They are sane languages with large ecosystems and solid frameworks for web-dev.

The question is not can you use something else, it's are they nicer/better tools to work with. I haven't for example seen many things that can honestly compete with WordPress. When it comes to eCommerce, not many systems can compete with Magento/Spryker/Sylius. The list goes on. PHP is a top player in web development while being one of the most hated languages for a reason.

I've spent a lot of time using PHP professionally and then coding all my personal stuff in Python/Go/Scala/Kotlin/etc. I know the downsides of PHP and I know the upsides and I often prefer coding in other languages but PHP really does have it's place.

> I haven't for example seen many things that can honestly compete with WordPress.

I'm sorry? Compete on what parameters?

Almost all frameworks win, hands down, in developer-friendlyness from WordPress. Many, if not most, modern CMSes can easily compete on security or performance. Many CMSes will win in user-friendlyness - for distinct use-case even more so. Many web-frameworks win easily in versatility: there's no way you can build a solid payment-service-provider in WordPress, build a Bookkeeping app, CRM, project-management, etc in WP. Yet these are fine in Java, .net, Rails, Django or even Rust.

The only place where I consider WordPress king, is for standalone, reasonably simple, blogs. This is a giant niche.

* standalone: not integrated into CRMs, or editorial workflow software. reasonably simple: no complex editorial and publishing workflows. blogs: anything slightly more than simple brochureware, but simpler than an avera CMSes.

The fact you're talking about building a payment service provider in a CMS kind of tells me this isn't a conversation worth continuing.

Sorry for not being more clear.

I was saying this exact thing: WordPress is just a CMS, which severely limits what you can sanely do with it. You won't build a PSP in a CMS. That was my point.

I have seen something similar to a payment provider being done in Wordpress. The only silver lining is that the ledger was technically maintained by a third-party and WP was just the frontend to it.

Me too. And I've seen CRMs built in WP, eCommerce, an auction marketplace, financial dashboard, and so on. But, indeed, processing financial transactions through WordPress is amongst the most scary things I ever saw in computing.

  > not many systems can compete with Magento/Spryker/Sylius

I'm evaluating eCommerce solutions for a Magento 1 upgrade path. I'm already evaluating Magento 2 and Sylius, but I've yet heard of Spryker. I found the PaaS offering, but even from their Github account I don't see any PHP application that would be an alternative to Magento or something based off Sylius. If you have any links or further information I've love to know. Thanks.

> The language itself, the downsides are very limited and the main one that remains valid is inconsistency of function parameters.

Usually one would have an IDE's auto completion to take care about function parameters, and in any case PHP8 has named parameters now to reduce whatever confusion (especially when optional parameters come into play) remains.

Sure, auto-completion makes the code easier to write. But you can't make it easier to read.

Jetbrains shows you the name of the parameter while reading so that part is reasonably easy

> Downside JVM is a Resource hog

The fuck are you smoking? The JVM is one of the most mature, resource efficient, and fast language runtimes out there.

See, this is why nobody can take you people seriously.

If you're conversing with someone who believes that the JVM is a resource hog, then you are likely conversing with someone with decades of experience. I would phrase my opposing viewpoint in a more respectable manner, as you might have a lot to learn from someone like that.

> If you're conversing with someone who believes that the JVM is a resource hog, then you are likely conversing with someone with decades of experience

As someone who has actually read the JVM specifications many times, has actively worked on a JVM implementation, and has a pretty good grasp on virtual machine design, I beg to differ.

But hey, I'll take the bait, what makes you think the JVM is a 'resource hog'?

I no longer think that the JVM is a resource hog. In fact I implied that it was an archaic mindset by suggesting that someone who thinks so has been decades in the industry.

That said, many Java applications themselves are resource hogs. Even my preferred IDE, the Jetbrains suite which I love, are resource hogs. Perhaps I'm simply not configuring it properly, but arguably I wouldn't ask an end user to tune JVM parameters any more than I would ask a car buyer today to set his timing or tune his mixture.

> Even my preferred IDE, the Jetbrains suite which I love, are resource hogs

Ok, so you're saying that because a large, complex desktop application uses a lot of memory and is also written in Java that therefore the JVM is a memory hog?

Well then, given how much of a memory hog Chrome is, I guess we can all shitcan C/C++ as well.

Look, in any reasonable apples-to-apples comparison the JVM blows anything PHP has out of the water, including haxe, hiphop, etc.

And even if you write a PHP-to-bytecode compiler (e.g. https://github.com/jphp-group/jphp) then there are certain limitations to how fast and efficient any dynamically typed language can be. Look at all the shit V8 has to go through to do field lookups: https://v8.dev/blog/fast-properties

And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.

And if you really hate Java as a language, you can always use something like Kotlin.

> Ok, so you're saying that because a large, complex desktop application uses a lot of memory and is also written in Java that therefore the JVM is a memory hog?

Actually, no. They said they didn't believe that.

> And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.

I think the point you need to specifically define that the JVM needs to be well tuned kinda shows you know there is a grain of truth to the fact that you dislike so much.

And really comparing performance of a compiled language to an interpreted language is kinda cheating. Compiled should be faster.

From my experience I can run a Go application with the same performance requirements as a JVM application with less resources. For example, for the same requirements I had 50mb of ram assigned to a Go docker and 250 mb assigned to the JVM. I'm sure we all agree 250MB is not so much but that adds up. Then we get on to the fact it's quite common in the real-world to see lots of apps built on the JVM needing lots of resources, sure you can say that's the devs problem and if they just did it properly it wouldn't be the case but if so many people are doing it wrong then maybe it's being the JVM makes doing it wrong so easy. (Which was PHP's problem so many years ago)

> the JVM needs to be well tuned

You don't need to tune it to beat the pants out of a PHP-based solution.

Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?

> Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?

No, if I've worked at a shop with a large scale low latency PHP app, they aren't not bothering their ass with Java, no need. They clearly have a highly comptent dev team who know their tools.

The only time I've dealt with Java is when companies are moving away from Java because their Java app is bloated beyond hell. They have a dev team that aren't highly comptent and think switching languages will help.

If I was dealing with the two, I would most certainly expect the Java one to handle scale better. But if I'm at lower level scale I would expect the PHP one to require less resources. Once PHP starts to scale up it can be a resource hog.

The reality is the comptency level of your dev team is the most important thing.

A think you need to remember, the JVM can scale massively well but the majority of systems don't need to scale well.

Reply on news.ycombinator.com