Golang

Thoughts on Go?

Been playing around with Go, thinking about using it for my next project (backend server for a turnbased multiplayer game), but still can't commit.

>The language itself
Feels like writing C with guard rails. A plus imo.
You can learn it in a day.

>Speed
Surprisingly fast. More than fast enough to stay ahead of web I/O.

>Concurrency
Channels are nice, but they are not the final solution to concurrency that the language designers seem to think they are. You still need mutexes/atomics. Also its very easy to accidentally create a channel deadlock. Overall better than most languages but overhyped.

>Std lib
Fantastic. You could easily build a CRUD app out of the box using only stdlib (maybe pull in a DB lib too).

>Interfaces
This is where things start to get wonky.
So interfaces in Go are entirely implicit. There is no "implements" or ":".
Any type which has methods that match an interface is considered a valid implementer of that interface.
This basically gives you duck typing, which is still type safe, but it feels awkward overall. You could easily accidentally implement an interface without realizing it.

>interface{}
This is basically the equivalent of Typescripts "any". It's used

>Go routines
Pretty nice and seems to "just werk" for the most part. MxN green threads for those who don't know. Each thread is basically an event loop which multiplexes its goroutines. It would be nice to have finer grained control over how the goroutines get assigned to different threads, but it seems like they've done a good job out of the box.


>No Generics
Honestly this is a fucking joke. None of the reasons they give for not having generics are good. Interfaces are not a substitute.
They should just copy/paste Rust's Generics/Traits and call it a day.

This is the end of my blogpost, thank you for reading.

Attached: 1_30aoNxlSnaYrLhBT0O1lzw.png (1500x1000, 50K)

Other urls found in this thread:

play.golang.org/
twitter.com/AnonBabble

Sounds too much like "gulag" so I dont like it.

Its like a shittier Rust, just use Rust

Attached: 1547585670529.jpg (1113x640, 55K)

Shitty language designed by an even more shitty company and has the shittiest logo/mascot I've ever seen

should I even use go if I'm not advanced enough to need channels and go routines?
I picked it up because I like C style programming but I'm a brainlet so maybe not the target audience.
I don't know when I would need generics as well.

You know what? This is actually an informative and quality content post. These are rare on Jow Forums these days. Please continue to enlighten us with your blog posts. Best regards, a fellow coder trying out Go.

I am going to use it for web simply because it will allow me to buy tons of cheap VPS. It will also greatly simplify my stack and admin work.. Can even ditch linux for openbsd comfortably

Attached: PEPERAILWAYS.png (400x560, 40K)

If you are just fucking around with command line apps go is pretty much ideal.

you should use a language based on your needs, not some other user's philosophical opinion

Golang was literally designed as C style programming for brainlets, Rob Pike had a quote on that. Basically he saw too many non-programmers at Google having to learn complex languages when all they wanted to do was build a simple tool for the task at hand.
Channels and goroutines are nice when you do need them but honestly it's pretty rare for most problems.

>current day
>languages with null

based OP, that was actually the first OP post concerning golang that was wroth reading

that being said
>and has the shittiest logo/mascot I've ever seen
/thread

Argghhhh. I fucking hate jewgle and their tranny shit but Go is just so good it's hard not to use it. Has good QT bindings, decent speed, easy to write and compiles to relatively small binary. I hate to admit it but it's really good

rust is better because it doesn't need a runtime. That's about it. I'd rather use c++ desu.

desu. i think desu is being transformed into desu. i've never used desu in my entire time on Jow Forums. wtf.

Come on, not having to deal with prehistoric shit is something everyone benefits from.

You sure about that?

Attached: desu-animated.gif (524x480, 106K)

>Channels are nice, but they are not the final solution to concurrency that the language designers seem to think they are. You still need mutexes/atomics
And they don't claim it is. Go has both mutexes and atomics.
>Also its very easy to accidentally create a channel deadlock.
Don't make your controlflow concurently multidirectional. Establish a hierarchy of what messages what and at what times. Or you can use timeouts and/or the default case in the select statement.

More thoughts

>Fear of functional programming
The designers have an odd aversion to functional patterns.
Basic things like map, filter, reduce etc.
These would be a huge productivity boost while writing go

You have to write for loops for everything. They claim this makes the language more readable, but I disagree. How is an explicit loop better than
var evens = nums.filter(x -> x % 2 == 0)

Its really hard to fuck that up. Writing the loop yourself just opens you up to off by one errors and other little mistakes.

>Closures/Callbacks
Despite their odd aversion to functional programming, they still allow closures, callbacks, and passing functions as parameters.
This seems bizarre as it is very easy to code yourself into a callback spaghetti hell, and is completely at odds with their idea of keeping everything simple and obvious.
And the fact that the language already has support for closures means adding functional patterns would be trivial. In fact you can write one off special case implementations of map/filter etc, but they should just be built into the language.

>Tooling
Tooling is great. Simple composable Unix style tools.
gofmt is the authoritative formatting option which I'm ok with. Formatting debates are useless bikeshedding.


>Ecosystem
The go package ecosystem is a little shakey.
You have a few superb libraries out there (Gorilla webtoolkit being the best example).
Then you have a scattering of github packages which are a complete crapshoot.
For little side projects these would be ok but I would be extremely hesitant to pull any of that stuff into a production product.

There's also an unusually large Chinese portion of the community.
You'll inevitably find packages on github with Chinese documentation, and maybe some English if you are lucky.
I don't really know what to make of this, but its worth mentioning as an oddity.

>Basic things like map, filter, reduce etc.
Result in extra allocations more often than not. Allocation is expensive.

>This basically gives you duck typing, which is still type safe, but it feels awkward overall. You could easily accidentally implement an interface without realizing it.
literally just use type classes, it's the same shit and can still be done posthoc except you don't trip over your own toes

it's kind of impressive how go just didn't learn anything from any other languages that are around today

go has its drawbacks but it's good enough for the most part

>it will allow me to buy tons of cheap VPS
>It will also greatly simplify my stack and admin work
>Can even ditch linux for openbsd
why is this?

Attached: say_desu.gif.png (320x244, 139K)

>>No Generics
>Honestly this is a fucking joke. None of the reasons they give for not having generics are good.
its a non-OO language dumb fuck, generics is a fix for a problem that Go doesn't have, no class types, no need for generic types

>The designers have an odd aversion to functional patterns.
its not meant to be functional, if you want functional use Julia or Elixir, imperative has its place in server programming

>Golang was literally designed as C style programming for brainlets, Rob Pike had a quote on that.
anyone who uses C outside of kernel/embedded systems is a brainlet, there is nothing (((smart))) about using a language with zero bounds checking and a library built on UB

OOP didn't invent generics retard, that shit was invented in the 70s by functional programmers

Shitty error handlings
Not listening to the community needs

Deploy your apps as a single binary.

It is designed to scare away devs who are more interested in looking clever than writing maintainable code.

>oh no, my shitty type class shilling is going no where, now I'll pretend that (((generics))) is related to Lisp macros

what the fuck does lisp have to do with this? are you retarded?

It is quite interesting how it really does lock down all-too-clever bullshit and yet you can still do everything you need to do.

>to sort an interface, you need to define a wrapper interface slice for the interface and methods for comparing, swapping, and taking the length of this wrapper.
I love having to write the boilerplate for every sorting method. Generics couldn't possible improve on this.

Attached: sorting.png (946x827, 148K)

>go
Big Yikes from me dawg

>muh generics
yeah, I would totally love using C++ templates to do that, I love how templates hides all the repeated code you still have to write with

Look up the sort.Slice function.

what the hell are you even talking about? are you esl?

>unironically takes an empty interface
so the performance is dogshit, go it

Attached: Screenshot_2019-05-23_12-10-38.png (582x231, 24K)

how the fuck does that less function work for slices which don't contain ints? are those indices?

Correct. It's an in-place sort.

it doesn't you need to represent your interface in such a way that it can be sorted using integers
why you would ever need a generic sorting algorithm is beyond fathoming to gophers

jesus christ, this language is a train wreck

Do you index your slices with non-integers? How?

Here is the earlier example worked using the sort.Slice method.
package main

import (
"fmt"
"sort"
)

func main() {
fmt.Println("Hello Jow Forums")
fruits := []string{"peach", "banana", "kiwi"}
fmt.Println(fruits)
sort.Slice(fruits, func(i, j int) bool { return len(fruits[i]) < len(fruits[j]) })
fmt.Println(fruits)
}


Which will output
Hello Jow Forums
[peach banana kiwi]
[kiwi peach banana]


You can try it yourself on play.golang.org/

anything which isn't stored in a flat array

those aren't slices

You may have noticed an unexpected feature of this interface - the less function given to the sort.Slice method must be "custom-rolled" for each call, as it binds the variable indexed into at declaration.
Consider the below code snippet, I had intended to sort my vegetables array but didn't update the comparison function to refer to the vegetables variable - whoops!
package main

import (
"fmt"
"sort"
)

func main() {
fmt.Println("Hello Jow Forums")
fruits := []string{"peach", "banana", "kiwi"}
vegetables := []string{"cucumber", "yam", "terryschiavo"}
fmt.Println(vegetables)
sort.Slice(vegetables, func(i, j int) bool { return len(fruits[i]) < len(fruits[j]) })
fmt.Println(vegetables)
}


Which returns
Hello Jow Forums
[cucumber yam terryschiavo]
[cucumber terryschiavo yam]


A silly mistake, but once we can make.

If you sort in multiple places you just make the sort.Interface type, don't be retarded. Or you make a higher order function.

Sorry user, I was born retarded and will remain retarded - it can't be helped.

found the php dev

afaik a slice is just an array of pointers
if all you care about is sorting the references, then that is fine, but if you want to sort the underlying data structure then it won't help you

>terryschiavo
KEK

we'll never let that joke die

Lol no generics

People aside from Google's pajeets and chinchongs codemonkeys are unironically using go ?

Learn rust faggot

Attached: rmm19vt8vp911.png (2512x1018, 421K)

Attached: Screenshot_20190523-181252_Chrome.jpg (1439x1287, 468K)

Rust have retarded syntax and no jobs. No thanks

All you have to do is look at the gopher mascot and that will tell you everything you need to know