Golang is the best modern language for Web Development, General Systems Applications...

Golang is the best modern language for Web Development, General Systems Applications, and Distributed Systems (second only to Erlang/Elixir in that regard).

Prove me wrong.

Attached: fcf0693653f50a9db3d0ee7ec305c1d8.png (804x703, 61K)

Other urls found in this thread:

weave.works/blog/linux-namespaces-and-go-don-t-mix
databricks.com/sparkaisummit/sessions
github.com/ksimka/go-is-not-good
twitter.com/SFWRedditImages

>Prove me wrong.
weave.works/blog/linux-namespaces-and-go-don-t-mix

Packages eliminate the need for a namespace.

How do golang packages eliminate the need for Linux namespaces?

I've become quite fond of Go.

> the best modern language for Web Development [...] and Distributed Systems
Scala is simply better.
Maybe just because it had an earlier start, maybe because it just is better.

>no built-in metaprogramming
That makes it literally worse than C.

Goroutines are really great , had to make some websockets that deal with lots of traffic and this feature of the language really is the cherry on the top.

Sorry I jumped the gun, usually it's "generics this" "namespace that" "template nigger" stuff.
After reading that article, it doesn't seem to clearly implicate an issue with Go and linux namespaces. It seems to implicate a particular implementation of a Go library.
Their problem basically stems from bad concurrency practices or a misunderstanding of how goroutines actually work, and when or when not a new OS native thread is spawned.
Effectively, it seems to me, the way they wrote the program and underlying package would spawn non-atomic goroutines, but because the call is blocking, the go runtime environment automatically spawned a new OS thread, and the resulting error occured there because it was referencing the same namespace after this job had already completed.
Setting the GOMAXPROC variable to 1 would eliminate this, but it sounds a lot more like a race condition error than an actual fundamental problem.

Justify your claim.

Metaprogramming is unnecessary and you end up with big blobs of nigh-unreadable shit like with C++ templates, filled with ::: let & borrow mut &: ^^ my fucking ass.

It is, but try to convince retards of something that is actually good.

I started this thread to convince retards of something good. Go is good.

> Justify your claim.
I'll point out OP didn't either.

But sure, the user base and number of direct [and affected end-] users of Akka and Spark individually might rival the whole user base of Go.

And then there are the widely used web frameworks like Play or Scalatra that run many big web pages.
Plus of course you also got Twitter's scala stack and derivatives with a lot of third party users.

Basically, no real contest at this point.

Attached: logo-cloud.png (2400x400, 70K)

>second only to Rust
Fixed that for you.

I'm not saying Scala isn't unsuitable for some of these purposes, and it may in fact be better for a specific one
However, simply saying "This is better" doesn't really mean anything. I could say "Javascript is better" without explaining myself but that's very obvious not true.
*Why* is Scala better for these purposes? What strengths does it have over Go in those applications?
Common usage isn't a justification either. Java is used in all sorts of manners that it was never meant for. Just because it can doesn't mean you should.

Rust barely even has concurrency, it's not even feature complete with C. Golang may be a meme language, but Rust is an actual joke.

Just leave them be. They will never learn.
People will often argue FOR more complexity until their very last breath.
Adding features just sells better.
For the rest of us, lets just enjoy the language by actually writing code.
No reason to evangelize.

No I wanna argue with people I'm drunk
Stop taking my fun away :(

Why not just use C? Go makes some good design decisions but a garbage collector means it'll never be more than a toy language to me.

>*Why* is Scala better for these purposes? What strengths does it have over Go in those applications?
It has the better logo, is easier to program, and more successfully used on bigger deployments.

The real thing that is easy to see is that even just the speaker's list on the Spark summits 2017 (three of them) has a lot of the entities who have a lot of business in processing a lot of data:
databricks.com/sparkaisummit/sessions

And that Scala is used on in the back or front of far more large production websites than Go.

> What strengths does it have over Go in those applications?
OP first then. All advantages of Go vs all common languages. Yea, I don't think so either.

Go has what I would argue as one of the best GC's out their.

Because it sacrifices throughput for latency? It's a trade-off but not anything innovative or new.

Computationally, it's close to C++.
Nothing will ever be as performant as C because, well, C is C. Just like C will never outperform well written ASM. You just can't beat shit operating on such a low level without directly going to that low level yourself, in which case why are you bothering? Just use the one that exists.
Go's GC is also hilariously efficient. It even beats out C in some situations in terms of memory usage.

>logo
Okay yeah literally everything does, the Go logo is fucking retarded. Which is hilarious to me, because of how stupid it is, but yeah, fucking dumb.
>Easier to program
I would argue the opposite. The way Scala deals with variable definitions isn't particularly clean, you end up with types at the end of statements as well as in front of them and at the end, depending on the statement itself.
Go is strictly postfix, which fixes this. It also allows for multiple pointer declarations.
Ex in C int* num1, num2 means num1 is a pointer but num2 is just an int. In Go, var num1, num2 *int would give you two int pointers.

It doesn't sacrifice throughput by leveraging Goroutines.
}[/code]

>All advantages of Go vs all common languages
Also this is a terribly silly request. It's a conflation of the "Prove there isn't a teapot" conjecture with something that's actually here.
Golang is the best option for X. If you think LANGUAGE is better for X because of Y, thats easy to justify. Counterexamples are much more concise and easier to discuss that entire proofs.

>Sorry I jumped the gun, usually it's "generics this" "namespace that" "template nigger" stuff.
hmmmm...

Attached: 1522109712349.png (720x514, 580K)

Go literally has enums.
const (
SomeVar1 = iota
SomeVar2
SomeVar3
.
.
.
.
SomevarN
)

>imagine taking a meme this literally

Attached: 1521393484266.png (775x575, 201K)

> The way Scala deals with variable definitions isn't particularly clean
Where? Besides, Go has a lot of syntactic quirks and dumb issues. Not that I regard the whole list here as valid, but there is plenty silly to go around:
github.com/ksimka/go-is-not-good

More time consumingly - Scala's libs are overall just nicer [including the standard lib and most 3rd party libs], scala's sbt beats the shit out of gb / scons or other build tools, and a lot more.

>Also this is a terribly silly request.
No more silly to ask me this than OP that made the claim that go is best
> for Web Development, General Systems Applications, and Distributed Systems (second only to Erlang/Elixir in that regard)

>Metaprogramming is unnecessary
Pic related. Metaprogramming is a necessary evil.
More important however, reality is working against you. History shows that all programming languages sooner or later end up with some form of metaprogramming. The difference between them comes from the quality.
The least painful form are well done, but all-powerful macros that facilitate full, impure compile time execution. That may seem counterintuitive, but the alternatives are along the lines of:
a) External text preprocessing, like in C. At least the C preprocessor is standardized now, but it only came to be as an addon, because K&R also thought that metaprogramming is unnecessary. Java and C# are also pretty great at this.
a1) Feel free to additionally count in the average build system that does more than just compiling all source files as well. Often enough complemented by some general scripting language, so you have an all-powerful macro language by using another programming language.
b) Zillions of non-powerful helpers. Like in C++. When people don't think it through from the beginning they might just think that those two non-powerful features (think of basic templates) are enough. But without all-powerful macros, those will eventually pile up (like concepts, metaclasses) and be harder to maintain than just going for all-powerful macros.
c) Shitty runtime metaprogramming, think Python metaclasses and pretty much stuff Perl and Ruby do.
d) Shitty bytecode manipulations, sometimes when bytecode isn't even a stable API.
[cont.]

Attached: images.jpg (299x168, 10K)

As you can see, brainlets can't escape metaprogramming. Ever.
And golang is ripe for the picking. At the moment it is at hold, because some people have hope for the flimsy excuse of golang 2.0. However, I give it at least a decade until one of the following things will happen:
1. golang 2.0 will actually happen. Improbable, but not impossible, given golang devs have a history of adding important features too late
2. golang will be COBOLized, after all Docker is the only important thing written in it
3. devs everywhere will get tired of waiting and will continue to do what they always did in such a situation in history: fling billions of shit-tier, unstandardized text preprocessors (quite a few exist right now even) everywhere until some will get stuck and then you will come back crawling, opening McCarthys zipper with your mouth and wishing those faggots had integrated proper metaprogramming from the start

>I give it at most a decade
fixed

literally no generics in >current year, just use java and if you consider that too complicated of a language, im sorry but youre a hopeless brainlet even pajeet can figure it out

Attached: pssssssh.png (623x450, 35K)

>Generics are required
Leave your OOP headspace
Interfaces if you really need it

Just because metaprogramming allows lazy developers doesn't make it necessary. K&R are still right to ignore it. Its programming on top of programming, and you're only asking for headaches and mistakes. "But now I can do X!" yeah, which you shouldn't, write it normally.

Scala has type definitions either before, after, or in the middle of statements. I wouldn't call it clean, though it is explicit.
Also 99% of those articles are "Go is bad because it doesnt do THING that I really like! WAAAAH1"
I've read through those articles like 5 times and they're all just bitchy, cater-to-only-me bloggers.

>scala's sbt beats the shit out of gb / scons or other build tools
I don't know about standard libraries, maybe, but Go has hilariously extensive build tools, to the point of telling you cyclomatic costs and "hey you arent checking errors here lol". There's so many linters for so many specific purposes that somebody made a metalinter, and now you can just lint every single gotool all at once without thinking. Go has faults but its tooling is absolutely not one of them

Generics can be achieved through interfaces if you really, really need it. But 99.99999% of the time, you don't, so don't allow loose type conversion and runtime errors. Generics are not inherently good.

>Hypotheticals with no basis
Okay. It doesn't have thing-you-like, therefore it MUST be destined for obscurity. Gotcha.

That is obviously a constant senpai, that's what const stands for. It's like saying an array is a integer-accessible enum as well, brainlet.

Enums are aliased constants
Its in the damn word

>literally no generics in >current year, just use java and if you consider that too complicated of a language, im sorry but youre a hopeless brainlet even pajeet can figure it out
>C++ pushing their stockholm syndrome hoping Go will shit itself with templates
>every single programming thread

> Golang
Meme language to grow cheap unified labor for google

>Generics can be achieved through interfaces if you really, really need it. But 99.99999% of the time, you don't, so don't allow loose type conversion and runtime errors. Generics are not inherently good.

uh huh I didn't realize projects larger than fizzbuzz are the 0.00001%

go is pre-2004 java with green threads, there's a reason they added features since then you know

>Leave your OOP headspace
>Interfaces if you really need it
>Generics are OOP
>[tool for dynamic dispatch] is a replacement for [tool for monomorphisation]
OP, I'm not even but oh boy you sure are a brainlet.

>Just because metaprogramming allows lazy developers doesn't make it necessary.
Sure, OP. Better stop using that built-in generic array type and reimplement them the number of times in every package you need them.
>K&R are still right to ignore it.
K&R couldn't even make the rest of a good programming language to save their asses.
>Its programming on top of programming, and you're only asking for headaches and mistakes.
That's just enough reason you'd want the error message to come from the compiler, not from some m4/perl script or some faggot preprocessor.
>"But now I can do X!" yeah, which you shouldn't, write it normally.
You sure don't like code reuse. Better stop using libraries right now.