Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Especially anything to do with React.
Ubbe114638dI can sympathize with those emotions, what keeps you in that field?
What would need to change to improve the JS ecosystem?
As an outsider, all I see is new frameworks followed by new frameworks...
Latest one being moment.js. Kinda reminds me about the left-pad incident (hilarious!)
Also, people really, REALLY need to learn about simple best practices. Today's annoyance took the form of a package that's trying to be overly magical and caused me an hour's detour creating a PR to fix its shitty behavior.
This is a package used by millions of people every day, too.
Python shouldn't be used where performance matters, ever.
That's where it ends for me, personally. The language itself has grown to try to be something it's not (only exasperated by Typescript, which is an atrocious mess) and has an army of terrible developers re-inventing the wheel just with flashier logos and branding and more investor-ready buzzwords ("blazing fast" comes to mind) in order to be Unique and Bleeding Edge for Github clout.
OliverTramp7138dI think Laravel is much better option than using node. Node seems messy and weird... writing node, feels like I am writing really old core php app.
Point 1: First of all PHP has a build in persistent SQL connections feature.
In a multiple statistics dashboard page we do the simple from cache queries sequential but all numbers that require long running queries go parallel so the database gets them simultaneously (multiple databases servers actually :multiple readers).
This is a big exception though. All the other pages are so sequential by nature. Trying to do things async is just overhead. Have to admit didn't test it but just looking at the code id say the biggest win on some pages is 20% in some cases (splitting things up more here so there are branch mispredictions) but 0 to 5 percent in most. It's fast enough...
You got to be kidding me in cases where cpu performance matters Go has a huge advantage: it engages all cores without protocol overhead. In the stats overview case PHP does the same but with a lot of context switching. It has to do some heavy post calculations so it might still be faster than node. Go will optimise it by minimising context switching.
> First of all PHP has a build in persistent SQL connections feature.
Yep, that's what I meant by pooling.
> Trying to do things async is just overhead.
In which way? Async decreases overhead performance-wise. In PHP you don't have a means of doing it, but in Node.js it's built into the language.
> Have to admit didn't test it
So then you have no basis to tell me yours is faster.
> You got to be kidding me in cases where cpu performance matters Go has a huge advantage: it engages all cores without protocol overhead.
This is not a novel thing. It's called multithreading. Goroutines are very, very bad at this. Pinning a Go process to a single system thread generally outperforms multiple system threads.
> In the stats overview case PHP does the same but with a lot of context switching. It has to do some heavy post calculations so it might still be faster than node. Go will optimise it by minimising context switching.
This is nonsense. I have no idea what to make of it.
> In which way? Async decreases overhead performance-wise.
If the problem is sequential. e.g. the result has to be in before calculations can start or they are needed in the next query the performance gain is 0. Even though promises and async/await are not very expensive but they have overhead so yes than performance is actually decreased.
> So you have no basis to tell me yours is faster.
Actually I didn't say mine was faster. Quite the opposite. I said that just by I balling there is not much opportunity to fetch resources in parallel I based my estimate performance gains by using JS on that. Even when getting creative (fetching resources when it's unsure if they are needed) the gains are going to be negligible; except for the two 20% pages or course.
> This is not a novel thing. This is called multithreading.
I know right. To bad node is bound to a single thread... Perhaps there is some solution I don't know about but I thought you would need to do RPC to get multiple cores engaged.
> This is nonsense. I have no idea what to make of it.
We use threading in the PHP stats solution so we can have the queries and processing in parallel. There is no co-routine in it so a lot of context switching. Go has co-routines and a scheduler that optimises execution.
JFK422583133dLet me guess, you maintain the is-odd package?