Is Go still a viable language or is it being phased out?

Is Go still a viable language or is it being phased out?

Other urls found in this thread:

yager.io/programming/go.html
youtube.com/watch?v=pb3-tq4f_bs
play.golang.org/p/1SsvyqsWxc
blog.golang.org/errors-are-values
jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/
twitter.com/NSFWRedditVideo

why, my peanus weanus of course :)

Uh. Ok.

Any reasonable responses not relating to genitalia?

Your mom's box

>2016
>phased out
kek

It's one of the most promising language out in the garbage programming language there is today

Phased out for what?

>promising
it's literally shit

>>>suckless

>it's literally shit
top keeek

explain yourself, nigga

fucking mods deleting my posts

>muh can't compile because I don't use this variable I declared which I will use later
>muh half code is error checking
>it crashes at runtime anyway
>it really doesn't have any interesting features

Phased out for networking, web servers and system applications.

"So why should I hire you?"
-"I-I know how to code in Go"

Uh so enforcing good code production means "shit programming language"? stfu dude

HAHAHAH so fake

>it crashes at runtime anyway
Kek. Go is rock solid. Meanwhile your RUST MUUH SECURE (TM) program crashes because somewhere an unwrap() in one of your 0.1 alpha dependencies blew up.

>muh can't compile because I don't use this variable I declared which I will use later
What is underscore.
>muh half code is error checking
Try catch generates more boiler plate than testing err for nil.
>it crashes at runtime anyway
It shouldn't. File a bug and they'll fix it.
>it really doesn't have any interesting features
Yeah, goroutines and channels are shit. Tony Hoare is a fucking joke.

Try serializing data. It might very well crash at runtime.

Networking is pretty much the only thing Go seems quite ok for.

Post an example on Go playground.

everything about Go is awesome and is done the way it should have been done 20 years ago

- structs act like classes but functions are only attached to structs by name, not declared in stucts, this make refactoring a breeze and avoids type system constraints

- stucts are modules, you dont need to wire together files and libraries by writing 1000 LoC make files, everything happens automatically for you, no more linking libararies, no breaking dependencies, everything just works.

- You have a go path on your computer, any code you download into your go path is readily available to you, there are no conflicts because everyones library is in their own namespace that cant clash with anyone else

- message passing concurrency is built into the language, no more thread locking and race conditions

- has type inference, type system is very strong, no casting hell, inheritance is handled better than the typical OO way so you dont get trapped into your own type system

- Its a very fast language, has garbage collections, you dont have to resort to stupid pointer tricks to get speed, writing sane understandable code gives you speed

I don't remember, it's a while since I coded anything in Go. I think I had it crash at runtime when deserializing data I received over the network. Can't remember the actual issue in detail but Googling shows a few people who got runtime errors for related problems. Why would it do that instead of just throwing an error into that err variable I need to bring with me everywhere?

Because it's a bug in the code that has to be fixed. Normally it would return an error.

>still

>Hahaha, no seriously: Why?

I'm not flaming anyone, but when I was looking for a new language to pick up, I seriously considered Go, but later decided against it. This guy explains better than I ever could some problems:

yager.io/programming/go.html

pic not related

>B..but in Rust and Haskell
Stopped reading.

>- You have a go path on your computer, any code you download into your go path is readily available to you, there are no conflicts because everyones library is in their own namespace that cant clash with anyone else

If you think that lumping all libraries into a tree of folders somehow solves the very hard problem of dependency management, and that everyone else is just too retarded to do it, then you are way dumber than you think you are.

Or you know... Scala, Java, C# etc... just because his examples are in Rust and Haskell it doesn't mean those are the only two languages that have these features. The inability of the Go community reply to any challenge with an argument, rather than "it's so beautiful" circle-jerking was also a factor why I ended up deciding not to pick it up.

sure, Im so dumb, I guess I cant be smart enough just keep pretending the problem is unsolvable and keep doing it the C++ way

>muh can't compile because I don't use this variable I declared which I will use later
comment it
>muh half code is error checking
not more or less code than exception handling
>it crashes at runtime anyway
what the fuck are you talking about
>it really doesn't have any interesting features
"I ran out of shit to say better pull the last two points out of my ass"

not having shitty new unimplementable features is what makes Go good

>comment it
Have the programmer do more work so the compiler can be lazy! It's the Go way!

The article does not understand the Go paradigm. The idea is to keep things as simple as possible. So no operator overloading, function overloading exception etc. It's just clickbait.

>so the compiler can be lazy!
it'd be easier/cheaper not to enforce it

it also takes a split fucking second of your time

>The idea is to keep things as simple as possible.
And that's a retarded idea. It keeps the language simple, which requires making programs complicated to make up for the lack of power.

The programmer has to do more work because the language designers decided to ignore all modern ideas.

>it also takes a split fucking second of your time
It takes a few seconds of my time. It takes a microsecond of the machine's time. Even if it's a minor problem, it is inexcusable.

And this one example is not a huge inconvenience, but it reflects the overall design of the language. The designers decided to offload a huge amount of work to the programmer that would be handled by the compiler in better languages.

all the complexity of C++ does not add power to the language, its just using templates and memory allocation to handle things that could be handled by a simpler language. the complexity of the type system or lack thereof just creates 'experts' who spend their lives hacking together coding styles that do nothing but fix a inherently typeless language

>And that's a retarded idea
it's the unix philosophy and it's always worked

>It keeps the language simple, which requires making programs complicated to make up for the lack of power.
haskell and rust are there if you need to do something Go can't

most of the time you'll get there faster and more easily with Go however, because you don't depend on expensive constructs that make specs needlessly painful to implement

>b-but my language should enable my shitty habits
golint, gofmt and govet all ship with the compiler and stdlibs, you have no excuse

and if one extra keystroke throws you off the entire thing, please stay the fuck away

youtube.com/watch?v=pb3-tq4f_bs

get help

Well Go as sure as fuck doesn't solve it. Can you even request a specific version of dependency? And how do you solve the problem of different dependencies requiring different versions of the same dependency?

its really simple, you dont have to explicty declare dependenices, the compiler treats structs (classes) like modules and compiles them to modules, there is no disconnect between the idea of classes, libraries, modules, because they are all the same thing in Go

not gonna lie, i fucking love youtube accounts like this

>muh generics
>muh operator overloading
typical its-not-like-C++-so-its-bad shilling

Why would you think I'm defending C++? C++ is not a modern programming language.

>it's the unix philosophy and it's always worked
No it fucking isn't. The UNIX philosophy is about modularity and composability. Simplicity is part of the philosophy, but only because it enables re-use. Design should be local, so users can easily combine programs into larger ones without knowing the details of each program.

Go does the exact fucking opposite. Go makes the language simple at the expense of versatility and modularity. The lack of generic programming and proper error handling means problems are anything but local. In every single part of the program, you must keep track of error and remember what your data structures contain. You get no help from the language.

No one is praising C++. C++ is crap. ALL decent languages (and most non-decent ones) support generic programming.

>And that's a retarded idea. It keeps the language simple, which requires making programs complicated to make up for the lack of power.
Surprisingly, that's not true. Compare the Go source to the Java source. The former is much easier to understand because it has very few abstractions.
>The programmer has to do more work because the language designers decided to ignore all modern ideas.
This is how you sort an integer array in Go:
type intSlice []int

func (s intSlice) Len() int {
return len(s)
}

func (s intSlice) Swap(i, j int) {
s[i], s[j] = s[j], s[i]
}

func (s intSlice) Less(i, j, int) bool {
return s[i] < s[j]
}

Behold, sorting without generics.

>can't compile because I don't use this variable I declared which I will use later
What the fuck is that even supposed to mean, you either use something or you don't, if you're declaring it and getting an error you're not referencing that variable anywhere in which case it's an error, that should be true outside of Go as well, why would you declare or allocate space for something you're not going to use? How is this even a complaint.
You're implying error handling is bad too, is this a joke?

i like go but some of the things you said are wrong
>no more thread locking and race conditions
wrong
here's a fun one. assuming foo() is a library function, how can a user accidentally cause a deadlock in the following code:
play.golang.org/p/1SsvyqsWxc

>no casting hell, inheritance is handled better than the typical OO way so you dont get trapped into your own type system
there's a lot of casting hell due to its lack of generics, i'm not gonna judge whether this generics are really better than casting hell, though
there's no inheritance

>you dont have to resort to stupid pointer tricks to get speed, writing sane understandable code gives you speed
this is wrong. as with every language that allows you to use pointers, if you want cache efficiency you'll have to design your types differently.
i presume go has pointers for exactly this case (otherwise hidden pointers are a lot nicer), but you'll still have to design differently to achieve that

this post is bad
when learning go you'll have to consider that the go devs value design factors other than the ones embodied in functional languages like haskell
go takes a pretty heavy stance on the idea that too much abstraction (and too much power to abstract) is also a problem

>Behold, sorting without generics.
Sorting of INTEGER ARRAYS. Obviously generics are not required for a non-generic function. If you wanted to make it generic, it would become hideous.

Thank you for proving my point. Go programmers are just too retarded to understand what generics are for, so they don't think they're useful.

It's amazing that you think you understand the UNIX philosophy better than Ken Thompson and Rob Pike (who made Go!), both people which have worked on UNIX.

>go takes a pretty heavy stance on the idea that too much abstraction (and too much power to abstract) is also a problem
That is the Go philosophy, and it's retarded.

You can sort any data type you want.
I do understand what generics are for. I wasted 4 years of my life writing Java. Generics are good on paper, just like OOP. Those things eventually bite you in the ass.

oh my the fact that i got exceptions now really means i don't have to think about errors in every part of my program

people like you cause mayhem
when you're using exceptions you still have to document every single exception that can occur at every level
if you don't, your code is fucking shit

>Go still a viable language or is it being phased out

Go is an english word you fucking faggot, now suck my dick.

>The UNIX philosophy is about modularity and composability
>Go makes the language simple at the expense of versatility and modularity
How is this the exact opposite? You sound like you're contradicting yourself.

>lack of proper error handling
You really need to elaborate on how the Go method of error handling isn't "proper" because your other complaint is
>In every single part of the program, you must keep track of error and remember what your data structures contain.
Which sounds like you're contradicting yourself.

I don't understand why you would treat this as an issue either, am I reading this wrong, because the way I'm interpreting this is
>you need to understand your data structures and keep track of errors
Why would forcing a programmer to understand what they're working on be bad ever in any language? How is the language supposed to "help" with something like this in a meaningful way without detracting from its versatility?

golang is probably the best language out there if you want to build some kind of scalable server application but for everything else it doesn't really have any benefits over more established languages

I've worked with a lot of overengineered and I don't think it's retarded.
Bad devs underengineer.
Good devs overengineer.
Both things are equally fucking annoying.
People like FP languages because it takes away the power to use state.
It's a lot more understandable now that we took some power away!
At the same time, most FP languages introduce a lot of power via abstraction, and people do nothing but get caught in their abstractions.
The power to abstract corrupts just like the power of state.
Power corrupts, even the holy tarpit paper mentions that!
You duplicated some code, so what. Duplicated code is decoupled, non-duplicated code follows DRY.
The two are often opposites, both yield advantages in different use cases.
Google had a policy to never duplicate code and is currently reversing a lot of it because they're suffering a shit load from the pointless abstractions people built because of it.
Most Go projects are a lot more straight forward because you don't have to learn about the mini-world the devs built for themselves themselves. This is just personal experience, but working on Go open source projects has been a lot more enjoyable than working on open source projects of other languages.
It isn't enjoyable when every programmer uses their own set of abstractions because the language makes abstraction so easy.

This thread is better than the dpt.

>exceptions
Once again, your ignorance of modern programming languages is showing. You are ignoring 30 years of progress because you seem to think programming language development stopped with C++.

I was not talking about exceptions. I would much rather have algebraic data types. But even exceptions would be better than the Go system, which requires you to manually check for failures with little help from the language.

algebraic data types are almost completly the same as golang errors with multiple return, which is why i assumed you were talking about exceptions (because why would you consider something better that is almost the same?)

please point out a case where an algebraic data type yields significant advantages over error types + multiple return.
no, being a minor bit more strict and monadic control flow are not significant advantages, they're very slight (also, monadic control flow only works very well in pure FP languages, it hides certain aspects in imperative languages)

This is the single biggest complaint I see and it makes me fucking furious, it proves the point that programmers should never be trusted, people are seriously complaining that Go is too safe and complaining that they have to handle errors, as if you don't have to do that in every language, it leads me to believe these people do not practice such a thing in other languages that don't enforce it which doesn't make the language inherently better and certainly doesn't make their code better.

>Everything that is syntactically legal that the compiler will accept will eventually wind up in your codebase
The strictness of the Go standard compiler is possibly my favorite feature, no slop allowed, anything that tries to circumvent the compiler sticks out like a red flag.

The fact that Go packages are not versioned with the standard tools demand that people make and use stable apis, non of this "we have to use some version from 5 years ago which has 18 vulns in it" bullshit. Obviously people are trying to circumvent this as well with external tools but again it's obvious when someone is breaking the standards and is an instant red flag.

If your program relies on hope alone and you don't give a damn to check errors for correctness, your program is shit, no matter what it's written in.

If your program relies on non-standard hacks and huge build systems just to compile, it's a bad program, no matter what it's written in. I am glad that Go is forcing people to do better.

>2016
>try catching or even testing err for nil

it's the same with inheritance
people were complaining that go has no inheritance
the reality is that all the code you don't have to write with inheritance is implicit and subject to the fragile base class problem
with inheritance and exceptions, you'll still have to think about the code you don't write, and if you don't, bad shit happens
the fact that it's implicit is pretty annoying when you you're looking for good maintainability, anything you can very easily miss (like undocumented exceptions or fragile base class problems) and is implicit sucks

>people were complaining that go has no inheritance

what the fuck, it's not implied that go even needs that

why do people learn one language and then think that others should behave the same way?

so, no one has found a case where the user can cause a deadlock?

>I was not talking about exceptions. I would much rather have algebraic data types.
>You are ignoring 30 years of progress
You are ignoring even more.

You really think algebraic data types are a good way of handling errors? Look at how Multics PL/I and Common Lisp do it, or your CPU for that matter.

But good error handling is incompatible with functional programming dogma.

>Look at how Multics PL/I and Common Lisp do it, or your CPU for that matter.
And of which would be better than how Go does it.

I agree completely.

I see this way more than I'd like too. I guess it's hard to fault people for wanting familiarity but I sure can fault them for demanding it.

I'm not going to make any kind of argument here but what I will say is that your example is one of bad practices, the sync package states that
>...intended for use by low-level library routines. Higher-level synchronization is better done via channels and communication.
Your example obviously has it backwards so I'm not sure what point you're trying to make exactly. If you don't use mutexes directly (which you're not forced to) then you won't have to worry about deadlocks.

keep in mind exceptions and conditions don't work as well anymore in concurrent systems
evm languages get this right, go takes an approach that is a lot simpler but more explicit.

the waitgroup is just there to quickly assure that the foo goroutine terminates before the main goroutine, it isn't relevant to the fact that foo() is prone to possible dead locks.
also, waitgroups aren't subject to the warning in the package overview, that applies to mutexes mostly (gopl also encourages waitgroups as good practice).
a blocking channel is analogous to a locked mutex, while an unblocked channel is analogous to an unlocked mutex.
when two lock/unlock phases cross each other, you get a deadlock.
in this case the user can cause a deadlock by sending to ch in a function passed to foo.
when the channel is full, the function deadlocks.
channels do not solve the issue of deadlocking (and in fact, pretty much every piece of go literature, be it gopl or anything else) pretty clearly states that go channels do not solve this issue.
there are numerous examples for this and this is just one of the more dangerous ones (because it's so implicit) i've encountered when writing a monitor goroutine for a scheduler.

Fair enough, for reference I'm not the user arguing Go solves deadlocking. However, I personally have found it quite easy to avoid or at least detect in Go. I was confused by your example mainly because the thought popped into my mind "if you're letting users define and then pass in functions there's nothing you can do to stop them really". I feel like in a case like that the onus is on the user to make sure they're not doing anything non-thread safe, much like is true for other languages. I'm curious if the standard race detector would catch a problem like you described.

the issue is that the function doesn't really contain anything the user may consider non-thread-safe.
you'll always have to think twice about the situation that occurs when a channel starts blocking (no, sorry evm guys, infinite channels don't solve this issue either, unbounded resources cause different issues).
in the normal consumer-producer scenario this doesn't occur, but in more advanced concurrent code you're fairly prone to issues like these.
this issue has two sides. on one hand you gotta bash the fact that channel blocking is analogous to mutex locking into your head and have to analyze your code with this in mind (this is annoying for people that have been used to sharing state, they're used to spotting deadlocks in normal locking/unlocking, but in the case of channels it's rather implicit).
on the other hand monitor goroutines localize synchronization to a single place, while with mutexes synchronization is usually spread all across the code.
this means that it's easier to track down where code channels are "unlocked", but finding where channels "lock" is still as difficult.

race detectors would likely detect it when it occurs. as long as the channel doesn't block it wouldn't detect it (which makes sense if you roughly know how race detectors work).
this is especially dangerous when the channel size is large, meaning the issue doesn't occur often (or even worse, only when somebody tries to DDoS your service, locking up the entire thing by accident as a bonus!)

Okay guys, I've not really invested much time in looking at Go, however, the things people appear to dislike about the language make it sound attractive. Would you recommend Go to a scientific Fortran77/95 programmer who avoids C and newer Fortrans because they are too powerful?

I'm sure it will be a good language once I don't have to make 10 directories with just one that allows me to actually compile code and another that keeps my code files which I'm not allowed to access unless in root.

It's fucking garbage and tries to be special and making anything permanent like GOHOME or GOPATH is a bitch.

It's like comparing JavaScript to C and saying JavaScript is actually better in most cases. In other words, it's beyond retarded. So retarded there isn't even a word for just how retarded it is.

The language sucks ass, directory branching for days, can't compile unless you set up the path and home for the workspace becauae you can't just make a file wherever you want cuz freedom is DUMB XDDD!! The compiling process is fucking brain-dead retarded as shit, and it's gotta be otherwise ITS NOT ORIGINAL N SPESHUL ENUFF XDD

GO is shit

D is the GOAT

unwrap() is completely justified when you want something to crash

like when you invoke my program with arguments that are not valid UTF-8 sequences

why the FUCK should I give you a descriptive error message when you went out of your way to give me data that's not even a valid string? No real users are affected by this, only you with your "ha, I made your program crash"

>once I don't have to make 10 directories with just one that allows me to actually compile code
go build
in any directory with go code in it will build a binary. If you don't like it you can just use make and gcc too. What are you even complaining about.

>when you went out of your way to give me data that's not even a valid string?
Do you actually assume all erroneous data is sent intentionally? That's such a bad way to think.

It's a shitty language but it's probably going to be huge. It's already seeing far more adoption than languages like Scala and Github activity from large companies is rising incredibly fast.

I really wish F# had a cross platform native compiler.

first of all, unwrap() doesn't segfault, it exits the program in a nice way with an error message

second of all, it's used for corner cases where the data is not valid so it's pointless to continue with the program, so exiting is justified

finally, if your thread unwraps, your program doesn't quit, your other threads still run

also, if you want a nice error message you can just use .expect("your string is not valid") or something like that

I don't see how having a wrapper for "please exit the program on this error condition" is a bad thing, since you can just avoid using it

package main

import "fmt"

func main() {
var a [2]string
a[0] = "Hello"
a[1] = "World"
fmt.Println(a[0], a[1])
fmt.Println(a)

primes := [6]int{2, 3, 5, 7, 11, 13}
fmt.Println(primes)
}

is this...a joke?
this is not an array, this is a tumor sack filled with ordered elements

What does that have to do with my question?

? looks p standard to me

so much this

if you cant use java/c#/c++/c/objective-c then you're automatically in the minority of programming

Sup Forums needs a really big fucking reality check, these languages are fun to PLAY with, but they are not used in very many production environments for a reason.

inb4 "you forgot javascript"
no, i didnt. I just don't consider that piece of shit a language

>objective-c

as ritchie said in the intro of the unix haters handbook, if your argument is purely metaphorical, your argument is shit.

I don't actually assume it, but there are error conditions where exiting is the best solution

>Compare the Go source to the Java source. The former is much easier to understand because it has very few abstractions.

What Java source? In most cases, the code in the Java standard library is very easy to understand.

That's a lot of bloat for sorting an array. In most languages, including Java, sorting any collection is a one liner even when using a custom comparator function.

It may be standard, but the reason I discard most "standard" langs is because of their dreadful array handling.
program array
implicit none

integer i
integer arr(10)

arr=0
write(6,*) arr(1:5)

end

>You're implying error handling is bad too, is this a joke?
No he's complaining that Go's error handling is bad. Using a right biased Either type (like Haskell, Rust, F#, ML) and sum types is far superior and lets you build abstractions to cut out a lot of needless boilerplate. Even basic exceptions are far superior to multiple return where one side is nil.

>lets you build abstractions to cut out a lot of needless boilerplate
What prevents you from doing this in Go?
blog.golang.org/errors-are-values

that user doesn't know what he's talking about
interfaces solve a subset of problems that generics solve, but in a different manner
they don't replace generics

again, go's lack of generics has had the side effect of people overengineering less and even famous people from the fp community like erik meijer have started doubting whether generics are worth it

if there was a way to easily keep people from overengineering at a large scale without taking some power to abstract away (same case can be made for use of state) then i'd be damn happy with that instead of what go does in terms of abstraction or pure fp languages do in terms of state, but sadly, power corrupts.

did he actually say that?

please refer to and show a concrete example instead of only asserting things

To the contributers to this book:
I have succumbed to the temptation you offered in your preface: I do
write you off as envious malcontents and romantic keepers of memories.
The systems you remember so fondly (TOPS-20, ITS, Multics,
Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture,
they are fertilizing it from below.
Your judgments are not keen, they are intoxicated by metaphor. In
the Preface you suffer first from heat, lice, and malnourishment, then
become prisoners in a Gulag. In Chapter 1 you are in turn infected by
a virus, racked by drug addiction, and addled by puffiness of the
genome.
Yet your prison without coherent design continues to imprison you.
How can this be, if it has no strong places? The rational prisoner
exploits the weak places, creates order from chaos: instead, collectives
like the FSF vindicate their jailers by building cells almost com-
xxxvi Anti-Foreword
patible with the existing ones, albeit with more features. The
journalist with three undergraduate degrees from MIT, the researcher
at Microsoft, and the senior scientist at Apple might volunteer a few
words about the regulations of the prisons to which they have been
transferred.
Your sense of the possible is in no sense pure: sometimes you want
the same thing you have, but wish you had done it yourselves; other
times you want something different, but can't seem to get people to
use it; sometimes one wonders why you just don't shut up and tell
people to buy a PC with Windows or a Mac. No Gulag or lice, just a
future whose intellectual tone and interaction style is set by Sonic the
Hedgehog. You claim to seek progress, but you succeed mainly in
whining.
Here is my metaphor: your book is a pudding stuffed with apposite
observations, many well-conceived. Like excrement, it contains
enough undigested nuggets of nutrition to sustain life for some. But
it is not a tasty pie: it reeks too much of contempt and of envy.
Bon appetit!

I was not making an argument, I was stating an opinion, which I may back up with arguments, granted, but don't have to. Here's a handful of arguments
1) having to write [n]x to declare an array is of length is literally backwards as fuck, because not only breaks it any mathematically inspired notation, it misses one thing:
.thgir ot tfel morf daer yllausu elpoep
2) if you declare the type of a variable in the same line you assign it a literal value something has gone terribly wrong because
a) either the compiler should already know the type since integer literals should obviously be of type int if nothing else has been declared, making the declaration of the type redundant
or
b) you (arguably) sacrificed readability for the sake of saving 1 LOC.

That and Rust are probably some of the more promising languages. It's a pretty great language for team-based stuff. Certainly prefer it over Java and C++.

>even famous people from the fp community like erik meijer have started doubting whether generics are worth it

Interesting Twitter conversations on this with a lot of big names chiming in. Haven't seen much from Slava Pestov since he went to work at Google and it's interesting to see that he's now at Apple working on Swift.

This is true
Go is good when working with other people

1 man show is OK to use functional langauges

jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/