Why do you like Golang /g/? Is Golang worth learning or is it

>garbage collector
It sucks balls.

Anything is a step up from nodejs

>>57868880
>why others like Golang so much.

1) Speed
2) Statically compiled, so everything is wrapped up into one neat binary (no external dependencies) which makes containerization simple

You can turn garbage collection off.

It has a lot of potential. Has big names backing it, has gotten endorsements from other big names as well. I think it's worth learning.

File: gman.jpg (63KB, 1280x720px) Image search: [Google]

63KB, 1280x720px

>no generics/templates

into the trash it goes

>>57868880
>Why do you like Golang?
I don't

While we're at it, what's the equivalent to Flash and Rails on Go? stdlib seems rather involved

>>57869053
Not Flash... I meant Flask

>>57868880
>Is Golang worth learning or is it just another meme?
It's a gigantic meme

Pointless piece of shit language that reinvents the C wheel badly. It has no redeeming qualities.

>>57869019
Virtually every language in existence can be statically compiled, and plenty are faster than Go. Enjoy your garbage collection

>>57869077
I will.
Enjoy your memory leaks.

>>57869109
>he legitimately thinks garbage collection solves memory leaks
I can tell you've been programming for less than a year

Go is one of the few languages to actually be deigned properly.

I've used quite a few languages and go is pretty much the best. You can learn it in less than a week, it can be very fast if you use it properly (concurrency, channels), many tools for working with, editing, and compiling code are integrated and officially supported so that when you do run in to problems it's very easy to find solutions.

Going from c++ to go was like going from a turn-of-the-century steam powered car, to a modern vehicle. It feels like it has decades of careful thought put behind it.

>>57869161
yeah but C++ has templates and is actually useful

>>57869161
>Going from c++ to go was like going from a turn-of-the-century steam powered car, to a modern vehicle. It feels like it has decades of careful thought put behind it.
Holy shit, this is some hilarious pasta

10/10

>>57869156
nice strawman
There's of course nothing that could stop leaks completely with any arbitrary code.

An airbag won't save your life in every situation either.
Doesn't mean you shouldn't use it.

>>57868880
>>57868880
>Why do you like Golang /g/?
it's a solid language, with coherent, consistent and well-thought-out features following in the plan9 tradition of simplicity and completeness rob pike is a hero also concurrency

it's a fast, fun and reliable platform for compiling statically-linked distributable binaries for cli and web apps

and it's close enough to the metal to do "real" (read: low-level) things where most interpreted languages would require a language extension which would probably have to be written in C/C++ or you'd need C/C++ in some form or another. Go also has cgo but we don't talk about it.

>Is Golang worth learning or is it just another meme?
absolutely worth learning! it'll take you no time at all to get proficient if you're coming from another language

https://gobyexample.com
https://golang.org/doc/effective_go.html

This post was not sponsored by The Go Authors or Google, Inc. See LICENSE for more information.

>>57869182
D is far better than C++, and Go is better than D.

Templates are unnecessary and one of the things that makes C++ less concise than other languages. You'll often find that C++ apps are some of the most fragile because of the variance you get between implementations.

Go on the other hand is much more solid because of it's conciseness, it's very hard to make mistakes when writing go because of how it was designed, and the tools provided by the standard library are powerful enough to let you build abstractions that are not only easier to understand than C++, but require less than half the code and in many cases, are more performant.

>>57869161
>It feels like it has decades of careful thought put behind it.

It does. The 50s and 60s mostly.

>>57869303
CSP came out in 1985, which is where much of the theory behind go is derived from.

Required reading for PhD students.

http://usingcsp.com/

>>57869301
>Templates are unnecessary and one of the things that makes C++ less concise than other languages.
Go is about as concise as C

AKA fuck all

>>57869301
>the tools provided by the standard library are powerful enough to let you build abstractions
Go has abstractions? News to me

Last I checked they didn't even have polymorphism apart from naive virtual functions aka ‘object’/void* style boxing, which is incidentally also shit for performance

>>57869370
You've clearly never used the language and are just spouting idiocy. Typical non-gopher.

>>57869387
You obviously don't even understand what an abstraction is. Go take a CS class kid.

>>57869053
If you're looking to do a pretty basic webserver, net/http will do the job. Some people like to plug in http://www.gorillatoolkit.org/pkg/mux , while for speed httprouter is the fastest (https://github.com/julienschmidt/httprouter). If you're more looking into a fully-fledged framework like Rails, then Go doesn't really have those.

>>57869370
>C++
>90 keywords
http://en.cppreference.com/w/cpp/keyword

>Go
>25 keywords
https://golang.org/ref/spec#Keywords

>C
>like 30 keywords

C++ is a mess

>>57869394
I've written a few libraries in the language before deciding it was a pointless waste of my time

It provides no innovation on top of C except green threads (muh “goroutine” meme) and has no abstraction to speak of. It's a language delibaretly designed to be as ‘flat’ as possible; there's barely any concept of user abstraction. Stuff like polymorphic lists and maps have to be hard-coded into the language because you couldn't possibly define them yourself.

It has no first-order polymorphism at all, the type system is a joke (because they have no real polymorphism they fake it using a universal/void* boxing, which requires type-directed case analysis at runtime AKA unsafe, slow, brittle code, no type erasure, etc.)

I literally don't think the language has any single redeeming quality. You might as well be writing C for all I care. All it does is add meme features like ‘omg import from github!!!1’ that nobody sane actually uses anyway.

It's a complete and utter joke. I don't know why the language exists.

>>57869495
So basically, it's C improved?

Got it.

>>57869493
Ah, I see you're still confused by covariance vs contravariance

Just because a language is simple doesn't mean using that language is simple. In fact, it's pretty much the opposite. The simpler the language, the more complicated the program.

Try writing anything in brainfuck, unlambda/SK or other ultra-minimalist languages with like 2 keywords. You won't get very far, because the language simplicity is so extreme that the program simplicity suffers a gigantic hit in return.

Meanwhile on the opposite end of the spectrum, you see the opposite trend - the more complicated the language, the more concise you can make your programs. Look at Haskell, Agda, whatever. You can write programs in a few lines that require painstaking amounts of low-level boilerplate in something like C or Go. This is because the language has so much power that you can make reusable abstractions, which is impossible or difficult in low-abstraction languages.

>>57869519
The thing about improving C is that nobody who uses C (or C++, for that matter) in 2016 uses it because it's a good language. They use it because it gives them raw control over stuff like memory management.

The Go people are on a misguided quest to make C ‘better’ by removing the only reason people use C. Anyway, feel free to use whatever language you want, I'm just explaining to you why you don't see anybody else apart from hipsters care about the language in practice.

>>57868880
I don't like it because the logo is stupid. I bet /g/ could make a better logo.

>>57869607
Yeah that fucking logo is really ugly.

>>57869573
English has 26 letters and that's fine.

25 keywords is basically the perfect number. Imagine if english had 90 letters, it wouldn't make it better at all. It would make it worse.

Yeah, it would be bad if we only had two letters too, but that's a straw man.

Go is pretty much the best language we have at the moment. It's definitely better than C++ (objectively), and the only time to choose C over go is when you need the performance that C offers (hardware interaction).

For financial systems, network/web software, and pretty much everything else, Go is a better choice.

The only reason to learn C++ is if you want to maintain legacy enterprise software that's over a decade old and get paid 45k/year for it.

If you want to have fun and build new things and make a living wage, learn go.

>>57869607
Women love it though. I put a gopher sticker on my laptop and it's gotten me laid twice.

>"hehe I like your little chipmunk sticker"
>"it's actually a goher"
>"do you like gophers anon?"
>"Well I'm actually a software developer, you see the gopher is a mascot for the Go programming language"
>"I don't know what that means anon, do you get paid a lot?"
>"yeah I made 80k last year"

*panties soaked*

I'm not lying btw. But go ahead and put the C++ sticker on your laptop, I'm sure a woman will think letters and symbols are cute.

>>57869661
That's an absolute shit analogy.

Keywords aren't letters, they are words.

Imagine if the english language had 25 words.

Simplicity does not equal simplicity of use.

>>57869799
No your analogy is shit.

Words are made up of letters, the english language can't be a finite subset of it's atomic constituents.

"A language with only 25 words" doesn't make logical sense. Language is extensible by means of it's atomic constituents (letters).

Your brain is too small to understand how simple tools can be used to create complex systems.

>>57869914
Are you honestly implying go is alternative to english? Lmao.

The words in go already have letters, you are writing a program created from words. 25 words is not a lot of words to use.

>>57869661
Holy shit, saved. Fantastic copypasta

>>57869738
>>"yeah I made 80k last year"
I know PHP developers who get paid more. Shit I know some PHP developers making $140k/yr in the valley

$80k is pretty sad unless you live in some slavic country

>>57868880
extrmely good for a handful of applications and probably the best web back-end technology we have right now

definitely not an all-purpose language though

>green threads done right
>standard library is good for the most part
>decent amount of third party libraries
>easy to use and learn
>lack of nerics keeps the architecture astronauts and abstraction obsessed haskell weenies at bay
>no one tries to be clever and codebases are straightforward to follow

It's shit but comfy

>>57869495
Nigga, you sound exactly like someone who's used go for only 1 day. Your supposed libraries must have been shit

>no abstractions
Interfaces, bro. They're actually pretty good, and overlooking them is a very telling sign of a go beginner

>>57870097
Interfaces are no replacement for generics. You will never write a piece of reusable generic code in Go.

>>57869998
This nigger understands.

>>57869999
>>57870000

>>57870097
>Interfaces, bro. They're actually pretty good, and overlooking them is a very telling sign of a go beginner
I mentioned interfaces:

>because they have no real polymorphism they fake it using a universal/void* boxing
I guess you don't really understand interfaces. It's okay, it was my fault for using terminology that only makes sense to people familiar with PL development/theory.

>>57869998
Forgot to add that cross compilation is literally just setting two environment variables for the OS and architecture. Easy as fuck.

>>57870111
Interfaces are actually great replacements for many of the same applications of generics, but admittedly not all of them. Saying that they're "not an abstraction" is just idiotic.

>>57870134
Interfaces are just pseudo abstract and virtual functions. They are not generics.

>>57870171
They're not generics, but they are useful *abstractions*, and allow for a significant amount of code reuse, at least compared to C.

If C++ developers and those who masturbate to Haskell/ML (since FP programmers rarely make anything useful) stay away from Go, that would go a long way towards explaining why the code is well-maintained and easy to read.

>>57870230
Interfaces in Go are the equivalent of void* in C.

It allows just as much abstraction, and it's just as unsafe. Enjoy your meme language

>>57870131
This. It's awesome to be able to compile software for ARM and throw it on an android device and run it in the background so easily.

I can SSH into my phone and run all my command line go apps.

>>57870238
What?
Are you talking about empty interfaces?

>>57870238
Nothing you said is even remotely correct. You clearly have never used interfaces in your pathetic virgin life.

>>57870268
Well, an empty interface is essentially just a void* together with no operations on it, sure.

If you have an interface with some methods associated with it, you gain the C equivalent of passing a void* together with some void* function pointers, which is what people keep saying when they mean “virtual calls”.

For example the C standard sort function:

>void qsort(void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *));

This works by having the user pass an explicit comparison function with the signature

int (*compar)(void*, void*)

, which is essentially the same as Go's “compare” interface, and about as slow.

The calls are resolved at runtime, there's no inlining, you have a virtual call overhead for every single comparison, et.c

Because it's so slow, they resort to hard-coding a bunch of copy/paste ‘sort’ functions instead, one for each primitive data type. (Of course, if you want to use anything other than a primitive data type, you're out of luck)

It's a fucking joke of a language abstraction-wise, because there is basically none. It's at the power level of the 60s. Come back when you can define a useful definition of a generic set without resorting to the built-in magical maps, for example.

>>57870437
Now you're suddenly complaining about runtime overhead.
I thought you were trying to make a point about type safety.

Moving the goal post, are we?

>>57870649
What?

I haven't changed my stance on type safety. Go allows you to cast from any type to interface{} and from interface{} back to any type.

package main

import "fmt"

func main() {
    var x int64;
    var y interface{};

    x = 5;
    y = x;

    fmt.Println(y.(string));
}

This code crashes at runtime, even though it type checks.

>>57870649
>>57870927
Also how ironic of you to talk about moving the goalposts when you're the one actively trying to avoid responding to my posts by bringing up different issues instead.

>>57870927
Duh, you're using empty interfaces.
A special case.

That doesn't mean interfaces don't provide type safety.
Does Java have no type safety you can wildly cast "Object"?

>>57870937
What are you talking about?

>>57871078
>A special case.
No, an empty interface is a subset of any other interface. You're just using an interface without any operations. There's nothing special about it.

The fact that interfaces allow you to box values behind virtual function tables is exactly the reason why people abuse empty interfaces to do dynamic typing in go, just in this case they don't care about the virtual function bit and just want the dynamic typing bit, which is why the interface is empty.

You can do literally the same thing with any other interface.

>That doesn't mean interfaces don't provide type safety.
It's not type safe if your code crashes at runtime with a type error, lmao. Well, I guess dynamic memelang proponents would call that “type safe”, in the sense that they don't care about your program crashing as long as it crashes with a type error instead of a segfault. To me there's no difference.

>Does Java have no type safety you can wildly cast "Object"?
Bingo; although the big difference between Java and Go in this respect is that in Java, the usage of ‘object’ boxing can be avoided in many cases. In Go you're *required* to use it.

C is unsafe. Manual memory management is stupid for 99.9% of applications.

>>57871731
Type safety doesn't stop existing because you can circumvent it at certain parts if you choose to.

>In Go you're *required* to use it.
In very few cases.
Biggest would be making your own generic container types. And even there you could use a preprocessor.

>>57871806
There exists gc for C you stupid nigger.

>>57868880

the best lang ever created

>>57871860
>Biggest would be making your own generic container types.
Yes, like I said - if you want to do any sort of abstraction in Go, you need to use unsafe object boxing.

Of course, Go programmers don't like abstraction, they're rather just copy/paste their sort algorithm 10 times with different types. After all, who ever needs more than integers, floats and strings in their code?

File: 1473883889862s.jpg (3KB, 125x125px) Image search: [Google]

3KB, 125x125px

>optional semicolons
>garbage collection
>google

>>57872832
t. NEET

>>57872773
Go programmers love abstactions. they just hate the useless ones, and the code monkeys who insist on using them.

>>57872877
>they just hate the useless ones
Yeah, like sets

>>57872773
You seem to be confused what abstraction means,
it's not a synonym for generics.

>sort algorithm
swap by index and have the content implement some compare interface and you don't need generics

>>57872937
I have 10 years of background in PL theory, I'm very much familiar with the words I'm using. An abstraction in this context is any sort of reusable model which fits multiple use cases.

Generics are a good example, but they're not the only example. The defining feature of an abstraction is that to make use of it, you need to abstract _over_ a common property. For example, if you want to build some sort of data structure or algorithm that works for multiple types, you need the ability to abstract over types - and parametric polymorphism is one way of doing that. Interfaces are another.

The point is that Go-style interfaces are a very, very limited way of doing abstraction. You need to duplicate much more code in the end, because there's much less that you can reuse - the abstraction floor is too low.

>swap by index and have the content implement some compare interface and you don't need generics
Yes, now tell me how you would use that model to have a reusable definition of lists that I can use with my data types without having to manually reimplement a bunch of basic combinators like comparison and swapping primitives specialized to my data type.

>>57873082
Hello, Mr. PL theory expert.
>I'm very much familiar with the words I'm using.
Yet to see proof of that.

>The defining feature of an abstraction is that to make use of it, you need to abstract _over_ a common property.
Which is almost anything you do.
Writing a function is already an abstraction.
Creating a struct is an abstraction.
Defining interfaces is an abstraction.

Statements like "if you want to do any sort of abstraction in Go, you need to use unsafe object boxing" are simply wrong and retarded.

Comparisons have to be specialized for your data type, an expert like yourself should know that.
And what is so hard for an expert to understand about swapping by index, where the element data type doesn't matter at all?

>>57872901
that's oddly specific

>>57873339
It's the first example that popped into my mind. Admittedly, it's not a terribly good example, because they'll just implement sets in terms of their built-in magical maps.

Maybe binary trees would be a better example. Anyway, all data structures in go are going be wrapped around

interface{}

for every single function, which means you're constantly casting your types, you lose all static type safety, your performance goes to shit due to runtime type inspection and virtual calls and you can't do higher-order polymorphism at all.

>>57869053
Go's philosophy and its limited type system are antithetical to building a Rails clone. The closest things it has to one https://github.com/revel/revel and https://github.com/gernest/utron, both under construction at the moment.

an abstraction is just a layer on top of something else. Ex: C is an abstraction layer on top of machine code. All programming languages are capable of abstraction.