Js as a backend language

I was going to make a joke but now you've ruined it.

If you wanted to "joke" that there are more threads that just aren't used, you'd be wrong as well. Threads are not unused if they are blocking.

false you fucking retard, polling isn't threading

>when will this meme end
NEVER BECAUSE IT DOESN'T BLOCK

Do you even understand the words you are using? Look at this fuckign diagram. Which part of "Worker threads" do you not understand?

Attached: Lbs9z.png (800x316, 21K)

Event handling is done outside of the JS engine. Who actually employs retards like you?

It's not as bad as you think.
The built in event loop means that the ecosystem is full of asynchronous, non-blocking libraries.
Other languages that only have event loops built as libraries aren't so lucky. Most I/O in other languages still works synchronously, which is a performance killer. It's not like you can just spawn a thread per connection, even apache realized that that was retarded.
Also software written for one event loop is usually incompatible with software written for another event loop. That's freaking dumb. JS doesn't have this problem.

You're oversimplifying things here. The worker threads are only used for certain things, like File IO which can't be done asynchronously, OS DNS resolution and also some long-running operations node couldn't let run on the main thread, like cryptography.

Many important things, like inter process communication, sockets (accepting, receiving and sending and higher level network operations), timeouts and console I/O all happen on the main thread in the event loop.

I have used JS, PHP, Python /w Django and most recently dabbled in Go for backend development, and so far I enjoy Node the most of them all.
The built-in module system and Express enables to painlessly write stateless, clean code; and I love the middleware approach to routing.
Compared to the frontend side of JS, you don't have to bother with Babel and Webpack either, it's actually more enjoyable on the backend.
That is if you don't use typing, which is easy to opt-in into using Typescript or Flow.

So I guess it's mostly retards that respew memes and not people who actually know how to use the language that '''hate''' it.

>I have used JS, PHP, Python /w Django
Good. So you have only used shit. vertx.io/ is superior.

>>Who thought this was a good idea?
Netscape.

>take node.js app
>create swarm of Docker containers
>connect it to swarm of Cassandra containers
>outperform every other enterprise configuration
>able to use cheaper hardware to drive down costs (alpine linux Docker containers)
>tfw

Attached: 1507096377587.jpg (379x472, 73K)

S-sorry ..

>profession, reasonable qualifier and a random insult attached at the end
never change Jow Forums

>take c++ 'app'
>create swarm of hyper-v containers
>connect it to san
>learn how bucketing actually works (faggot)
>outperform your shitty nodejs shit

>not writing native modules for Node.js
Sad!

don't pretend to be smart you retarded NEET, nobody uses that shit in modern web

>*overflows your buffer*
Nothing personnel, kid

because they use LCD products just like their end users
fix the bug, if you don't work for a meme company it will work out.
yes I want to write a bunch of boilerplate code to interoperate c to a DSL from an obsolete browser people stopped using 15 years ago, because we live in the 'everything is backwards' timeline.

Attached: glaugh.jpg (500x370, 59K)

>fix the bug
Sure, but the data has already been leaked.

Ask me how I know you don't know what you're talking about.

because python is better in nearly every way.

I probably don't know more than I need to know about node.js in order to know that it should be avoided.
in a testing environment.

how many processes are there? if 1, then it is polling and not multi threaded.

simple.

NodeJS is super chill for smaller CRUD apps. Scaling it up though to a bigger codebase would be a fucking nightmare, as is the case with any dynamic language. Another thing is if your app needs fancy concurrency or to use any math libraries you are fucked because JS is too brainlet for those concepts, you will struggle as is with all the async based libraries for DB access. There are serious and hard bugs in JS if you forget a function is async.

>thinking processes are threads
The state of Jow Forums.

>super chill
filthy opinion discarded!

>It's not like you can just spawn a thread per connection
why not though

who cares where you live when you shit out code 100 times faster than pajeets and javascript kiddies do?

literally one of the easiest languages to deploy and run and a lot of software/tools.

not seeing the issue.

>POZZIX AIO is a fucking joke
>only windows has proper async file io
>surprised when libuv uses multiple workers for OS features with shitty or nonexistent async support.

>takes an hour to CICD every commit once project hits 500k loc.
>moronic pre-mature optimizations done early cripple the architecture in technical debt
>shitty packaging makes it hard to integrate external work or projects.
>potentially insecure code may lurk.
>have to deal with constant toolchain upgrades that may cause subtle issues.
>not platform agnostic.

it's more correct to suggest something like Java, where the VM means you have real modules, build tools that don't suck, actual dependency resolution and virtually identical performance characteristics for most network applications.

Why are there so many standards in web dev? I don't even know where to start.

very high security concerns
people want to use the web and deprecate random crapshoot custom gui bullshit on each person's computer.
can't "break the web"

lots of reasons.

>v8 engine
how is tomato juice still the fastest way to run javascript?

You know those punk kids that post boomer memes? They system now.

>>takes an hour to CICD every commit once project hits 500k loc.
those are dependencies taking that long to compile(ie stdlib or boost), or you have disgusting header spaghetti. If I went to cppreference and copy/pasted every stdlib example snippet and compiled them all, it would probably be less than 50k loc but would take way over an hour to compile. Don't use stdlib unless your really need it and can pay the price.
>>memes
i don't understand your accent
>>have to deal with constant toolchain upgrades that may cause subtle issues.
msvc only has a major release every 2 years
>>not platform agnostic
the hyper-v container? that doesn't matter to anyone according to my experience.
>>potentially insecure code may lurk.
maybe an asteroid is going to hit earth, maybe I will get hit by a car, maybe I have cancer, maybe the NSA will backdoor my butthole anyway
>>shitty packaging makes it hard to integrate external work or projects.
if I guess what you mean, you think there should be a program that you type 'install wangblowswidget2' into, then go to your editor and type 'import wangblowswidget2' into, then type 'wangblowswidget2.blowhiswang()' into main(). Then you go home, right? and get paid for that? Am I understanding the state of Jow Forums correctly?

Attached: 1528480307607.jpg (500x332, 31K)

>the javascript interpreter (2M LOC) that I got for free from those kind jewish folks surely contains less security vulnerabilitys than your c++ program!
my sides

>if I guess what you mean, you think there should be a program that you type 'install wangblowswidget2' into, then go to your editor and type 'import wangblowswidget2' into, then type 'wangblowswidget2.blowhiswang()' into main(). Then you go home, right? and get paid for that? Am I understanding the state of Jow Forums correctly?

yes you fucking kid. literally every language has this in 2018. even C++ has conan but literally no one uses it only big shit (zlib, boost, etc) is actually packaged currently.

>don't use stdlib xd
jesus fucking christ.

it's very well tested and developed by google for the use in web browsers you absolute moron.

it's literally developed by some of the most well paid people on earth.

I've been forced to use node, Mongo, mongoose, etc. because devs were overly excited and got the sales guys going. They're all total shit. Ever since RoR got a foot hold around 2005 - 2006, there have been gigantic faggots pushing for shit that doesn't need to exist, and they NEVER finish what they started.

node.js, mongo, ruby, [insert current framework du jour here] need to go the fuck away. Anyone supporting them need to be purged.

>take C++ app
>compile with emscripten
>get js output
>avoid overcomplicating build process for the sake of (((cloud))) meme
Docker is a joke and I hope it dies

Attached: tumblr_p7fnsytbNp1wr60xso9_400.jpg (400x400, 16K)

it's hard to have a conversation with you when you're all the way down there licking all of those boots. I guess you have to keep going until they're completely clean, so I'll just leave now.

>self documenting and immutable containers are a joke and so is all the advanced tooling that automatically manages my cluster of containers for me

this is how I know you're a literal nobody retard.

>I work a for a literal who nowheresville company with only a value of a few hundred million at best and haven't seen the power of modern software development

maybe get a real job kid and you'll learn something.

>it's literally developed by some of the most well paid people on earth.
>these are the standards used by normals

Attached: asfdafasfsfsaddfas.jpg (232x217, 16K)

Attached: DY1iRezVwAAgFqw[1].jpg (745x589, 46K)

>>I work a for a literal who nowheresville company with only a value of a few hundred million at best and haven't seen the power of modern software development
woah there. I work for my own company and it's not even worth 2 million. I don't see how that's relevant though

>Don't use stdlib or any libraries. Just reinvent the wheel everything xDD
>Easy dependency management is stupid. Gotta be l33t and do it manually
Wanna know how I know what you are a larping neet or a 1st year uni student?

there isn't any package manager for native C++ and you sound ridiculous for suggesting it.
At the last place I was (((gainfully employed))) the subset of stdlib we could use was frozen (not allowed to add headers) and boost was verboten. They were also completely rewriting the part of STL we were using (yes, completely 'reinventing the wheel' according to you) for performance. Except that's really just 'making a better wheel' in the world of real development with resource constraints.

Attached: 1508287667711.jpg (2209x2921, 1.08M)

>there isn't any package manager for native C++ and you sound ridiculous for suggesting it.

Conan dipshit. and you're company is literally retarded reimplementing STL (STL is why my shitty code is slow, trust me I'm a senior dev who don't need no profiling). not surprising though. most of these literal who companies are ran by senior dev boomers who haven't found a new job in the last 20 years.

Enjoy your retarded technical debt and I'm sure bountiful security issues because you retards probably don't even have a good test and fuzzing framework or running god knows how many outdated tools and shit.

>most of these literal who companies are ran by senior dev boomers who haven't found a new job in the last 20 years.
haha it's on the fortune 500 and I don't have to work there anymore. What you're saying basically is 'I wouldn't want to have to deal with that' and I don't disagree.

Attached: 1408414619731[1].png (699x1041, 593K)

>'I wouldn't want to have to deal with that'

literally no one does because it literally doesn't work. I've worked for really faggy retarded companies who have done shit as dumb as fucking with major open source libraries and it got to the point where a whole project had to be made to undo all the custom bullshit work. it only took literally numerous "security failures" found by customers and third parties to make it clear that "maintaining" shitty internal forks or custom re-implementations was a really fucking stupid idea.

you stick to what your product does. that's literally fucking it and I hope that shitty "fortune 500" company dies.

>immutable containers
>hooray my virtualbox isn't magically changing by itself
what I'm saying is that you don't need a fucking server to compile and deploy your shit. If you made the code in the first place, you clearly already have the utilities you need to build and run it.

Sure, it has its use cases. If it's something where you have one application talking to another remotely, then containers make sense. That said, it still doesn't do much of anything that can't be done locally.

I'm tired of this industry fetishization of taking everything that can be quickly and easily done on your own computer and making some other computer do it remotely. In the majority of cases, it's unnecessary and cumbersome, and it creates a bunch of unneeded extra points of failure.

Attached: tumblr_p7fnsytbNp1wr60xso8_400.jpg (400x400, 19K)

Yes you do need a server because your server is a gate that preforms sanity checks and then either denies or hands off to some other part if the cicd process to move it through the release cycle

Who the fuck is letting devs build binaries and deploying them to a binary repo?

Jesus.

Literally don't even know what your green text is going on about either but containers are more than just build environments or simple run environments

>unironically using chill as an adjective
kys

Who cares how fast you code when it's all shit.

>Who thought this was a good idea?

The blue hairs with problem glasses. They learned javascript as their first language, thus it is the best language.

This, you can tell who is an undergrad CS student regurgitating opinions they think smart people say, or a generic code monkey who only knows at most two languages

Who said anyone was deploying binaries directly to a repo? How is that even relevant? What I'm saying is that all of this shit can be done locally, without extra network overhead and a bullshit impediment to what can and should be the fastest and simplest part of the development process.

The only use case you listed isn't a use case at all. Docker provides no features to do anything over a network that you can't do running on the host.

A few reasons you would want to use Docker:
>you can set restart policies to automatically restart containers if they go down (the process exits)
>you can scale your containers as you please. Works especially well in microservices architectures. Docker has built in load balancing capabilities and internal DNS
>you can build a completely fresh environment within your containers with its own OS, file system, dependencies, configuration, etc. Easily scriptable using dockerfiles. Without the overhead of a full blown VM (Docker containers share resources and the kernel with the host). A new developer can just compile and run applications within a container immediately after pulling the code without spending days installing dependencies, local certificates, changing config files, troubleshooting failing builds, etc.
>since the container is lightweight and standardized, it's great for testing as well as production deployment. No more "works on my machine" because your container is exactly the same as the container on a customer's infrastructure

I could go on. Docker has a learning curve and isn't worth using everywhere, but if implemented properly, it can be a great addition to your tech stack.

See

Attached: 5NPDwcy[1].png (795x442, 580K)

How do these async functions work at a lower level? They don't spawn a separate thread, do they? If not, how can you execute your asynchronous function while continuing on executing the rest of the main program flow at the same time? Do they somehow take turns doing "work" on the same thread or something? This has always confused me.

Let's take a look at javascript
1. It has weak dynamic types making runtime faliure the norm
2. Npm is terrible
3. Node is a heavy process used with little gains due to it's "concurrency" model
4. Tools for it lack the ability of enforcing interesting rules (due to it's type system)
5. Code standard is all over the place
6. Legacy mistakes kept in due to "don't break the web"
7. You can list more yourself

You need CI to make sure it doesn't break other things and to serve your binary. You need containers for building to ensure the build is pure. There are many more but I'll leave you to live in the delusion you've drawn for yourself.

Guix*

when the code itself is 100 times faster

I won't question it's a great way to check for OS compatibility, it's great for that, but that's a really specific thing to be good at, seeing as half the time the language+compiler you're using is going to dictate OS compatibility at the outset.

Frankly, I have never heard of a new developer spending "days" installing dependencies and troubleshooting failed builds. It can be a pain in the ass, but maybe an hour or two. but yknow that's just me in my department of 11 people where half of us are on different OSes. The shit works because we're competent enough to make code that works cross-platform, which is why we have our jobs in the first place.

Attached: 0cf.png (650x686, 249K)

Docker != CI
Docker can facilitate CI, but it is not CI

I didn't say docker is CI so read it again

No. What exactly they do depends on the OS, for linux for example it's poll.
You're not understanding the event loop correctly. The event loop is not concurrent, it's just asynchronous (i.e. only one thing runs at a time).
The easy way to test this out is to start a download in node and then immediately block the thread with some synchronous work.The download will stall.
In Linux, the event loop is implemented via epoll -basically, epoll is given a list of file descriptors (for sockets, pipes ttys etc.) to watch over.
Epoll will block the program until one of the file descriptors it watches for becomes available for reading or writing (or whatever else, it's pretty configurable) without blocking. It also has a timeout after which it will return to the program anyway, and that is how timeouts are implemented.
So basically, every time you open a socket in node, or http client or pipe or whatever and listen to it asynchronously, it gets added to epoll's file descriptor list. The program will only interact with those file descriptors when epoll indicates that it can be interacted with without blocking the entire program. So socket file descriptors only get used if they have data in the buffer, not while you'd have to wait for the other side to send you some.
Everything happens in a single thread. That's why in node, it's such a terrible idea to do any longer-blocking work on the main thread. Like, imagine if you have a node.js server serving 1000 people. In one of the threads, you resize an image on the JS thread, which takes 8 seconds. During those 8 seconds, the event loop can't continue and thus, no new connections can be accepted, no data can be sent or received from anyone etc - all must wait.Long, blocking work needs to be done either in separate processes (which can then be asynchronously interacted with via pipes), on the thread pool (which requires you to write a C++ extension) or at least chunked, so the event loop has a chance to do other things.

People who never realized there's more to java than spring boot

I'm fine with what JS is used for.
It's just that there is literally no reason to be using JS for it other than JS has been used for it and therefore it has the most support/libraries.

sorry to ask but i am still learning, what is Docker used for? i am starting to learn code and programming and a teacher just name it

is really Docker that bad?

spring is king

No. Docker is fantastic

they're spelling it wrong, google 'docking'

Audibly keked

Attached: GOOD LUCK I AM 7 CALLBACKS.png (795x442, 670K)

It would have been usable if there was an actual standard library present. But no, instead we got NPM and whatever the hell some pajeet college dropout wrote.

>Scaling it up though to a bigger codebase would be a fucking nightmare
The workaround for this has been microservices. Read, a hypervisor filled with VMs, each with its own Node instance. Think of the Linux philosophy in regards to coreutils and apply it to Node servers - one server VM per API function, with a larger VM linking them all together.

Of course, this usually ends up blowing up in your face after a certain point once the free AWS credits run out.

I wrote a nodejs program to extract files from a proprietary archive format that uses bzip internally. Reading things like headers, hashing filenames while taking 32-bit unsigned integer overflow into account, and just handling buffers was such a shitshow.

t. unemployed

single page meme needs to die

This was a great post, thanks for sharing.

Microservices are their own retarded meme and they also don't scale with a growing codebase. You're not really solving any maintenance problems with them since all the benefits are just from having clean interfaces between areas of responsibility. If you don't already have that then you're just not a very good developer.

The alternative at my workplace is Spring. I'll take node and angular any day.

>It's not like you can just spawn a thread per connection
fuck you, if the customer wants better performance and stability he can go buy better gear

Attached: 1530276932120.jpg (600x532, 42K)

what a bunch of generic nonsense

Stfu pls python is slow af not mentionning that the indentation makes it a retarded language for retarted people

>why keep things simple when you can sperg out and brag about it on Jow Forums