Why the fuck would anyone ever use this god awful language

I like cancer.

another day, another thread by the Rust Evangelism Strikeforce
back to "Hacker" "News"

It's got some good ideas. The type system isn't as bad as people make it out to be - although it is unintuitive.
I think Go suffers the most from it's verbosity. Anyone working on a large Go codebase will tell you how fucking annoying it is to type So. Much. Boilerplate. Lack of a decent optional type means constantly checking for nil to avoid a bad pointer dereference. Also, almost *nothing* is an expression, which leads to even more boilerplate.
And lack of generics means dumbfuck generated code for mocks and the like.

Also
>tfw no versioned package manager

It's not the worst language. It's comparable to pre-generics Java in most respects. If it got generics it would probably be an ideal introductory language. The only complaint I have that isn't the absence of a feature is the inconsistency of value/reference semantics.

Attached: golang.png (1500x1000, 57K)

They're just too stupid for C++.

it has a cute mascot

Attached: gopher.png (300x441, 25K)

Not sure, it's a hateful toxic language filled with a community of hateful toxic people.

dis

>Jow Forums calling the golang mail list hateful and toxic
Hmm

It's all hate.
the mailing list is hate
ycombinator is hate
Jow Forumsgolang is hate

golang people don't come in the middle they come in two very well defined extremes-
Purple haired sjw fuck
MAGA trumptard fuck.

golang makes even the most heated posts here look like well rounded arguments by normal people with fulfilling lives.
golang community is HATE incarnate.
There is no middle ground, join a side or be cast out by both.

Sure, but I actually legit hate go

lmao

Scheme and ML are ideal introductory languages. Go will never be one.

nobody cares about fp autism

>The key point here is our programmers...
>They’re not capable of understanding a brilliant language...
>So, the language that we give them has to be easy for them to understand
Rob Pike

it's thread creation idiot, it's the future old man

is from golang.sucks/ btw

scheme isn't fp

post a single example thread for your claims of the hateful go community.

inb4 you cannot because it's all made up lies

Attached: pussycat.webm (640x360, 1.87M)

>autistic about mutation
>no iteration, only recursion
>everything is an expression
sounds pretty FP to me

it has mutation. not fp

>impure FP is not FP

Sold.

>"impure FP"
there's no such thing

Your post.

I am not a member of the go community. I dont even know how to program hello world in go.

so I take it you just made it all up because someone from some go community put you into your rightful (faggot) place? (fag)

Yet another example of the hateful, toxic Go community?

Good standard library for writing network services.
Builds static binaries, which automatically puts it above most languages for deployment.
That would be Tcl.

It's free.

unlike C who's standards are behind paywall

>builds static binaries.
wow, blew me away. truly revolutionary

it's even worse, the dynamic linking support is awful

Convenience sells.

Goroutines are not threads. The runtime scheduler multiplexes them over OS threads, so they're much more lightweight

>>go routines
Fucking meme word
Coroutines + a simple scheduler = WOW SO AMAZING

Why isn't there an OS with native lightweight threads?

Goroutines are great. They're much easaier to work with and more flexible than OS threads.

All languages have their own standard grammar/syntax. I think was more referring to the standard formatting as provided by the gofmt tool (which I'd recommend using, though it's entirely optional).

>lightweight threads
What the fuck does this even mean?

Anyways, Windows has had NATIVE support since fuckign XP. It is called the win32 Fiber api

Linux also has ucontext which is a bit slower and apparently deprecated as of posix 2008 or something
Anyways it takes like 15 lines of assembly to do it so "native" support really measn fuck all as it is so simple to implement

Errors are values. They can be programmed, and they can be made useful: blog.golang.org/errors-are-values

From the introduction:

A common point of discussion among Go programmers, especially those new to the language, is how to handle errors. The conversation often turns into a lament at the number of times the sequence

if err != nil {
return err
}

shows up. We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two, less often than some would have you believe.

I kind of like it and think it is an OK language. However, I still prefer C when it comes to a statically typed compiled language. There are a few things I don't like about it though. I think some of the syntax is fucking garbage, particularly the prescribed single letter variable names and camel case. I feel like some of the syntax decisions, along with other decisions, were really chosen just to be different than other languages just so it could try to stand out more when compared to existing languages.

I feel like it is popular because somehow, while not perfect, C has gotten an undeserved negative reputation and most companies won't touch it with a 10 foot pole. Thus, Go is a reasonable alternative for someone looking for a statically typed compiled language. I think a large subset of Go developers really wish they were given the freedom to development in C instead but had to settle for Go. At least that is how I feel every time I use it.

Attached: 1526334711488.jpg (400x384, 30K)

Goroutines are essentially "mini-threads", which get multiplexed over OS threads by the Go scheduler. They are much less expensive to create, and much easier to work with.

I've actually found the Go community to be very welcoming. One of my favorite I've yet encountered (along with the Python community).

I know what the fuck they are. Why did you post this explanation with retarded words? Multiplex my fucking asshole
1) Malloc a stack
2) Put the stack pointer there
That's what it is.

"Cutesy names considered harmful"

Go's concurrency implementation is delightful. You should try it.

>You should try it.
I have tried it. I know what it is and how it works. What makes you think I havent't tried it?

It's a bit more complicated than that, actually. I invite you to have a look at the following:

morsmachine.dk/go-scheduler
rakyll.org/scheduler/

Kavya Joshi's talk on channels also contains a great overview of the runtime's scheduling and memory management with respect to goroutines (around 9:10):

youtu.be/KBZlN0izeiY?t=9m10s

>It's a bit more complicated than that, actually
Only slightly. The coroutines are scheduled by some scheduler that is based on linked lists and does work stealing. AFAIR they had the guy fro 1024cores.net write it for them

>>forced no bloat
>have to commit all dependencies to source control

no not at all but it usually is

>>have to commit all dependencies to source control
>What is .gitignore t. brainlet

There are k8s client libraries for other languages, but the majority of the ecosystem is indeed in Go.

how am I supposed to take someone serious when they are so retarded they cant just throw together a static site with some html+css and have to resort to some hosting platform and shit ton of unnecessary js

>pure fp
there is no such thing

it's good.

they are green threads mr semantics

they are green threads mr brainlet

Thank D*g I'm not the only one who gets bothered by this stupid buzzword term

green threads are just non-OS threads so it'd be silly to have the OS provide them

what i'm asking for is an OS that just gives programs actually decent threads so that that programmers don't feel the need to multiplex them into green threads

Go is a super comfy language.

>green threads are just non-OS threads so it'd be silly to have the OS provide them
No it literally would not be silly to do that. Windows does it since XP, and the variant of FreeBSD in the playstation OS supports them as well (called sceFiberSwitch, sce = Sony Computer Entertainment)

>what i'm asking for is an OS that just gives programs actually decent threads so that that programmers don't feel the need to multiplex them into green threads
You just need to write a scheduler abstraction like the Go langage has already done for you. It shouldn't be an OS feature.

I don't mind it go/coroutines but calling them not threads or mini threads is not accurate

yes that is the definition of a greenthread. you do understand the difference correct? the scheduler is just implemented in userspace rather than letting the kernel handle it. in many cases the performance is better

Who needs Dart of Go after they've put a major stake on the Kotlin.

Attached: unti324234tled.png (644x879, 1.41M)

I like it and hate it at the same time.

it only seems that way until you start to get out of RAM because it is consumed by duplicated code separately loaded into hundreds of processes.

All processes share the same physical pages. Duplication in RAM is non-existing issue. Plus it's good for debugging, not just runtime.

I'm afraid of it becoming popular and Google having influence in yet another area. Sound pretty neat to write though.

go is poo

github.com/kubernetes/kubernetes/tree/master/vendor
Kindly kys, I know what .gitignore is. I'm lamenting the fact that these are literally the recommended "best practices".

The next version of Go, which will be released in a week or two, has a versioning system for dependencies.

And before anyone says it, it's better to have the right implementation late than a bad implementation soon.

He prefers installing all the packages manually.

Dont you like hunting for C libs?

It already has a dependency tool called dep, unless I'm missing something?

It was never part of the official toolchain. It also has problems, according to one of the Go language designers.

So are they just integrating it with mainline or is there some new tool? Only issue I ran into it with was the aws-sdk would not work with it properly. But that was months ago.

No. it's a completely different implementation with a completely different dependency file. Look up vgo by Russ Cox.

>It is not necessary for interfaces to exist at runtime
What is dynamic dispatch

>the inconsistency of value/reference semantics.
There is no inconsistency. Go only has values, Go doesn't have references.

If they are implemented in the OS they're not lightweight.

>I feel like some of the syntax decisions, along with other decisions, were really chosen just to be different than other languages just so it could try to stand out more when compared to existing languages.
Clearly you don't have any experience writing compilers.

Go's syntax is actually sane to parse, which is why Go has so many more tools (goimports which automatically adds and deletes imports, race detector, etc.) than other languages. C isn't even a context free language for god's sake. C style type declarations parse in a spiral: c-faq.com/decl/spiral.anderson.html

How does mallocing a stack let you run code concurrently?

>an OS that just gives programs actually decent threads
That's literally not possible. Anything in the system namespace requires a syscall with huge overhead. You would first need to invent a hardware architecture that makes context switches cheap.

>I'm afraid of it becoming popular
Too late for that. It's the newest language in the TIOBE top 20

Something unnecessary that can be inferred at compile time when you have interfaces.
And an inelegant implementation detail when you have objects.

>dynamic dispatch can be resolved at compile time
Oh no, it's retarded.

Erlang does it better