Top 3 backend languages go

1) Elixir
2) Clojure
3) Python 3

Attached: 11-animated_gif-gif-mikuru-moan-yuri.gif (746x533, 945K)

Other urls found in this thread:

youtube.com/watch?v=xrIjfIjssLE
twitter.com/NSFWRedditGif

If you give sauce, I will agree with you.

lurk moar

tcl

Attached: tcl.png (654x1023, 65K)

>Dynamic
>Dynamic
>Dynamic
You might be retarded.

replace 3 with Go, much faster and as easy
you might've never written server backends in your entire life, but that's okay. just don't act like it sweetie

Go is great for hobby projects. Java for anything important.

php7

pajeets detected

>Hurr you don't know how to write super elite backend webshit if you think dynamic is an antipattern!
>Recommended a strongly and statically typed language one sentence earlier
You might also be retarded.

There is literally nothing wrong with jvm.
Just save some sanity and use Kotlin.

ScritBasic

Attached: 8QUEENS_SCRIPTBASIC.png (556x504, 21K)

>Java for anything important.

Attached: 1513453559090.png (644x500, 66K)

yes go is static typed, that doesn't mean dynamic is shit and static is the only way to go sillyhead

1) Node
2) Elixir
3) Go

>Seriously using Node
Lmao.

Uber is using python and node.js for most of their most fundamental microservices and it works fucking great. Paul Graham always adviced startups to use fast to market languages like lisp or python. Erlang is more than proven to work. Dynamic languages allow small teams to overperform bigger teams writing code in something like Java with Spring.
The biggest problem with Erlang / Elixir is that, at least until a few years ago, it was very poorly suited for big data because all the libraries are for the JVM ecosystem.

Node is an abomination but it just works. If you play sports node is like the star playing for your rivals that just wrecks your team. You hate him and he may be an asshole but you can't deny how good he is. That's node.

No, node is garbage and the only thing going for it is that retards who learned programming in a bootcamp and only know javascript can use it.
If you have a semi-competent team, there's literally no reason to use node.

What makes you think your opinion has any value when there are so many successful startups and companies using node with great success?
You may not like node. Hell neither do I. But if you don’t think it’s good then you’re being delusional at beat and just dumb at worst

Go
Nim
Python

You can be successful while using garbage technologies, just look at all those PHP based sites. And look at all the companies outsourcing programming to India. They are also successful.
Node is a bad option if your team is good. If your team is full of people who only know javascript from a bootcamp, there's literally no other option than node. And those people are usually cheaper, so all in all, it's not terrible for business.

But dynamic is shit and static is the only way to go. The only reason for dynamic to exist is so new programmers don't have to use toString() or parse(). That's the only advantage.

+1 dynamic sucks dick

Dynamic languages make writing garbage way quicker, but high quality code way harder. What do you want your legacy to be? What do you want to be hired to do?

Node is like Visual Basic in that it's fucking braindead to get working and it turns into spaghetti fast, especially when you have an army of first year junior devs banging on it. This is literally what all those companies are doing. They're not making nice things, they're making cheap plastic toys in incredible volume in hopes that sometimes one of their useless webapps actually become popular. Remember that for every somewhat successful startup there are tens of failures.

[spoiler]Typed Racket[/spoiler]

Java and node.js are still used? Enjoy your guaranteed vulnerabilities and data loss.

1) Z80 ASM
2) Malbolge
3) PHP

1) PHP/Laravel
2) ASP
3) Spring

python is near last place.
so you are wrong.

1) Rust
2) Rust SJW Edition
3) Rust

1) see peepee
2) sh
3) perl

if you know what you're doing you don't need anything else

>1) Elixir
Obligatory Erlang movie.
youtube.com/watch?v=xrIjfIjssLE

1) Go
2) Go
3) Go

there is absolutely no reason to use anything else

Completely wrong.

1) Java / Kotlin / Scala (Amazn, Netflix are mostly Java for a reason)
2) Erlang
3) C#

1) Lisp
2) Lisp
3) Lisp

C
Web Assembly
Assembly

Java, Javascript, C#

Anyone saying Go or Node.js never actually built something that is supposed to stand the test of time and scale both vertically and horizontally.

Go and Node are the retard monkey packages for bootcamp startups. Using them is a clear sign of a lack of experience and professionalism. It tells everyone that you are only capable of writing CRUD shit instead of mission critical data processing.

Haruhi Dating Simulation

> Kotlin
> C++
> Python

>and it works fucking great
Know what else works great? PHP
>Dynamic languages allow small teams to overperform bigger teams
You're giving scalability/maintainability for quick development, that is if we exclude testing. But then again, most startups don't even reach the stage to have this kind of problems.
>so many successful startups
They're using node because it's fast to develop and so ubiquitous. It's really a non argument how many startups use it.
>node is good
Good for the right job, but overall?
>single threaded
>cant do anything cpu intensive
>cant scale vertically
>js
Sorry but no.
What did he mean?
>everything is a dick measuring competition
What are you compensating for?

>1) shit
>2) piss
>3) shitpiss
It's A) Ada, B) Ada, C) SPARK.

Attached: HackerMasterrace.jpg (1500x1000, 274K)

Can you give me an example of mission critical data processing?

Where I work we use angular/mvc/c# for creating cruds

Lockheed Martin F-35 platform, with Ada.

Attached: FighterCat.jpg (640x600, 43K)

Scala
Go
Ruby

covers a whole bunch of use cases

some other contenders
java, php, crystal,erlang.clojure

don’t use
python, node, elixir

>GOTOS
BEGONE
BE
GONE

1)Go
2)Elixir
3)Rust

Go is unmatched as a server language, no other language is so easy to refactor by design and is so scalable with its easy to use built in multithreading. Go is the right backend language 90% of the time. Elixir for large permanent connection networking and distributed concurrency. Rust for speed.

>waaaaah
all the seething brainlets who wasted their career doing nothing but OOP with Java and C++ are pic related

Attached: e.jpg (480x640, 239K)

>cant do anything cpu intensive
Webassembly or bindings.

Which technologies do you use for your front end?

>Scala, Clojure and Java
>not Kotlin
what did you mean by this?

Id say Dart for very largescale frontend applications. But huge code bases for frontend apps are rare so Id say thats a niche. Id say Javascript is simpler to work with for regular frontends

I hate to make an opinion on frontend frameworks, thats all a matter of opinion although I like Dart better than Typescript so I would use the Dart versions of React and Angular.

>kotlin on the backend not master race scala
kek

>write shitty mess full of bugs in a dynamic, slow, interpreted language to be the foundation of your business
>have to rewrite the entire fucking thing if it ever takes off
>need to scale to billion instances before you get the rewrite done because you wrote the backbone of your business in a slow language
Just do it properly from the start and save yourself a bunch of headache in the future.

If i am doing a basic giftshop, is dart a good option?

nodejs

I hate both, but you're wrong if you think they're generally the cause of vulnerabilities, or are any worse than any other runtime.

Dart is an OOP language like Java, so I think its good for handling a large amount of state and logic. But for a normal CRUD web app I think its overkill to use Dart and much simpler to just use Javascript. Modern Javascript also has class based OO now too, its just that I think Dart is cleaner with large code bases.

lmao it's a language made for idiots. Go is purposefully crippled to be extremely unexpressive so you can cram retards through kode kamp, and have them write crud backends without them being able to hurt themselves with their ignorance.
If you really like Golang you might be a brainlet.

Scala's main advantages are slowly but steadily being built into Java with rolling releases, we're gonna be at JDK 12 in March
And what does it even have over Kotlin in the first place?

Is it faster and it works? asking sincerely

>The biggest problem with Erlang / Elixir is that, at least until a few years ago, it was very poorly suited for big data because all the libraries are for the JVM ecosystem.
Erlang/Elixir has its own ecosystems which is the OTP

Shinji/Misato?

Attached: misato shinji handholding 1.11.jpg (4907x3532, 1.48M)

You are correct

You are correct with the caveat that js/node should be reserved for unimportant slapjobs in your project, never the core.

Go is unmatched as a validation and business logic layer between a database and some http listeners, and not much more. Once you try to do more, you'll find that it's just extremely tedious. It's "easy" to refactor because it has a half decent type system, like any language worth literally anything. But the boilerplate and lack of generics makes constant mechanical refactoring a total chore compared to languages which give you better constructs in the first place. And a good threading model is nothing to brag about: Coroutines and the continuation passing style have been around since the 50's. Go's "goroutines" aren't even the first or best implementation either. There's a reason why everyone is cribbing from the C# async/await style and nobody wants to touch Go's channel bullshit.

1. C# (ASP.net)
2. PHP (Symfony)
3. Java (Spring)

The thing with Go is that "a validation and business logic layer between a database and some http listeners" covers something like 80% of all web backends ever written. Damn near any microservice fits that pattern, and it's a good fit for AWS Lambda or other FaaS platforms like Kubeless and Azure Functions.

Is it a good language for heavy computation? Probably not. But most people don't need heavy.

1. Go
2. JS
3. C

>Is it a good language for heavy computation? Probably not

Still better than PHP and JS and all those languages that get executed in a runtime, are interpreted or have dynamic typing.

Definitely. It's fast enough, and doesn't have the startup penalty of the JVM, which is why I mentioned the FaaS stuff - you get billed by function runtime, so fast startup pays for itself quickly.

Faster than what? It's certainly pretty quick, but once you transfer from the interpreted dynamic world into strong and (at least bytecode) compiled languages the differences in performance are rarely worth bickering over.
Does it just work? It certainly does. Go programs are fairly predictable and unsurprising. This is a nice characteristic.

However the above does not absolve Go of its sins. FORTRAN and COBOL are two very fast languages which just work as well. Nobody wants to use them because writing software with them feels like digging holes all day. Go's lack of expressiveness means you'll be writing the same code over, and over, and over again. Enjoy the grind.

Webshit is cancer and webshit backends which do nothing more than translate database calls are the worst kind of cancer. If most of your service is just a database interface then please consider that your service might be wholly pointless and/or might be better off as a local application.
If you're calling for Go to just be grease for the trivial calls you'd like to spin off into serverless functions, sure, it's good for that. You could just as easily use node or python for that though. There is nothing special about Go in that space.

Not 100% sure how JVM applications are ran, but if it's anything like FastCGI, there should be a list of workers that are always running, so that overhead shouldn't exist. I bet Java doesn't use FastCGI but some overengineered alternative, but it should use the same principles.
The days of CGI where a process had to be started on every request are thankfull over.

>muh webshit cancer
It's a perfectly cromulent web SITE design pattern. Not everything on the Web needs to be an application reimplementing half the desktop stack with 500 niggabytes of JS.

On Azure Functions you only pay the startup cost upon scaleout, which only happens when demand suddenly increases beyond your current warm capacity.
Not sure about AWS Lambda but I'd expect it to be similar.

If you're writing basic websites for a living then I feel very sorry for you.

Your whole post is just a bunch of FUD memes that get repeated over and over on Jow Forums about Go. I dont waste my time commenting on the Go hate threads that get posted every day because its all just raging lunatics. Im going to give brief responses to your post not because I want to argue the merits of Go, as Jow Forums is just too far behind the curve now to make it worth my while to even talk about Go anymore. But just because Im bored I'll make quick points so no one actually thinks I go along with what you say.

>Go is unmatched as a validation and business logic layer between a database and some http listeners, and not much more. Once you try to do more, you'll find that it's just extremely tedious.
This is a bunch of vague bullshit backed up by nothing. No one can give any facts or examples and just come up with "its bad because I dont like it" as there only reason for saying Go as bad

>It's "easy" to refactor because it has a half decent type system, like any language worth literally anything.
thats sort of a half truth, its easy to refactor because it removes class based types which has done nothing positive for programming

>But the boilerplate and lack of generics makes constant mechanical refactoring a total chore compared to languages which give you better constructs in the first place.
funny how you say generics and are afraid to use the word templates, templates are needed in Go, keep begging, we will never use them

>And a good threading model is nothing to brag about: Coroutines and the continuation passing style have been around since the 50's. Go's "goroutines" aren't even the first or best implementation either. There's a reason why everyone is cribbing from the C# async/await style and nobody wants to touch Go's channel bullshit.
youre really trying to hard now to come up with something bad about Go, Go multithreading shits all over C++, Java, C# or any other thread locking solution

>templates are needed in Go
*arent

>Elixir
Small Meme
>Clojure
Big Meme
>Python
Only realistic choice

1) C++
2) Python
3) Erlang
4) Go

node
go

>Im going to give brief responses
Nigga your post is close to the character cap.

>No one can give any facts or examples
Holy shit what?
>if err != nill
Bam, fucking dead and finished. Go is full of dumb shit like that spurred by refusing to include any features which could confuse code camp developers.

>its easy to refactor because it removes class based types
Go has "classes" in that it has strong types. What it doesn't have is inheritance, but it does have interfaces. The only difference between Go and Java/C# interfaces is that Go doesn't support explicit implementation of an interface, and instead just allows a sort of duck typed resolution.
Lacking inheritance is not a feature. Inheritance has been very widely misused due to poor education (and the availability of multiple inheritance in Java/some others, which I believe is an antipattern), but it does have use cases. The duck typed interfaces are convenient in a way, but I find the way this is all done rather sloppy. When you change an interface, type errors happen at calls instead of type definitions, which means you'll need testing if you're building a library which never actually makes a call that would be bugged by the change. I don't like when provability is moved from the type system to unit tests.
And for the record, idiomatic Java and C# refactorability is not harmed by inheritance since all public passing is conventionally done with interfaces.

>afraid to use the word templates
They are not the same thing. Templates have proven to be cancerous. Generics have proven to be incredibly useful. Incredibly useful.

>Go multithreading shits all over [...] any other thread locking solution
Go channels are implemented with locks. You have to do synchronization somehow. If your complaint is about having to explicitly lock in your code: Good news, async/await also doesn't require explicit locking and doesn't require the use of a channel either.

You seem to not have much perspective beyond Go.

based and wapppilled

>very poorly suited for big data
>JVM ecosystem
What did you mean by this?

Hadoop is almost entirely Java, as are other Apache projects of similar nature

The guy is high on the literally shitty air of Silicon Valley. He really believes that just because some companies (who are arguably blights upon society) have made lots of money by cramming hundreds of code monkeys onto a project, that means the language they used is worth something.

But that's 4 languages

rob pike made it for himself so if you think he’s an idiot you’re either donald knuth or an idiot

golang has some simplifications which make it good for some tasks and bad for others

it will be a long time, if ever, before kotlin has the advantages of scala such as good support for higher kinded types