When I learned Haskell in college I was blown away by how laziness enables cool things like dealing with infinite lists or more performance even though the UX is exactly the same. (Apparently with Ruby there is the slight hint of adding the lazy method in between)
Later I found out laziness in the whole system by default leads to some difficult issues, which quite a few people seem to agree with. Simon Peyton Jones (Haskell co-creator) apparently has said "The next Haskell will be strict". (https://news.ycombinator.com/item?id=14011943)
That was SPJ being cute more than an actual indictment of Haskell fwiw. That quote gets misused a lot.
Laziness hasn't killed Haskell's usefulness. However, it is something Haskellers take for granted. I can't tell you how many times they "just turn on -XStrict" and are surprised their program gets slower.
I have about 7 years of professional Laravel experience. I think it's quite slick! There is one aspect I haven't seen mentioned here that frustrates me: the community is quite eager to make new shiny things and forget about existing things. I feel the core framework doesn't get a lot of love anymore, and the same for some other packages. Something like Homestead got introduced as a huge thing, but got relatively quickly replaced with Sail and Valet it kind of seems. (Yes, they have a bit different corners, but I would say it doesn't justify a complete package) For authentication you have multiple packages that were introduced as the holy grail but now sit in an awkward spot with each other, and similar for frontend things packages.
Another small frustration for me is all the huge adjectives being used:
- "Laravel Horizon provides a beautiful dashboard ... "
- "Laravel Jetstream is a beautifully designed application... "
- "Laravel Octane supercharges your application's performance..."
- "Laravel Prompts is a PHP package for adding beautiful and user-friendly forms ... "
- "Laravel Reverb brings blazing-fast and scalable real-time WebSocket ..."
- "Laravel Sanctum provides a featherweight authentication system ... "
- "Laravel Telescope makes a wonderful companion ..."
- "In other words, Valet is a blazing fast Laravel development environment ..."
I think it would we wise to do a bit of a cleanup and merging of official packages, and to not forget about the core framework. I think Symfony shows you can still do great additions even after many years like Targeted Value Resolvers [0]
You can see all the official packages clicking the "Ecosystem" button in the header of laravel.com
> the community is quite eager to make new shiny things and forget about existing things.
When I got into the Laravel ecosystem I had high hopes for all packages made by Spatie (Belgian Laravel agency). Later I noticed that the packages aren't all that great (or: very opinionated, less idiomatic) and that I fell for their great marketing. The packages sometimes are more of a self-promotion device. Also some of them are open core only (for instance media library has a corresponding media library pro).
Relating to your other point they aren't only "created" but "crafted" as so many other "artisan" in the web programming space, maybe especially in the Laravel world :)
So, if working with Laravel be sure to take everything with a huge grain of salt.
Next time I'll start a PHP project I'll probably go with Symfony.
> I think it would we wise to do a bit of a cleanup and merging of official packages, and to not forget about the core framework.
Isn't this an issue that most enterprise frameworks end up with?
For example, if you look at the Spring ecosystem, there's also quite a few packages: https://spring.io/projects and https://start.spring.io/ (if you click on the "add dependencies", it integrates with a lot of stuff)
The RFC for DNS-over-TLS [0] seems to indicate that tunneling DNS requests through a TLS channel has no effect on the potential size of the payload returned.
In Europe there are a few options which let you pay with your bank account without a credit card. I tried to look up all the things Wise supports, found part of the list:
I find it quite odd and funny that the author specifically mentions Google, and his script has a function `def google_it(query):` but then in the function he uses DuckDuckGo. Is the author ashamed, or does he expect people to not trust DDG?
The Mozilla issue is labeled as "Position: Positive" and there is a comment that says:
> We're supportive of View Transitions, but since it's a new capability for MPAs in particular, we think it's important that the solution works well for MPAs and that it's consistent with the solution for SPAs. As such, if design changes are needed for the MPA use case that also affect SPA API, the latter should be updated as appropriate even though it has shipped. In other words, we think it would be bad for the SPA and MPA APIs to diverge or be inconsistent.
I don't think that's undecided. More like, "positive with some reservations".
edit: When I think about it again, perhaps you are right given the issue is still open (but also "ready to add").
edit2: Thinking about it more, I like the open process and all but perhaps such discourse should be private before being finalized as early commenters from Mozilla can have a premature influence on public opinion.
> but perhaps such discourse should be private before being finalized as early commenters from Mozilla can have a premature influence on public opinion.
No, it shouldn't. It's a good thing all discussion is happening in the open. See how Firefox devs still have their reservations but Chrome already shipped it to prod completely ignoring any such reservations.
I agree with my sibling comments, but want to add that nowhere does TS imply it has it's own stdlib or anything. If you type map, you know fully it's the JS map that's going to be executed. I don't think TS ever wants or could replace the JS stdlib.
Some people might not know this yet, the common idiom is to have the default value be None, and then start your function with checking if it's None and initializing to empty list.
Later I found out laziness in the whole system by default leads to some difficult issues, which quite a few people seem to agree with. Simon Peyton Jones (Haskell co-creator) apparently has said "The next Haskell will be strict". (https://news.ycombinator.com/item?id=14011943)