honestly i haven't looked at laravel recently enough to remember the specifics (although others here seem to have), but 2 general stengths are (1) ruby is more consistent, intuitive and fun vs. php, and (2) rails has reasonable defaults, easy configurability on top of that, and a nice ecosystem of both built-in and community-built widgets. it's so fast to get up and running with rails.
but i'd pick php over js any day! (probably even over python/django, unless data mining is a core concern)
Which part do you see that is not performance in that benchmark which shown the average time? I have tried benchmark on my own and PHP took longer than RubyJIT.
Command being timed: "/usr/local/bin/ruby --jit -W0 nbody.rb 50000000"
User time (seconds): 249.30
System time (seconds): 0.58
Percent of CPU this job got: 100%
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:08.97
---
PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:52) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.11, Copyright (c) 1999-2018, by Zend Technologies
gtime -v php -n nbody.php 50000000
-0.169075164
-0.169059907
Command being timed: "php -n nbody.php 50000000"
User time (seconds): 248.02
System time (seconds): 0.49
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:09.82
Polish and refinement. Ruby's expressiveness and clean design make possible a level of elegance in Rails that I haven't seen in any other web framework. Ruby lends itself to DSLs much more than most other languages, Clojure excepted, and its meta-programming makes possible a number of shortcuts which help you to get a project up and running in record time. Add to that the magnitude of commits to the Rails project over its 14-year history and you have an ideal tool for SME web projects.
This is the Soylent hypothesis. "Processed food" as such is not the problem—it's processed food used as a delivery vehicle for as many addictive sugars, fats, and simple carbs as possible. I would guess that the bad kind of processed food is much more common because it's both easier to make and more profitable (flour is cheap; oil is cheap; protein is expensive).
The same hypothesis (that we can reclaim the idea of processed food for nutritionally complete foods) is also on display in a product like Vite Ramen which explicitly patterns itself after a nutritionally dubious staple food (i.e., instant ramen). I would expect to see more startups in this space in the next few years.
> It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people
"Non-technical" people who don't plan for maintenance costs to their software (including maintenance to keep up with dependencies like PHP) don't get a ton of sympathy from me ¯\_(ツ)_/¯
I've heard this criticism of Laravel a couple times and never understood it. I've been using the framework for years and have never had an issue with upgrades. There is a clear and comprehensive upgrade guide with each release, as well as a third-party package called Laravel Shift that can inspect your code and perform automatic upgrades in many cases. I've found there are only one or two breaking changes per minor version release (which seems reasonable to me), and they are always well-documented.
Aside from that, I'm glad you've highlighted Laravel, which—despite being the most popular server-side Web framework on GitHub—gets virtually no attention from HN. It's typical to use Laravel in the old server-side rendered Rails paradigm (which is still probably best for some applications), but I've had success using it to develop APIs as well. Core features like the ORM, job queues, dependency injection, email templating, etc, are very solid, and the ecosystem of packages around it is phenomenal. I would recommend it to any Web developer.
Laravel also as a lightweight version called Lumen for simpler APIs and things. It includes a lot of the features of core Laravel but has a more stripped-down application structure.
Traits are okay: React 'Mixins' which I mentioned in my parent post are basically traits but at the framework level, which allows them to be smart about composing/merging the use of framework functionality normally accessed by overriding superclass methods (eg. componentDidUpdate). Traits still have the composability issues I mentioned for React Mixins: how do you avoid collisions between the namespaces of different traits while still allowing some to compose others?
Hooks aren't _quite_ like traits or mixins or anything else. You can apply the same Hook multiple times and pass values between them. That's what makes them powerful.
Yeah, definitely a different beast. I've done things with what's basically dynamic scope trickery before now, though it didn't look exactly like hooks.
I still want traits because I've got very fond of doing class-with-read-only-members type stuff and being able to compose functionality together works really nicely in that regard
(nonetheless, I very much appreciate your efforts on elucidating hooks - I think most of the reason I'm replying this confidently is as combination of your articles and the reference docs :)
It's very slow and unresponsive. Any time saved with not having to reload the page is wasted several times over in the clunky UI, and the lags in loading data still remain.
The information density is much lower. It's harder to scan a page for its content because everything is more embellished. It's less focused on text, which IMHO used to be one of Reddit's best features. (Design feature.) And it feels very generic, like a basic Bootstrap template.
Mobile is nagware until I enable JS or use desktop mode. Blocked for being some goddamn frustrating now. I was formerly a heavy user, about fed up with the astroturfing, but this was the last straw. Life is noticably better now.
PHP has had optionally typed function parameters and return values since the late 5.x releases I think (current release is 7.3). Types are checked at runtime and throw TypeErrors if the declared types are violated. They can also be checked ahead of time by IDEs with code inspection such as PhpStorm.
The 7.4 release is adding typed class properties as well[1].
I maintain a ~75k LOC PHP codebase (using the Laravel framework), and we have almost never encountered type issues. The new style of PHP (and Javascript is heading in a similar direction tbh) is to write it almost like it's Java, but with the option to fall back to dynamic "magic" as needed. If you utilize the dynamic elements sparingly, and following widely understood conventions, the productivity-vs.-reliability tradeoff is highly favorable for many applications compared to languages like Java and C#.
P.S. I like Python, but I would argue PHP actually has a better story to tell about types these days. "While Python 3.6 gives you this syntax for declaring types, there’s absolutely nothing in Python itself yet that does anything with these type declarations..." [2]. Declaring types in a dynamic language only to have them ignored at runtime does not inspire much confidence.
Declaring types in a dynamic language only to have them ignored at runtime does not inspire much confidence.
Funny, I see it the other way; declaring types in a dynamic language yet only having them checked at runtime does not inspire much confidence. With mypy, you actually get static checking, so you're not dependent on your tests hitting the bug.
It would be far from the first HN article (or comment) that failed to make a distinction between "poorly designed object-oriented systems" and the very idea of OOP, design patterns, etc
