FUCK YOU /G/!

>>59603012
Obvious troll is obvious. And I'm one of the guys who thinks that there is nothing wrong with PHP or JavaScript.

File: 14d65caf0c96f287e067438c41e42729[1].jpg (21KB, 440x280px) Image search: [Google]

21KB, 440x280px

>>59603017
>PHP or JavaScript

the picture of (You)

File: IMG_0975.jpg (4MB, 4032x3024px) Image search: [Google]

4MB, 4032x3024px

>>59603140
I don't take selfies, cause I'm not a cunt, but here's a pic of my car.

Here, your free reply

>>59603140
There are no bad languages, only bad developers.

>>59603337
is it true that one of the front lights is an air intake and the other is just a fake lens?

>>59603337
>don't take selfies, cause I'm not a cunt, but here's a pic of my car.

OMG it's even worse you're a fucking redneck.

>>59603012
>There is literally nothing wrong with it
Yes there is. It's slow as fuck compared to Java, Go and C solutions and it has an awful problem where people cannot stop pulling dependencies into their projects for every little thing. It's also incredibly fragmented with build/launch systems out the ass and the code is spread across a bunch of active versions.

I run several self host node apps and I lose an hour or two of my life every time I have to update them because managing their million and one dependencies/versions/launchers is a waking nightmare.

If you want to build a small scale website quickly and you observe good development practices (not pulling enough dependencies to blot out the sun mainly) then yes, it's perfectly usable and even good. But let's not pretend there's "nothing wrong with it".

>>59603486
>this

also op please finish yourself.

>>59603012
Yeah, Node is fine, for what it is.

It's pretty much exactly what anyone could have reasonably expected from a general-purpose scripting environment based on JavaScript.

The most unusual aspect is the use of asynchronous APIs for *everything*. But the language does have the features to deal with the management of asynchronous execution, so it works.

The library situation is a bit of a mess. There's a lot of experimental frameworks out there, and the whole ecosystem doesn't quite feel mature yet. To deal with this, my approach has been:
1: don't use Node for anything huge,
2: try to use the minimum number of modules possible,
3: try to find the lightest-weight modules possible.

Like it or not, JavaScript is now the most important language of the web. JavaScript is here to stay, for the long term.

>>59603380
Yes.

i use node, i want to learn elixir/phoenix but it looks too alien, I don't know if I want to spend weeks/months getting good at it for my next project when I can just start with node right away, I've only ever used C family of languages and python.

>>59603012
>listening to /g/ ever
Serves you right, though I had my fair share of falling for /g/ memes too.
I unironically thought bloat was a valid reason to hate C++, Java and PHP until I realized that's almost exactly like complaining about the weight of a hammer.

>but look how lightweight and precise a screwdriver is!

And that's what Go, Lisp and C are: screwdrivers.
But if you insist on using a screwdriver for everything and believe that makes you are superior then you have autism.

>>59603449
Are you mentally retarded or just a fucking idiot?

>>59605092
>I unironically thought bloat was a valid reason to hate C++

Anyone who believes that C++ necessarily means bloat simply doesn't know enough about the language. And /g/ is full of people who don't know much about C++.

Almost all C code (with just minor modifications) can be compiled by a C++ compiler -- and the generated machine code will usually be identical to the C compiler's code. That right there is absolute proof that C++ doesn't need to have any more bloat than C.

And then, there are a bunch of features in C++ that generate the same machine code as the equivalent way of expressing it in C. For example, constructors and destructors -- if you write the equivalent functionality in C, the resulting machine code will be identical. The C++ namespace feature adds absolutely zero overhead -- a fact that can be proven by inspecting the machine code. C++ virtual functions can be emulated in C by using function pointers, and, although the machine code might be a bit different, there is no important difference in the performance of the machine code between the two languages.

Of course, there are a group of features in C++ that do add bulk and overhead. Obviously, using std::string is going to result in more overhead than char* strings -- but that's to be expected because std::string gives you some very significant additional features, like the ability to automatically expand the string to an arbitrarily large size. That's a luxurious feature, so, of course, you're going to pay a price for it. A good C++ programmer knows when he can afford to pay that price, and when he can't. If you find value in the extra features of std::string, then it's not "bloat" -- it's simply extra code to implement the extra features you need.

>>59603012
Enjoy your event loop hang ups.
>>59603584
>JavaScript is here to stay, for the long term.
That is, until GC support and DOM access will arrive for WASM and languages like C# and Swift will obliterate it in one product life cycle - which is about how many months for a web application?

>>59606031
>And /g/ is full of people who don't know much
Could've cut it like that.

>>59603337
That car makes it look like your trying to make up for something else mate.

>>59603337
>literal amerifat car
lmao

I don't get node.js too much. Why use node.js when you can just program in a different language and use a library or framework that communicates with client JS in a fluent manner?

>>59603449
What kind of semen-belching scum thinks any non-compact-car is redneck? Rednecks drive pickup trucks you mung.

>>59603012
nice played, jew