Explain the appeal of Go

Explain the appeal of Go

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

Other urls found in this thread:

youtube.com/watch?v=q1h2g84EX1M
tour.golang.org/methods/2
tour.golang.org/methods/3
mathworld.wolfram.com/BinetsFibonacciNumberFormula.html
tour.golang.org
groups.google.com/forum/#!msg/golang-nuts/nOS2FEiIAaM/miAg83qEn-AJ
twitter.com/AnonBabble

It's even simpler and more accessible than early Java, with significantly more utility.

Statically typed but writes and reads like a scripting language.

lol no generics

interfaces, can work

Goroutines
They allow you to make things that scale very well and are not hard to implement.

Dynamic typing.

retarded hamster

Coroutines are not exclusive to Go though

I don't even know what this means

Attached: 1518182559001.png (645x773, 10K)

This. I'm a Python programmer and was surprised at how Go is even EASIER than Python. You can go look at the Kubernetes codebase right now and easily read and extend it.

Of course, this plays right into the hands of Google because they designed it so that they can have brainlets commit production code on day 1 instead of spending resources to upskill them.

Go routines have the ability to spawn themselves , are asynchronous and the the go routines scheduler sorts it all out for you.

Go is literally compiled Lua with a better std:
>Same error handling
>goroutines == Lua coroutines
>No classes, use a data type instead (tables for Lua, structs in Go)
>functional elements
>no generics
>no semicolons

Simple, decently fast and it doesn't need a vm

It's fast in comparison to Python, Ruby, PHP, Lua, the shittier part of JS libraries; which I would consider fast-enough. Nowhere near C/C++/D/Rust or faster languages.
Big standard library that is mostly useful, not like Python where things are there but are utter trash and you have to find external one for everything anyway. Includes testing and benchmarking, tracking, network libs, templating and more.
Ok build tool (the lack of versioning is failure though. at least they seem to acknowledge it and work on it in year 2009+9).
Language is very predictable. Even more so with pointers. But pointer-types containers and slices reallocation kinda break this point.
Good C bindings and arch/platform-specific code isolation.

But overall it's not that good, lack of either generics or function overloading leads to annoying APIs, slow dynamic dispatch and need for reflection.
Interfaces are lie, they don't describe operators which leads to yet another retarded boilerplate (see sort library and imagine how clean it would be with elementary types implementing some Compare interface)
Lack of any good macros and meta programming.
GCC or LLVM backends aren't popular and I'm not sure how functional they are. Afaik there has been a lot of work done on GCC backend but didn't try it and never heard of any bigger project using it. Their compiler is very inferior when it comes to optimizations.
Because it started with Plan9 C toolchain, most of modern debugging tool didn't work. Additionally most of Plan9 debugging tools didn't work as well and Goassembly is trash, there is also SSA IR so what the hell is point of multiple IR layers?

The GC isn't particularly good, youtube.com/watch?v=q1h2g84EX1M . But not think it really matters in most applications.

Overall i really like Go, it's a breeze to create RestAPI with it, also no objects.

Attached: golang.jpg (770x478, 62K)

Go has become much faster in recent releases.

Wrote a fibonacci program in both Go and D.
And the version compiled with a recent Go version managed to beat the ldc compiled version.

Your point about debugging is not true. Go has delve for debugging, and you can set line breakpoints and all that jazz using it in conjunction with VS Code.

Go runs on Plan 9. You can even use acid to debug it on Plan 9.

>Wrote a fibonacci program in both Go and D.
>write someting O(1)
are you shitting me?
also Go compiler doesn't do tail call optimizations

Delve is fairly new and I admit it looks great
>Go runs on Plan9
afaik 9front had some issues with compiling Go lately and ACID was broken on Go

>write someting O(1)
I used the O(log n) matrix squaring soltuion

>also Go compiler doesn't do tail call optimizations
So what? A language with proper loop constructs has no need for TCO.

>Wrote a fibonacci program in both Go and D.
Never write something trivial like fibonacci to compare optimizing compiler.
In fact, don't even compare simple interpreters with shit like that, because the focus of interpreters lies elsewhere.

>Never write something trivial like fibonacci to compare optimizing compiler.

Why not?

It's not like I wouldn't like to see proper benchmarks.
But I never could find any comparison with recent Go and D versions.

Go does relatively well in the Language Shootout (around the same as Java and Ada), but for some reason they don't have D benchmarks.

>static typing but without being overbearing like Haskell
>Minimal language interface. Simple enough to keep the whole language in your head
>Big standard library that can handle most tasks
>Standardized formatting and comes with great tooling to give you even less to worry about
>No shoehorned OOP nonsense, just plain fucking code prevents retards from making a huge mess of everything
>Compiles fast as fuck, makes it basically like a scripting language
>Baked in concurrency that is elegant and simple
>Compiled, cross platform just works

Go is a language for people who actually program instead of browsing hacker news and talking about their favorite ""design patterns"".

Because optimizing for simple numerical shit is easy enough that it skews the benchmark towards otherwise impossible to optimize languages with even their best tries like Ruby or Python, where the best JIT compilers struggle gaining x8 the performance improvement over their reference implementation.
Also, relevant real world software isn't simple numerical shit but shittons of pointers to shitton of data structures. Memory layout optimizations are much more important here, because most of the time the CPU is stuck waiting for memory.

>>static typing but without being overbearing like Haskell
>>Minimal language interface. Simple enough to keep the whole language in your head
>>Big standard library that can handle most tasks
>>Standardized formatting and comes with great tooling to give you even less to worry about
>>No shoehorned OOP nonsense, just plain fucking code prevents retards from making a huge mess of everything
>>Compiles fast as fuck, makes it basically like a scripting language
>>Baked in concurrency that is elegant and simple
>>Compiled, cross platform just works
good description of what concurrent pascal had ages ago

>no OOP in golang
How are structs with methods different from classes?

Structs don't have methods, they have fields. A struct can implement an interface. The two are otherwise unrelated. If you don't understand how this is different from OOP, you should really learn more about language design.

But user in golang structs can have methods.

Example straight from the book
package geometry

import "math"

type Point struct{ X, Y float64 }

// traditional function
func Distance(p, q Point) float64 {
return math.Hypot(q.X-p.X, q.Y-p.Y)
}

// same thing, but as a method of the Point type
func (p Point) Distance(q Point) float64 {
return math.Hypot(q.X-p.X, q.Y-p.Y)
}

The struct does not have a method. The struct implements a method. Read the implementation and see the difference.

Here, since it seems you are getting your example from the Golang tour:
My argument:
tour.golang.org/methods/2
Further examples:
tour.golang.org/methods/3

structs in Go lack encapsulation. Methods are not declared within the class, but are entirely posthoc. Interface implementation is structural and implicit rather than explicit.

>tour.golang.org/methods/3

Aside from disallowing runtime class changes and having static typing I'd see this Python code as pretty much equivalent:
class MyFloat():
def __init__(self, f):
assert(type(f) == float)
self.f = f

def abs(self):
if self.f < 0:
return -self.f
return self.f

f = MyFloat(-1.414)
print(f.abs())


I can instantiate and pass around some variable that contains data and methods. Totally not a class instance but just a type with associated methods.

Packages are encapsulated and only capitalized methods are exported so you could just use that for hiding your private methods.


I'm very new to golang so I'm probably missing something. To me all this just seems a lightweight class implementation since there are no abstracts, inheritance or such.

lol if err != nil
lol canadian aboriginal syllabics

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

Rob Pike actually said this lmao

It doesn't mean what you think it means. If you're not a brainlet who don't need no go because it's for retards please enlighten us with a link to one of your projects.

>If you're not a brainlet who don't need no go because it's for retards please enlighten us with a link to one of your projects.

True that! If you aren't a MongoDB or Linux kernel developer, you have zero rights to opinions. So shut the fuck up and write Go like the rest of us brainlets!

Pretty much this.
It's software Taylorism. Don't develop your employees, put them into a production line. Don't trust the people, instead make tools that can be used by unskilled workers because they are cheaper to hire.
Disgusting, I bet it doesn't even work that well at that. It's been proven time and time again that tools can't fix bad developers.

Go doesnt really need tail call optimization if you understand how it allocates stacks

>we dont need tco because we can just keep throwing more stack space at it

Attached: QaYqtd7.png (645x729, 90K)

>Well designed languages that prevent obfuscated, obtuse code is bad
Ill never understand this argument.
Its a modern language, we can take everything we know about the bad of faulty design choices of languages past and avoid them.
Java and Python get lots of runtime errors. Make everything super explicit.
Python and Ruby are easy to read but are inconsistently formatted. Leverage whitespace and let the compiler deal with brackets and semicolons.
Config files are messy and end up requiring a whole IDE. Make linking inherently part of the file structure.
Its clean and rigid, which makes it pleasant, and it happens to be pretty performant to boot.

Tco is only necessary because stacks take up a lot of space, its rarely any more performant. Golang stacks are teeeeny tiny so it obviously wasnt considered a design priority.
We might see it later in the language, maybe with 2.0, but why bother with it now if it'll hardly make a difference?

>going on about TCO with no need for tail recursion
You clearly don't understand what tail recursion is, if you think it's important in a non-FP language like Go.

I like the simplicity and familiarity to C

also it's pretty fast and simple to deploy

And your argument for omitting such optimization is...?

> Fibonacci
> O(1)
I don't think that's how that works my friend
But that hamster makes me finna bust a nut

And your argument for including it over more important features is?

A programmer should be discouraged from using tail recursion instead of a loop in Go.
There's no reason to ever use it over a loop in Go and it just decreases readability and consistency in the code base.

generics is a saner solution than interfaces user. That's why most modern languages have them.

Interfaces can be used as generics, theyre not designed to be. Its a workaround if you really really really really want generics for some reason.

>muh google
>muh minimalism
>mentally disabled mascot appears relatable
>babbys first statically typed language
>babbys first compiled language
>babbys first language faster than ruby/python
>babbys first package manager that's not npm
>babbys first formatting script
>babbys mind being blown by the concept of green threads
>babby doesnt know what generics are so they cant miss them
>walls of text about how their virtual machine is actually super impressive (it's not)
>muh docker
>muh gamed micro benchmarks

previous, now abandoned by all but the most braindead go shills:
>muh systems programming

Attached: commander.png (922x197, 12K)

>its for brainlets because its clean and sane! Reeee!

>muh google

Contrary to popular belief "muh" is not a valid counter-argument.

people only use it because of the mascot.
>no joke

Brainlet-tier criticism

>muh brainlet boogeyman

mathworld.wolfram.com/BinetsFibonacciNumberFormula.html

also
>although the result was known to Euler, Daniel Bernoulli, and de Moivre more than a century earlier
always have to giggle at such things

is it?
never tried go to be honest

It honestly makes me laugh every time I see it.
Its so fucking retarded

try it yourself:
tour.golang.org

>arbitrary precision floating point math
>O(1)

The Q matrix squaring solution ends up being faster than Binets

a few more reasons:
- security
- runs on many platforms/OSes
- uses much less memory than java
- compiles to machine code, which means almost-C speed
etc.

>hurr durr real men like obfuscated, insecure languages

Its more comparable to sepples speed, and is particularly slow on large data structures and regex and such because the existing benchmarks use native go libraries instead of making C calls

Golang is GC'd and has a considerable runtime overhead compared to C.

It does hold its own compared to other GC'd languages though.

>compiles to machine code, which means almost-C speed

It's faster than python but the speed is closer to java than C, and in some cases much worse

You are just conflating the two because you likely are only familiar with OOP. That is fine, but you are drawing an analogy where none exists. Sure, you could compare the two because of methods and dot syntax, but the implementation is completely different.

Even the Python variation, while it looks similar, is very much OOP (maybe not strictly, but objects/inheritance are fundamental to the language). Sure, you can emulate something that vaguely resembles OOP with Golang, but it will always just be fake.

The formula you posted is nowhere near O(1) even the 2^n bit requires a loop to be computed

you can do power of two with shift operator btw

Go will become the standard backend web language, I cant believe people are still holding on to Node which is only good for SPA's and CRUD frameworks like Rails and Django when Go does both very well and you dont even need to use frameworks in Go because all the functionality and middleware is built into the language

Go will become the standard backend web language, I cant believe people are still holding on to Node which is only good for SPA's and CRUD frameworks like Rails and Django which force 'opinionated' cookie cutter REST apps when Go does both very well and you dont even need to use frameworks in Go because all the functionality and middleware is built into the language

Attached: running_pike.png (720x514, 580K)

This. It is pretty well made for all of this.
Given time it will become super popular, since it can do practically anything.

You can use other regex libraries, which are faster as far as I know.
> is particularly slow on large data structures
This shouldn't be true. It completely depends on your data-structure.
Operating on a slice, no matter the size, is as fast as possible.

TCO was omitted from Go because they wanted to have better error messages from the stack trace and you should be using iteration more than recursion.
groups.google.com/forum/#!msg/golang-nuts/nOS2FEiIAaM/miAg83qEn-AJ

classes vs. types+methods+interfaces vs. prototypes vs. structs+functions

Sure the implementation is different and they all have their different snowflake intricacies but in the end it's pretty much the same thing in different packaging. You're trying to combine some data structures and functions into neat bundles so that it would be easy to understand and maintain them.

You could write this in C but it'd just be painful and laborious. You don't have abstract classes but you do have interfaces. You don't have inheritance but you can stack a bunch of types together.

I'm the complete opposite. I feel it's substantially more annoying to tack something together that would take minutes with Python than it would to do so in Python, and readability suffers.

Could be I'm not as familiar with it, but I just don't like it. I'd much rather default to Java if I couldn't use Python on a daily basis.

*would to do so in Go, sorry, I can't proofread

So what can't you do with Go? Is it a backside java replacement? Is it as quick to develop with as python? How fast is it compared to C++, Java and python?

Rob Pike is actually slightly in favour of adding TCO but with a special keyword (become instead of return).

Become instead of return is interesting

>hey kids! look at my cool meme that makes template programming look like the hottest most bitchen far out cool hip new kind of programming

and be sure to try out C++, the only language in town that has the core language built on templates

and read pic related if you want to learn how to do cool tricks with templates!!!!!

Attached: 12436957389_sMtG8.jpg (250x314, 21K)

1.5/10 barely got me to reply

>muh valid arguments

generics are not needed if you have go's interfaces

hurr durr I'm retarded

no u