Memes aside, what's the deal with golang?

The tooling is really great: gofmt, go test, go doc, go vet, guru, etc.
High quality crypto in the standard library is also fantastic, no other language does it this well

I see it's not C
>inthetrash.webp

i like the mascot

I've worked with Python for 4 years and Java for 7.

I tried Go over the past two months and I'm hooked! I love the error handling, it actually provides you with a way of thinking that makes your program robust and easy to read.

The one problem I've had is lack of generics, however there is likely a very good reason there isn't generics. It resulted in me copying and pasting a lot of code and modifying the types for a API client libraries I'm working on for ConnectWise Manage and IT Glue. While the code is more verbose because of this, I've found it had the added side effect of making everything written with intent and really made me get the implementation down right before being able to proceed with using it.

"Don't *snicker* be evil!"

>however there is likely a very good reason there isn't generics.
There is a page on it that explains that Go is meant to be as simple as possible because it's a language intended for "young Googlers who can't use brilliant languages"

(Reasonably) performant
Don't have to fuck around with manual memory management but still have access to pointers (not """references""")
Slicing, something most modern languages conspicuously decide to not use
UTF8 encoding by default so spring parsing and manipulation isn't a godawful nightmare
Goroutines
(Generally) extremely memory light
Toolchain is incredibly
Clojures, first class functions, and highly extensible typedef systems offer a lot of flexibility
Goroutines
Syntax is extremely clean
Smartly designed interfacing system that enables enough pseudo-genericism for 99% of use cases
Maps are a built in type
Channels
Goroutines
Closest-to-source error handling is tedious but ensures you catch problems immediately as they arise instead of debugging through 12 stack layers in a try/catch block
Multiple assignment/return system is super handy

It's not going to replace C/++ in terms of raw power and it's not going to replace Java/C# in terms of OOP enterprise design, but it's a happy middle ground. Goroutines are also fantastically well designed and enable stupidly concurrent programming without the need to plan everything out ahead of time, and channels help enable minimal race condition opportunity because now you can safely share data without needing to mutex-lock-wrap 16 functions
Jow Forums shits on it because it won't fuck you in the ass like C and it's not "import solution" like python. Also the "simple language" statement is constantly taken out of context.
I use it for most of my side projects because it's just so comfy and clean to use.

Actually listen to the talk that statement comes from. It was designed to be a language that anybody with a vague understanding of C/++ could use without needing on-site training on how to not fuck it up.
It was explicitly designed around the idea of "There's a right way to do it, and this is it", which is also very C-style if you're not an insane person.
Contrast that to Java, C++, or just about anything else, and the myriad of ways one can accomplish something leads to unmaintainable, unreadable, write-only, WRONG bullshit. C++ is especially notorious for this (have you ever googled how to do something you thought would be trivial in C++? Nope, no STL implementation, here's 16 wildly different, wildly overcomplicated ways instead!)
Golangs advantages as a hobbyist language are basically Clean, Good Toolkit, GC'd but still reasonable fast, and massively massively concurrent. There is no other strong reason to use it over .

But to a manager of a team of engineers? Wet fucking dream. Everything is formatted the same way without being whitespace reliant, there are enough language features to enable complex design without ever getting too muddy, and you'll never have to worry about an inexperienced developer accidentally introducing memory leaks all over the place.

Experiment with interfaces more, unless you need absolutely generic interfacing there's no reason you can't implement an interface that all the different types can implement.
Doesn't solve the boilerplate issue unfortunately, unless you make interfaces of interfaces and get whacky. Look into moq.

Jow Forums's arguments against Go:
* it has C's syntax and I'm too stupid for C
* it has C's error handling, but more consistent and simpler and I'm too stupid for C
* it doesn't focus enough on the inclusion of trannies in tech
* it doesn't come with a preprocessor and I'm too stupid to use my own
* it's made to be simple, but I enjoy my VB
* its_made_by_google.webm

Go is perfectly fine, keeping in mind that it's obviously not a replacement for C++, but a replacement for Python/Ruby/Perl offering:
* Easy deployment with single binaries and no run-time
* Good performance
* Good, native concurrency support

It's good to develop small to medium-sized programs, exactly where people using Python or Ruby before.

It does not compete with Java or C++ so it's pointless to compare those languages. Go is a canoe, C++ is a nuclear submarine.

>no run-time
Go has a runtime, it just includes it in the native binary. It's why Hello World is 1.6MB

>simple language
>fast
>fast GC, optional
>multi-arch
>multi-platform
>small binaries
>good libs made by people who actually use them
>security orientated
>well supported
>responsive devs
>big community
>helps develop new and interesting stuff
should I keep going?

just try it:
tour.golang.org
golang-book.com

I wrote a pretty large project in Go, an emulator for the Game Boy. I also did the same in C and Rust.

They all had their issues but I see Go as a nice blend of modern language idioms and keeping the old C-like features. I would prefer to use it over C/C++ for most things.

I don't agree with this at all. In the introduction of the Go Programming Language book it is stated as being C 2.0. Of course it is not there yet - but it may be eventually.

cloud, microservices and ops retards imposed it quickly and made it the cloud de facto language

Hahahahahaha. Go is a massive piece of shit. I needed to parse some complicated json recently.
json.unmarshal(map[string]interface{}, & muhdata)
You see that interface{} shit on the end? Looks innocuous right? Try it yourself.

Attached: 1517778304994.png (540x960, 586K)

>umarshaling maps

Attached: tumblr_nmmioxBCKd1u07g1vo1_1280.jpg (593x640, 46K)

I rewrote the core pages of wiby.me in Go. Works good. I just wish it let you keep unused libraries and variables. It should just give a warning, not refuse to build.

suggestion: add gometaliner to that list :)
also, gore as REPL

use underscore

go would be good, if it had typeclasses and HKT

You don't need to go full type theory, just the basics. C# itself has a proposal champion for HKT and typeclasses

Wait until you've seen goimports. I don't want to use other languages any more.

My professor at CMU made us build our code with -Werror.

After working with a lot of shit C/C++ code bases after college, I've come to agree with him that warnings should be errors.

I feel like people place too much importance on being able to comfortably WRITE a language and not enough on being able to READ one. Go is literally the king of easy to read languages and not having imports shitted up because you were too lazy to clean them is a feature.

And I'm sure theres a tool that manages your imports automatically.

>unmarshalling into a map
>but mad that a strongly typed system wont let you deserialize your data into fuck all

t. brainlet. This is the worst critique of the language I've ever seen. Did you just pass CS 101?

A GC language can never be C 2.0

Rust could be C 2.0, but who knows. It will need +10-20 years of consistent, mainstream usage to claim that title.

>type safety
hm yeah where are my generics?

go concurrency is confusing

Create a struct my dude

Go imports... Run on save

should I learn Go as a first language my end goal is video game cheats

Attached: 1531160202662.jpg (979x652, 292K)

Should I learn Go or Rust if I can only choose 1?

Rust.

It will literally take you 2 hours to learn Go unless you are a massive brainlet.

Rust will easily take you 2-3 days to learn, and 1-2 weeks to get comfortable with. I've been "programming" in Rust for 3 months now, and I still don't expect how mozilla wants us to use this goddamn futures system

depends, do you want to learn C++ in future? Rust are a nice training wheels for the memory model since it's ownership containers are just cleaner, more intuitive and better checked version of what modern C++ offers and nothing else learns you to design your programs data flow toward such safe sharing between contexts and avoiding unnecessary copying.

In what way? The only confusing thing for me was that goroutines aren't scoped (can't be blockly waited on without channels/locks) and don't return anything.

Highly unlikely.

But I'd like to contribute to the "fireplace" we, which is completely in Rust.

>It will literally take you 2 hours to learn Go unless you are a massive brainlet.
t. actual brainlet

nobody can learn anything in 2 hours you delusional arrogant fuckface

>Minimal, not bloated
>Good docs
>Fast compile times
>Made by the plan9 guy
>Good libs
>Simple syntax
>Compiled
>...but still has garbage collection

This is a fast and sane language for people who actually need to get shit done

It's not a true Golang thread without the braindead Golang mascot image posted. Can someone provide it please?

I did, Go doesn't have anything new to warrant more than 2 hours

No generics lol
Braindead error handling
Too primitive
GC
No pattern matching
Lame package managment
GOPATH/GOROOT

literary made by evil sjw cucks
also doesn't allow the superior allman indentation style

There is literally nothing wrong with it. Jow Forumstards are just angry because they hate anything what can get the work done and is not so arcane that after learning it you can feel like a better person despite you being still a worthless self insufficient waste of resources.

>nothing wrong with it
>tabs for indentation

It's optimized for ease of reading.

>SJW
Made by Brian Kernighan, Ken Thompson -- The creators of C language and UNIX.

>using spaces for indentation
>ever

Attached: 1529536859657.jpg (727x480, 38K)

If your work for a SJW company then you are a SJW

>he uses SJW unironically
Back to your containment board, please

this does not even make sense lads. programming is just too complicated.

Attached: file.png (383x461, 31K)

I agree, 0-indexing is nonsense and should be done away with.

Not that user but isn't it strange how the Go CoC tries to control what words you can use? That isn't freedom of speech

what's hard about slices?

>go authors
>"Let's make a language for C++ devs, but put some modern features in like garbage collection and memory management"
>C++ devs
>"MUH MEMORY MANAGEMENT! garbage collector?!?! REEEE!!! not using it."
>Jow Forums
>"meme language!"
>
>python/ruby devs
>"hey look Go is there, maybe we can use it to replace the few small tasks where we needed to write something in C++, but keep doing everything else in python/ruby."

rust is not worth learning at this point, it's not a finished product yet

>What's not to like?
The typing. It's so basic. It's suffocating to use.

yeah Go's arrays and slices are pretty fucky

there are 2 distinct things:
1) array - an actual owner of place in memory with fixed amount of elements
2) slice - a view on array
it's illustrative on function parameters and sharing between context, take following code:
package main

import "fmt"

func addOne(array [4]int) {
for i := 0; i < len(array); i++ {
array[i] += 1
}
fmt.Println(array)
}

func addTwo(slice []int) {
for i := 0; i < len(slice); i++ {
slice[i] += 2
}
fmt.Println(slice)
}

func main() {
arr := [4]int{0, 1, 2, 3}
fmt.Println(arr)

addOne(arr)
fmt.Println(arr)

addTwo(arr[:])
fmt.Println(arr)
}

output:
[0 1 2 3]
[1 2 3 4]
[0 1 2 3]
[2 3 4 5]
[2 3 4 5]

Here I make an array (owns the memory) in main(). addOne() takes as an argument the array with size 4, parameters are passed _by value_ - meaning that they are copied for the function call and function operates on its own copy - and thus it adds one to its own owned memory. In main() back again original array is not changed.
Then addTwo() takes the slice of array as an argument. Slice doesn't own the memory (it's just pointer with a size hint) and so the modification inside function affects original array in main(). It's cheaper because it doesn't copy potentially big chunk of memory, but you need to be aware of slice exposing the memory of outer context into inner.

this was the simple part
it gets fucky with appending elements, capacity and such

hey thanks for the example man. I feel like I'm lacking an understanding of actual programming concepts and fundamentals and not really the syntax itself. I'll keep grinding through this book and hope it sticks though. thank you