>makes concurrency super easy all over your code

>easy to use
>fast
>easy concurrency with Go routines
>loads in the standard library
>will be maintained because google made it

Why does Sup Forums hate this?
Is it because real world useful applications are written in it?

Attached: golang.sh-600x600.png (600x600, 91K)

Other urls found in this thread:

github.com/golang/go/wiki/GoUsers
blog.discordapp.com/how-discord-resizes-150-million-images-every-day-with-go-and-c-c9e98731c65d
twitter.com/SFWRedditImages

it has an extremely specific use case
also it's ugly af

98% of people who hate Go on Sup Forums aren't programmers and their only criticism of the language is that quote saying it was made to be simple. One of them will probably post in this thread. Try asking them to see their non-brainlet code to have a laugh.
The 2 other percent have legitimate concerns about its type system/generics/error handling/etc.

Go's concurrency model is shit. Sure you can launch corroutines easily, but there is no higher level system in place to reason about them. In the end you end up with code that is really hard to reason about.

it's like a less expressive but moderately performant python

if err
does become a little annoying I admit.
Well the use case is google style problems mostly.E.g lots of requests .

>>will be maintained because google made it
Tell that to Reader, Wave, etc.

lol no generics

are you really trying to equate consumer facing services with a programming language

Name an example of needing to use generics.

a function which could take more than one numeric type.

what are some successful go projects, i know docker was planning a rewrite from python to go but got bit in the ass by go's crappy gzip module several times and they probably couldn't even tell you why they chose go when all they do is shell out to standard utilities except bandwagon

discord was planning to rewrite some of their backend python to go but the performance gains were so moderate i don't even know if that's still happening

github.com/golang/go/wiki/GoUsers

Twitch use is for their chat box
The largest russian email provider use it dealing with 3 million requests per second. The list goes on.

>it's like a less expressive but moderately performant python

I agree w you that it feels a lot like python but its a little more than moderately performant its like a factor of 10 for most applications (of course use case performance could vary widely)

do you have a blog discussing the perf gains of the switch? I'm not doubting you I'd just be interested in reading it.

Bitstream

fuck you, Go is sexy af

blog.discordapp.com/how-discord-resizes-150-million-images-every-day-with-go-and-c-c9e98731c65d

containers

or anything that needs more than one type or multiple entries of the same type, really

a fucking list

lol no generics

Go is pretty fucking bad at abstraction. But it is at least 100x more productive than node for building web apps.

Here's a recent gripe with go, as you all know go puts the full path for every source file in the exe multiple times, yet when building for windows they remove the timedatebuild field (for repeatable builds which you can't do with filepaths in the exe) and they marked it as debug stripped in the PE header yet it's full of debug information.

Generics are fucking garbage and if you need them you're a trash programmer

Attached: java.png (128x128, 19K)

>data structures are fucking garbage
ok

>Media Proxy needed 60% fewer server instances to handle as many requests as Image Proxy while completing requests with much less variance in latency.

Looks like the switch to go was worth it to me, but still a good read thanks.

>java makes generics unpleasant so no language should have them
(You)

it's just not a good sign when the simple python implementation is faster than go's, might as well use imagemagick if go is going to make you work your ass off anyway

>c ffi in python is faster than some garbage collected, binary made with ancient and naive plan 9 tools.

gee really?

Because I have scala and haskell. I have concurrency for free as a basic feature of the language practically.

>>will be maintained because google made it

extremely rare that you will ever need/want this in practice.
if you want functions to automatically truncate floats for you, you are a moron.
if you want libraries you write to work on different data types, (ex. physics simulation library that can do fixed point as well as floats) generics are insufficient, (in the ex, you likely want to use float infinities/nans heavily, you basically end up writing more code to support types you'll likely never use because you think that generics make it better somehow) you need real metaprogramming 99% of the time. (you can actually do this with c macros quite nicely, usually)
if you want functions that have completely different implementations (i.e, integer & float sqrt) to be magicked together, you want function overloading & separate definitions, you just admitted generics would be pointless. (i shouldn't need to say this.)
cont.

if you literally are just too fucking anal to pick a single consistent type for your libraries and want to, for example, support sorting 16 different sizes/formats, i hate to break it to you, but c's higher-order "qsort method" is massively superior as far as cleanliness goes, and if it was inlined (which is fairly easy if it's not in the fucking stdlib, these optimizations are nothing new, and you can totally metaprogram to guarantee it if you want, which would still be the same method as qsort, just manually inlined), it would likely be faster, especially if your compiler is a cunt about culling generically generated functions (templates generate _blank_ many functions, all the symbols stick around till link time, linker isn't willing to/can't cull them, happens especially in projects using shared libraries a lot, where the "air gap" dictates that unless you go around with a death squad static-ing everything, you're gonna end up raping your lower level icache, since those functions internally could have been inlined and severely size reduced internally, but need to be exposed externally)

go isn't perfect but it's simply a better designed language than the alternatives.

>generics are bad, you don't need them
>but you can do a really hacky version of them with C!
The stockholming is real.

Data structures and higher order functions are the best use case of "generics".

I think this is a fair point, go tooling is fuckin awesome but at this point i've been a go shill in this thread lol