This language is unironically great

It is unironically better than BASH script.

Not really all that great, though.

You forgot

>Lightning fast build times
>Easy cross-platform deployment
>Sub millisecond latency GC
>Great profiling/benchmarking tools
>testing built into the language
>no bloated "public/private/static" nonsense, everything is done by convention
>Massive standard library so no NPM leftpad shit

Fuck go is great.

>still violates DRY
>no co/contravariance
>no rank-N polymorphism
and that's only compared to java. compared to any other language it's even worse.

>concurrency model built into the language itself
If you've followed languages that are actually used for a lot of distributed concurrency like Java, Scala or Erlang/Elixir, you should have realized Go's implementation is not actually good enough; and that you probably need more than one model at this point.

>sane modern build system and packaging
It's reasonable, but it also ain't no mill/sbt. Still I agree this is nicer than average.

> avoids object oriented nonsense
That one is not actually good. It does lack ways to encapsulate code that isn't purely functional, and it's not a good purely functional language at all.

Who cares about any of that nerd faggot shit. Go write a context free grammar in haskell pencilneck.

The back and forth from gotards really is amusing.
>Go is fine without generics.
>Go is getting generics; generics are awesome now.
>Go generics aren't deficient, nobody really needs [everything generics are useful for]
and so on

Nobody said Go doesn't need generics except retards. The official word from the Go team was "We'd like to add them at some point when we can get the design right"

stop hating on Golang

Attached: 87368710.png (228x221, 9K)

Is there any more news on generics for Go 2.0? I like the mascot for Go 2.0 more than the blue thing

Attached: yammy.png (512x512, 292K)

And yet the current draft is even more deficient than Java - a noncommittal stopgap at best, a sepples style hackjob at worse.

I don't hate it, it's a better "scripting" language than python or bash script.

Beyond that, Go users mostly overestimate the language.

It's definitely not the salvation of parallel and/or distributed computing at all at this point, it's not even close to being a better C/C++, and so on. Either of the above will require about ten times more work to be put into Go before it even has a real shot at it.

They currently lack the clever boys that fixed this for Java.

Attached: history-of-java-32-638.jpg (638x359, 74K)

Go is an underdeveloped language bolted to a fantastic runtime. Built-in first-class M:N green threads and the emphasis of primitives and value types that are easier on the garbage collector than heap-allocated everything is a set of tradeoffs I wish more languages made.

>Lightning fast build times
This is false though. Sure the language is designed so that compilation time is near linear and there are no extensive symbol resolving and code generation, but for what it does the compile types are abysmally slow. It should be by couple of magnitudes faster.
>Sub millisecond latency GC
Until you hit the knee point, then it has awful coherency profile.
>Great profiling/benchmarking tools
Tru, the chrome profiler integration is good.
>no bloated "public/private/static" nonsense, everything is done by convention
I don't see how is the rule of making things public any better than explicit public keyword. I honestly like more when I can just search public iterate through list of exported symbols. There are private member fields which is kinda ugly.

It's pretty nice, wish there are any jobs where I could use it.

So go has no object oriented design? The fuck?

You know why they call it Go? Because it goes in the toilet.

Lol yes. This is typical behavior in programing circles where they rationalize every fucking thing about their favorite whatever. To what advantage they do that I have no idea.

>object oriented nonsense
How?

its not object oriented

Luckily they got go modules right aside from breaking every single IDE with that change.

However, the error handling plan they're rushing into 1.14 is horrible and example that the devs of the language is out of touch with the core principles of the goddamn language.

what does it look like and what's wrong with it?

>no generics
>great

>sane modern build system and packaging
there is lacking documentation on how the projects should be structured when you want it to work with go get and have multiple executables yet has a library
you can't use multiple instances of a library
the library is required to know its namespace
just how the hell is this sane or modern

There is no reason to use this pile of crap over Java/Kotlin+GraalVM

>If you've followed languages that are actually used for a lot of distributed concurrency like Java, Scala or Erlang/Elixir, you should have realized Go's implementation is not actually good enough

lmao Go is just a CCS implementation; study some theory you codemonkey

>just how the hell is this sane or modern

not being C++'s build/"package" system is enough

Because of Java programmers

>write generic containers
How often do you need to fucking do that? Write a goddamn interface or use map.

> you should have realized Go's implementation is not actually good enough
It absolutely is. Have you never used the language? Goroutines are a brilliant solution for imperative-based distributed models.

Interface generics cover 99% of use cases. The only people who bitch about the lack of full T generics are people who never used the language, or overuse generics in Java.

There's tons of documentation. The build environment is arguable the worst part of Go so you're right to complain about it, but you just have to "do it their way" and it will just werk. It's all expected to live under a known environment variable, you aren't supposed to just slap projects into whatever directory and expect it to work.

It's fucking stupid. It's really fucking stupid. But it makes sense in its own insane way.

Know how I know you're a Pajeet?

>Interface generics
protip: adding "generics" to the end of something doesn't automatically make it generics

>write generic containers
>How often do you need to fucking do that? Write a goddamn interface or use map.

Yeah, I prefer this:
func Vec2Float64(u, v float64) {...}
func Vec2Float32(u, v float32) {...}
func Vec2Int32(u, v int32) {...}
etc

Rather than
func Vec2(u, v T) {...}

It's generic just like passing Object to a function is generic. It's not full genericism but it allows for a subset of it.

I always see this argument and it always baffles me. I use glm constantly in C++ and it will either convert an integer into a float for me via templates, or it will outright require me to input everything as a float.
Why is this arithmetic boilerplate such an ideal target for generics? Just force the type to be float64 and people will have to add a whole two characters when initializing values.

Like it's not a good example. At all. There ARE good examples, but this isn't one. "Oh no now I need a new function for *every single type* that this vector has!" How about you just force a single encompassing numeric type instead, you dumb fuck?

This is your brain on Go

The word you're looking for is polymorphism. Please stop butchering CS more than you already are, gotard.

it all seems like you have never seriously used it for anything big

Not an argument.

Go back to CS221. Polymorphism isn't a hard and fast rule, you can have partial genericism in a language.

I use it every day at work. I don't think you've ever used it at all.

"partial genericism" is utterly meaningless - you pulled it out of your ass. "Generics" only ever refers to forms of parametric polymorphism, which Go interfaces definitively are not.

>There's tons of documentation.
I admit there are some good 3rd party documentation. Official website has almost nothing and misleading examples, those 3rd party sources claim it has been researched based reading go get's source code and other projects.
>The build environment is arguable the worst part of Go so you're right to complain about it, but you just have to "do it their way" and it will just werk. It's all expected to live under a known environment variable, you aren't supposed to just slap projects into whatever directory and expect it to work.
Which addresses nothing I've mentioned. I'm ok with GOPATH, env variables as configs, flat src/ directory and local vendor/.

You should realize how Interfaces work and how poor they are for performance. Often times they are a good tool for the job (e.g. for fmt package and most marshal interfaces), but for hot low-cost operations its terribly expensive (e.g. sort) and in data structures they destroy any cache alignment. Additionally in Go, escape analysis doesn't see beyond casts to polymorphic pointers and dynamically allocate everything.

>2019
>the bar is this low
we need James Cameron to embark on an ocean voyage to find the bar and raise it

I want a job building out Bitcoin and layer 2 infrastructure, or appendant stuff

Am I better off learning Go/C++/Rust?

I know Lightening Labs use Go exclusively

There's memecoin projects written all three. Bitcoin core is all c++ as far as im aware.

Learn rust faggot

Attached: am7ws98uk0v21.jpg (718x697, 77K)

>That one is not actually good

Opinion discarded.

It's garbage collected, so it's trash.

dis

It's clearly a good 'get stuff done' language, and that is its main selling point. It's not a language where you muse about the most elegant way of solving a problem as the features at your disposal in Go are so limited.

So a boring language, but clearly productive and therefore seeing a strong uptake:

Github:

language:go fork:false = 243,024 repositories
language:rust fork:false = 33,974 repositories

>Sub millisecond latency GC
>Sub millisecond
>good
A millisecond is like forever for a CPU.
And it'll get higher the larger your heap is.

>And it'll get higher the larger your heap is.
You don't need to scan the entire heap for garbage every cycle, thus you can keep latency low.

just imagine how much stuff are rendering and real-time physics engines going while also running at one frame per 7 milliseconds
dozens of microseconds in serial communication is a huge latency
1 ms pauses are for web shits

60fps is about 17 ms per frame brainlet. Not everybody needs a language to be able to write the next Uncharted.

are you too stupid to divide 1000 by 7 to get the 140 fps number?

for those who criticize it:
patches are very welcome.

Some book:
golang-book.com

Go tour:
tour.golang.org

IRC channel:
webchat.freenode.net/?channels=#go-nuts

If Go can get generics right, then it will be useful for the 1% of the time where it's needed. But otherwise I don't miss it, I'd rather generate the code for the 1% rather than shit up the entire language for the 1% use case

Also, news:
golangnews.com
reddit.com/r/golang

Jobs:
golangprojects.com

>muh code generation
literally how is this any different to templates

>it's a better "scripting" language than python or bash script.
That's setting the bar pretty low, though.

Because it's not a part of the language or compile process. I can generate the code using bash if I wanted. It also stops the compile from taking hours like C++ shit.

you can't patch deliberate design choices

that just means you get even more arcane compile errors when shit doesn't work

Are you actually retarded?

Are you? Do you like debugging code filled with mangled symbols?

Is this loss?

how do you write code that would be extensible by 3rd parties in go? without classes in general even

>external tools are the better solution
pro-tip: they are not. never were, never will be.

but of course

Attached: 1553862210308.jpg (554x554, 30K)

Unironically better than the original. Now draw a beard on it.

Golang is like google's version of c#. They hoard all of their code in their own equivalent of the old .net hoarding libs. Its like they haven't read history or something.

>Its like they haven't read history or something.
UNIX oldfarts designing technology at 11.

I don't use Go, but IIRC it has structural typing. So your function calls a method, and if the type doesn't have that method it would throw a compile-time error.

Compared to what, C++ and Java which require a dozen external tools to orchestrate compilation?

it's better than perl, which I'm forced to use

Types and receivers are Go's equivalent of classes. Go actually has lots of features of OOP languages, but it doesn't reuse OOP terms for good reasons.
Another example, Go has data hiding in the form of exported and unexported names.

No, compared to having them integrated into the compiler.

[F]

Things like this are the hangnails of an otherwise great environment. I don't understand why there is a fear to just make a keyword like "any" which is equivalent to interface{}, just like "iota". With all of the little wacky bits fixed up and a couple features like generics and a better standard build system, the language will be top tier.

nobody wants to develop anything in this language because it will be difficult and expensive to hire engineers to maintain it

>It's going to be difficult to find developers for a programming language that you can learn in a weekend and master in 2 weeks
Yeah... right

Reminder than passing empty interfaces has a huge runtime cost and you are at least 10 times better off copy pasting your definition for each parameter set needed.

>make + gcc vs. clusterfuck of go tools and GOPATH
Choice is clear

>omits enums and generics
>includes goto

Attached: B34E75B1-52AE-4D31-8D33-C601172B0D07.png (657x527, 34K)

>for you
you are a big guy

Attached: CIA x Bane.jpg (1051x720, 66K)

>for you

You're a big guy
youtube.com/watch?v=qIRmxBPHh_8

Attached: CIA eyes.gif (280x358, 2.18M)

>go build

Woah... too complex for me m8, I need a makefile and a build tool.

>go build
>uses the wrong library version and overwrites the old one
>have to debug the opaque build process
No I prefer knowing exactly how my build process works tyvm

but I have only seen trannies use it

I know you guys are stuck in the past, but get with the times, Go has modules now.

>I don't understand why there is a fear to just make a keyword like "any" which is equivalent to interface{}
Just do type any = interface{} you lazy ass-faggot.

fixes nothing about the awful runtime performance of using it and breaks all static guarantees

try looking for candidates based on "golang" rather than "python"