How good is golang?

I couldn't disagree more, languages should have some actual standards when it comes to packages and package managment, the fact that they don't is why we have so much bullshit surrounding dependency resolution and the actual building/linking process. Every standard go program is built the same exact way on every platform and so are its dependencies, there's no need to be concerned about special snowflake distros who have arbitrary names for their deps or don't keep things up to date.

Regardless if you don't like it you don't have to use it over your distribution package manager so I don't see what the complaint is. I really don't get the complaint with the build process, I don't see how go build is any different from make build, I'd really rather have a standard build system than deal with all the third party tools that differ from project to project and platform to platform.

OS package managers should be responsible for applications, language package managers should be responsible for libraries. Oddly enough Microsoft is the only one I've seen doing the sane thing with OneGet, that is a good approach that allows for hits with ease. Just have a package manager interface that handles multiple repositories and standalone package managers, that way you still only interact with one program but it interacts with specialized package managers, install 3rd party full applications through pacman, apt, etc. and then handle language specifics stuff through pip, cpan, go get, etc. but all through the same interface with the same syntax, it's just wrapping those underneath. I see no reason to rely on such centralized systems instead of breaking it out where it makes sense, keeping the entire world in multiple repos controlled by different vendors that differs from one OS to the next just seems terrible and unnecessary, both in terms of complexity for developers who want to actually distribute software and wasted effort for package maintainers. Standardize this shit and separate it from the OS/platform.

This bullshit is my main complain with every language I deal with and every poorly documented project that has either platform specific or outdated build instructions. At least with Go the build process is the same forever on everything, you don't have to think about it, and why should you?

Proofs?
If you don't write stupid code in Python and use native extensions for tough places if any (which are likely already written — see SciPy for example), it's reasonably fast too, if not faster.

You only ever write in C and C++, right?

Also there is PyPy, which now supports Python 3.

Nothing changes in this regard, one is hidden from you by autoconf/the OS package manager the other is hidden by the language package manager. You only changed where the dependency resolution happens, it is still needed.

People don't use "snowflake distros" because they don't like the way packages are built on them like you, they use it precisely because they like that packages are built that way on that distro. And again, you can build the same C program exactly the same way on every platform (and its dependencies), there's nothing new here. Forcing a specific version of the dependencies (if that's what you're implying) makes no sense, people often need a specific version of a package.

Right, but every piece of documentation is based on using it.

A library is an application for a developper.

Almost everything in C, but a good amount of stuff in R also, though I use it exclusively to manipulate csv data and plot it in a semi-interactive way (org-mode). I don't like the fact that R has a package manager, I'd rather install the libraries I need through my OSs package managers. I also do some Perl and sh scripting, and sometimes I sketch something with Python (which is another clusterfuck since some packages come via the OS and others via pip). C++ I try to avoid at all costs but sometimes a library imposes it. Sometimes I use ML or Scheme if a functional approach is better suited for a program, though I never had to install any libraries for them.

...

wow i? hate golang now

Python is still kind of slow, especially if you get fixated on a certain datatype that might not be optimal for your problem, and then scales badly.
Example from work - finding specific items in pandas dataframe with string matching is horrible. about 0.5 sec per item.
I need to iterate over a million items, which would amount to 6 days. And that's when you go back to dictionaries.

The language is idiotic, ass-backwards version of C that's touted as simple, but in reality it's more complicated than C.

Just look at how you declare variables and how you make methods for classes. Really, it's pure cancer reading through the code, tho it's still less worse than the sjw macfag Rust abomination.

Just use C, C++, D, SBCL, Racket or anything else with human, solid maturity in its design.

The language is perfect to implement strong abstractions thanks to the really good type system and sane polymorphism. It's simply not good for those who like OOP shit.
Generics are one of the greatest reason compilers are slow. You can still do monomorphisation like in C++ by using go generate.

x := 1y := 1.05z := "some string"var a intvar b int = 1var c intc = 1
play.golang.org/p/RVDGDPoUon

Declarations and assignment are similar to C except with a shorthand `:=`, methods on classes are literally just function definitions with the class name before the function signature. Seems simple to me, how would you rather it be?

I see people post this a lot and I don't understand why a language that's easy to learn is seen as a bad thing.

Easy to learn languages aren't bad, but easy to learn by itself is not an indicator of product quality. Ton Roosendal of the Blender Foundation said in a recent talk (paraphrasing, so might be rong) "We don't want to make easy to learn software, we want to make software that is quick to use once you've learned how to use it". The typical implication of "easy to learn" is that by making it easy to learn, you lock out more advanced features or teach users to do things in a slow or bad way in favour of it being easy to learn.

From the same talk, the more important thing is consistency in use. If you do something to something else in one context, then doing the same thing to something similar should work in a different context. Users get frustrated if this doesn't happen, especially if it's similar enough that they make the connection.

Looking at the code snippets posted, I like the := syntax, assuming it's declaring and assigning a value at the same point, similar to C++'s auto type specifier, but I don't like how similar it is to the = syntax. I don't like the other declaration syntax. If I have some type specifier inside of a function then I know it's a variable, I don't need that specified again. Similarly with the function and class declarations. I know it's a type declaration from the class, struct, or typedef at the beginning of the line, I know it's a function declaration because it's outside of a function. For class member function declarations, I know when I can stop looking for them when I hit the closing brace of the class, and declaring them outside of the class declaration like that seems to detach them from the class, especially if you end up with multiple (related) class declarations in a single file.

x := 1

c = 1

Am I missing something here? Why are there two ways of assigning a value to a variable?

I assume that the first one declares a variable named x with the type of the value on the right hand side, second one assigns the value on the right hand side to the previously declared variable on the right hand side.

C/C++ way of declaring ways is problematic, anything involving function types is notoriously hard to read, and there are a few cases where the parser needs to partially evaluate the source to resolve the grammar ambiguities that exist between declarations and expressions:

northstar-www.dartmouth.edu/doc/ibmcxx/en_US/doc/language/ref/rnrslvng.htm

I'm surprised someone could be so retarded to not know this and still attempt to criticise a programming language.

`:=` just implies the type from the right side, it is simply syntactic shorthand for `var x type = whatever`, you can still do it the long way if you want to though, which is what I did with b and c there. All of these do the same thing
x := returnVal()var y inty = returnVal()var z int = returnVal()

Yeah.
I'll agree that "var" is kind of unnecessary however I can't say I use it often, it's very rare, especially in cases like you said combined with named returns and the previously mentioned :=, in any language you usually want to initialize your variables anyway so it doesn't hurt to just say x := *zerotype of your type* instead of var x *type*.
Even still if you want them declared the long form way but want to avoid "var", Go allows you to give your return signature names which are auto declared at the beginning of the function so you can avoid such declarations and even avoid specifying the return variable(s) (naked return).
play.golang.org/p/9UXLQrwSDS

The separation of methods from datatypes is an intentional design decision based around interfaces, the reasoning is that you do not need control over the deceleration in order to satisfy an interface, you can extend another datatype easily in your own package as needed without modifying the original library.

For instance if you made a library that has yourClass and someone else had a library with classInterface, in my package I can extend your type to satisfy classInterface by just implementing the missing methods in my package, I don't have to modify either library to do this, specifically I don't have to modify the existing class or create a new subclass that inherits from it(although this is possible too), I just extend it directly. It's like "extend" in Java except you can't override methods, if you need to override methods you do have to do something similar to Java where you make a subclass, embed the superclass, then declare your own members and methods of the same name but with no special syntax around it, it's the same as any other method deceleration, if you want/need the original method/member you can still call it too by specifying it.
mysubclass.method() //overwritten method
mysubclass.mysuperclass.method() //original method

That's more related to inheritance though, I could probably give a contrived example if you want showing that.

If I missed something or explained poorly let me know. I'm no expert on this.

I also want to link this
youtube.com/watch?v=ytEkHepK08c

The explanations are good. Makes sense why they've done it the way they have. I'm assuming there's something similar to the make_(un)signed templates in C++ to ensure you get the right type?

Sorry, I don't understand. Get the right type in what context?

The only time you have to worry about types are inside of functions that take an interface, in which case you can do something like this
t, ok := input.(typeName)
where input is some unknown type, typeName is something like int, myClass, etc., it's essentially a validated cast, "ok" is a bool that will be true if "input" is or can be used as typeName, "t" will be a copy of input except strongly typed.

tour.golang.org/methods/15
tour.golang.org/methods/16

Take into account something like that should be a rare occurrence, not many things need to account for every possible datatype and if they do they shouldn't have to differentiate between what those types are, so an empty interface isn't usually a good choice, a defined interface would be a better fit and you wouldn't have to worry about what underlying type it is so long as it satisfies the interface.

Not sure if that's what you mean though.

If you're doing math that requires the limits of an unsigned integer for a certain portion but the inputs are signed integers and you use the := operator, how do you force it to make the just declared variable an unsigned type? You could declare the type, but then if you change the type of the inputs, you might get narrowing conversions.

It would depend on the situation, in most I'd say you would just cast it to and from as needed, with either a copy or a pointer. Is this what you mean?
play.golang.org/p/6oHmLhTp0B
A function that takes an int as the input but requires that int to be represented as a uint, then returned as either an int again or the converted uint.
There's other ways to handle this but I'd say it depends on what you're doing.

Example where we avoid the type system for no good reason.
play.golang.org/p/TU89esuzVd

If you meant just force the := to be of an unsigned type on assignment you can do a cast on a literal, I don't know if there's another way to do that, it's usually the case where I do `var x uint` but you could do `x := uint(0)`

I don't think there's a notation for unsigned literals, there is for complex numbers though.

Sorry I'm a bit tired now.

If you think about it there's no reason why you would ever need unsigned literals.

Literals in go are not typed.

...

Go has no classes :^)

Related note:
Google is trying to kill Python even more by having transitioning their Python 2.x code-base to Go.

opensource.googleblog.com/2017/01/grumpy-go-running-python.html

gophers pls go

lol wut