Which will shape the future of backend services and web in the future? (besides .NET and Java)

Which will shape the future of backend services and web in the future? (besides .NET and Java)

Attached: golang-vs-node-min-730x236.jpg (730x236, 14K)

Other urls found in this thread:

devdocs.io/node/worker_threads#worker_threads_class_worker
octoverse.github.com/projects#languages
blog.codeship.com/making-the-switch-from-node-js-to-golang/
medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b
twitter.com/NSFWRedditVideo

Node or it's improved version (Deno).
Javascript and Python are the languages of future and the "bare minimum" for the future generations.

.NET

>reading comprehension

Node with async/await and promises its unironically fucking amazing.

Attached: 68568686586848.jpg (1064x672, 491K)

both

This, just combine them, Go for everything heavy until Node adds proper multhithreading and Node for the rest

This is the correct answer. There are IPFS implementations in both languages and IPFS is the long term future of the web.

The Node Js and JS foundations are going to combine so good luck with Node going away

Both are the present of the web. The future is serverless.

Why the hell are people memeing Go so hard in the past weeks?
I swear, just 2 months ago Go was a thing that "existed".
It's not even like Go gained a lot of popularity recently, while it did grow in 2017, in 2018 the community mostly remained the same.

>denying the truth

what about php

>in 2018 the community mostly remained the same
its the fastest growing language on GIT

It’s dead

fug

Attached: 5ABEFB7E09CA46588D637A26A1A16942.jpg (225x225, 5K)

*implicits your parallel*

Attached: 3E2F58A6-11A3-41A0-9A7E-DEE077ABD734.png (1200x847, 15K)

*emits 2GB for intermediate results*

>besides the 2 things that actually matter, let's discuss 2 that don't.

Have you worked with serverless? You still need something to implement your lambdas or whatever the csp you use calls it.

If we assume Node as JS then Node is almost as big as Java

>not knowing .NET is the only thing that should be used

I miss it bros.

Attached: users.png (1152x826, 153K)

>its the fastest growing language on GIT
wat

Did you read what said? To an extent he’s right. I’m not sure about how it works with java or .net so correct me if i’m wrong but if you have to build your services from the ground up there goes 50% of your lambda time.

And you have typescript on top of that, at this point can we even escape from the js ecosystem?

Yeah that would be Rust, not Go, but they kind of want to deny the existence of the one similar but superior language.

can you go into more detail and give example tasks for each plox?

Attached: 1542007308990.jpg (680x850, 135K)

>its the fastest growing language on GIT
This is the power of poo lang shills

Please bitch. Those toy languages are today's BASIC, except at least BASIC programmers were closer to the metal and understood shit.

>proper multhithreading
Never. It can't be done. JS is single-threaded.Node is stuck with multi-process at most, and then good luck wiring an IPC mechanism of your own.

i dont know how "proper" it is but (((microsoft))) has already done a proof of concept fork of node with multithreading

Yeah I read it, and he's completely off base or simply hasn't been exposed to enough practical business systems to understand that "serverless" encompasses perhaps .1% of viable use cases and is ultimately a meme. The final destination is going to look more like a virtual actor model, but you need some degree of coherence between components within a system like that to achieve any reasonable degree of performance (latency being the major factor of concern here with distributed components).

If you mean Napa.js, it is just Node communicating with a bunch of V8 isolates, each one running its own stack. Communication between isolates means having to marshall-unmarshall the data. Hell even functions are serialized when loaded onto napa workers.

retard
devdocs.io/node/worker_threads#worker_threads_class_worker

This sounds strangely like the original problem with the GIL in python in terms of parallelism lol.

Use Mojolicious

>devdocs.io/node/worker_threads#worker_threads_class_worker
Pretty much the same as napa, or webworkers; you have a half-assed context where certain things are not available or don't work, and to communicate with other workers there is message passing.
So no, it is still not proper multi-threading. It is just workers to do CPU intensive tasks.
Call me when you can run arbitrary code and the 'this' variable is visible and shared among "threads" (kek, that probably creates a black-hole that engulfs the world)

>it's not proper multithreading unless it fits these arbitrary criteria
okay buddy

>arbitrary criteria
If by arbitrary criteria you mean everything you can do in every actual multi-threaded language but not in JS, then OK (inb4 Rustlets which are constrained by design, not by possibilities)
My advice for you: learn several proper languages, then come back to JS to appreciate the shit it is.

So what if they were? As long as you can get stuff done it doesn't matter. Well, at least to people in charge.

>learn python
>end up being a lesbian cake
>learn JS
>be shit and not having an anime ever.

Attached: fjsioj73jhse.jpg (225x224, 8K)

Uniqueness types could have solved it. Clean for web!

>besides .NET and Java
don't forget PHP, the unsung hero of the web.

Attached: php.png (280x280, 26K)

That's because nobody likes JS, Anonymous.

Node concurrency will always be limited by being built on callbacks that queue up on an event loop. You can use any long running functions in Node without blocking the event loop. Go is a good replacement for Node but so is Elixir/Phoenix. Phoenix very much feels like frameworks used in Node in that everything is middleware. The BIG difference being Elixir has real threads and so can handle large tasks whereas Node can only use callbacks on an event loop.

last i read about it it was praised, but i really havent used it

T.b.h i have to yet find one website that uses Node where its performance is shit

I never said its performance is shit, just that it can only be used in Single Page Apps as its event loop cant handle heavy long running functions

But thats completly fucking false

no thats common knowledge

Go, JS doesn't scale
No, async JS isn't the same as Go concurrency

You telling me a frameworks that runs a big chunk of Linkedin a gigantic "app" can't do multi page apps?

you dont know what a Single Page App is, you actually think that a Single Page App means the *entire* website runs on one single page

I just joined in this discussion and yes i actually thought that. Starting my journey with back-end and honestly chosing a language is hell and now after i started with node i see it shit talked and get defensive sometimes. I apologize. What exactly does single page mean.

Did he mean Github ?

Stop talking. You're confusing front-end with back-end.

To answer OP, I don't think Go has much future as JavaScript (typescript) is still more elegant. I think we will see mostly Node.js, with specialized performance-critical services written in Rust or Haskell/OCaml depending on circumstances.

>Muh multi-threading

Bitch nigga this shit is so fucking irrelevant it doesnt even matter

It means that the entire page does not need to refresh to make changes on the page. Like take Google Maps for example, you are doing a lot of interactive stuff with Google Maps but the page never refreshes and the page is making constant updates to the backend and then rendering it with Javascript in the frontend. Like all the graphical stuff that happens could not happen if you were just using the backend so you need a frontend framework to do all these animations. So Node works very well on the backend for supporting all this highly dynamic frontend rendering.

I see but now i am reading about it and big new web sites are single page apps so shouldnt Node work greatly with them?

>Ryan Dahl,creatorofNode.jsmoved to Go.
>TJ Holowaychuk,creatorof Express.js frameworkmoved to Go
Makes you think

Shame nobody else did and the language NEVER picked up

How about Django? Instagram runs on it and it runs just fine

>Main problem of Node is the lack of support of multithreading
>Builds another Node

Guy is a fucking retard anyway. Good riddance

Just use a worker then?

Not Node I hope, I don't want a language where the most popular packages are is-even or leftpad.

>Shame nobody else did and the language NEVER picked up
Are you retarded ? It's easily the most popular language of those released in the last 10 years (including Rust, Swift etc).

Just the hold it has on the container ecosystem ensures its continued success, which in turn spills over into web backend.

VertX

The reason people don't think node has problems is because
the apps they are talking about worked very hard on load
balancing, etc. Node is hard to use in production becuase
when it reaches its limit, it starts to lose requests, and then
completely crashes. Then there is the typing. Node has a fcking
Number type. Forget about accuracy, business logic in the backend
with different data types becomes lol.

Besides typing, just switching to go will make your typical
request 2x faster. If you look up startup jobs, a lot of people
are switching from node to go for a reason.

>backend in node.js, rust and haskell

what a terrible mess that would be

t. NEET

One: You meant github.
Two: You are wrong. It is actually Kotlin. You are double wrong because Go is actually being outpaced by Typescript as well.

octoverse.github.com/projects#languages

>Node is hard to use in production becuase
>when it reaches its limit, it starts to lose requests, and then
>completely crashes.

When did this actually happen with a website, because all the lack of Nodes lack of performance has never, never affected something using it from what i can tell

>Are you retarded ? It's easily the most popular language of those released in the last 10 years
Like this mean anything when every new language is a failure that dies in a couple of years lmao

>Forget about accuracy, business logic in the backend
>with different data types becomes lol.
Paypal runs Node if they can fucking do it then a shitty business app can do it too.

>If you look up startup jobs, a lot of people
>are switching from node to go for a reason.

A whooping 1 job for GO in my country

Node obviously.
Both are broken by design(go v2 is an improvement though), but node manages to fix most of these mistakes thanks to ES6, Babel and webpack. Node has huge package library for anything and together with async/await+classes+functional features, it creates really comfy language.

>async/await
This, amazing features desu. They make creating Async code easy as fuck

did u actually look? Plenty of examples.

Please post them

Theres no reason to go from java or c# to go, so what u have
is startups who hired cheap bootcamp grads who only knew
javascript having scaling problems, and switching to go.
If you dont have a strong startup culture, u have no golang culture.

Not advocating go here. Once you start writing go, you get
kind of addicted, which is why theres always a thread about it
even though it has like .4 % market share.

just say ajax you retard

>Node is shit because the people using it are guys who have been programming for half a year

yikes

blog.codeship.com/making-the-switch-from-node-js-to-golang/

medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b

Node is a hack on top of an event loop menat to handle async
events on one fucking page. I understand it works, but
theres a reason java and c# dominate.

Being good at node actually means being good at nginx / micro services

Thats not what i asked for, i asked for situation when Node clearly just simple plain dropped dead when a website had huge traffic

>blog.codeship.com/making-the-switch-from-node-js-to-golang/
>medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b

>Literally fucking who

bootcamp superstar doesnt want to hear he might have to learn
what data types are. wah wah

You did not search yourself, you did not read the articles someone else sent u

What are those scaling problems?

Also

>You did not search yourself

Of course i didn't, the burden of proof is on you

> always does minimum
> lives a masturbatory life in general
> wonders why no one wants to pay him

PHP