You said:
> Hell, there's still a lot of 5.x deployments out there that work just fine.
forgive my ignorance but I was under the impression 5.x isn't actively maintained anymore?
984 karma · joined January 26, 2011
> Hell, there's still a lot of 5.x deployments out there that work just fine.
forgive my ignorance but I was under the impression 5.x isn't actively maintained anymore?
Nobody is saying that. The golden rule of API design is do not break your customers.
The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
Excuse me, where do you work? Do you not have a company policy about not using software that isn't actively receiving security updates?
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.
this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code?
I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal.
It just boggles the mind.
PHP should learn from that, instead of trying to repeat it (in slow motion)
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'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better?
No other reasonable language does this.
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.
This such a typical response of people who live in a bubble, and get angry when nobody else in the real world agrees with their insane ideas.
Just because people think PHP is garbage doesn't mean they don't know what they're talking about. In fact, in my experience, the hatred many experience people in the industry have of PHP almost always comes directly from having been forced to use it.
In my case, I've worked on several large PHP projects (100k+ sloc, developed over 10+ years by many people) and it's by far the single worst language and set of tools I ever used.
Literally everything from the language, to the runtime, to the standard library, third party libraries, etc. is just complete and utter amateur hour, and is done so much better in almost any other language ecosystem out there.
I'm glad you're somehow able to make it work for you, but don't pretend it's good. It's really not.
this is a horrible take, language semantics should never change in a backwards-incompatible way. This is API design 101.
The problem isn't that AWS does not let you manage limits, because they do, to some extent: https://docs.aws.amazon.com/general/latest/gr/aws_service_li...
The problem is that if someone has your root credentials, they can just change these limits and go to town.
While I generally agree with the sentiment of your comment, I would like to point out that the above is only true for green card holders. There are a lot of H1B/L1B workers stuck at bad teams with high amounts of pressure/stress and incompetent or downright abusive managers.
For them, leaving the company isn't an option because it means leaving the country and leaving a life-changing amount of money on the table and denying their children the advantage of growing up in the US.
You might argue they can switch teams, which is technically true, but this can complicate and delay the green card process, and vindictive managers often smear engineers with HR because people bailing on them makes them look bad. At Amazon for example, particularly bad managers will PIP an engineer to block them from transferring teams.
So while in general engineers are treated well and can choose where they want to work, I think we should also show some solidarity with our friends who don't have the same options that we do.
I don't either, but what I also don't understand is why in 2020 anyone would use PHP over many available vastly superior alternatives.
Other than keeping old stuff running, why do people keep beating this dead horse? I just don't get it.
There's a couple of sharp edges still but in general it just 'makes sense'. If you don't like TypeScript there are also bindings for Python and Java, among others, although TypeScript is really the preferred language.
Amazon cares, but Chinese sellers are paying Amazon customers to write fake reviews for them. There's an article about it here:
https://www.buzzfeednews.com/article/nicolenguyen/her-amazon...
This practice basically makes it impossible to tell fake reviews from real ones.
And then you go to stand in line at the local wholefoods to buy $2.5 local chocolate croissants and $2 kombuchas from a teller who earns $15/hour.
Tip well, my friends, tip well.
it's funny, I feel the exact opposite. I work on a team that maintains a digital catalog, and a lot of what we write is about taking in asset- and metadata files, asynchronously processing them, and then publishing that to a denormalized read-optimized data store. We often joke that we mostly take data from 'over here' and put it 'over there'.
All our stuff is in Java, and honestly, if you use Lombok to squeeze out the boilerplate, and a decent dependency injection framework like Guice or Dagger, modern Java really isn't so bad. Streams are clunky but they get the job done. We use Jackson a lot to serialize/deserialize Java pojos to JSON and XML, which is pretty seamless for us so far. The Optional class is again clunky, but it works well enough.
The thing for us though is that the problems we spend most time solving are just not really related to the language we write it in. The hard problems are much more around things like operations (cd/ci, metrics, alarms, canaries), performance (latency, load, etc.) and just the nuts and bolts of the business logic (what type should this new field be? what values can it take? how do we plumb this through to downstream system X owned by team Y? etc.)
I honestly wouldn't want to have to write this stuff in Python for a simple reason: I don't think I could live without static typing, which is a fantastic tool when you need to manage a large code base written by multiple people over multiple years. I can make a change in some package, do a dry-run compile of every system that uses it, and then see what needs updating. It gives me certain guarantees about data integrity right at compile time, which is super helpful when you're doing data conversion.
But hey, different jobs, different tools. Glad you found something you're happy with.
I work at a Fortune 500 company, and the only wall I have to scale when I want to use a library that nobody at our company has ever used before, is to get someone to check and approve the license (typically takes 1-2 days), and import it into our code repos.
I mean I see your point, but not everywhere is as bad as you make it seem.