Is Go still a viable language or is it being phased out?
why, my peanus weanus of course :)
>>54739640
Uh. Ok.
Any reasonable responses not relating to genitalia?
>>54739712
Your mom's box
>>54739630
>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?
>>54739748
>promising
it's literally shit
>>54739748
>>>suckless
>>54739830
>it's literally shit
top keeek
explain yourself, nigga
fucking mods deleting my posts
>>54739860
>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
>>54739777
Phased out for networking, web servers and system applications.
"So why should I hire you?"
-"I-I know how to code in Go"
>>54739918
Uh so enforcing good code production means "shit programming language"? stfu dude
>>54740017
HAHAHAH so fake
>>54739918
>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.
>>54739918
>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.
>>54740216
>>54740181
Try serializing data. It might very well crash at runtime.
>>54740017
Networking is pretty much the only thing Go seems quite ok for.
>>54740574
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
>>54740707
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?
>>54740876
Because it's a bug in the code that has to be fixed. Normally it would return an error.
>still
>>54740066
>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:
http://yager.io/programming/go.html
pic not related
>>54741141
>B..but in Rust and Haskell
Stopped reading.
>>54740872
>- 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.
>>54741249
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.
>>54741270
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
>>54739918
>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
>>54741393
>comment it
Have the programmer do more work so the compiler can be lazy! It's the Go way!
>>54741334
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.
>>54741429
>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
>>54741437
>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.
>>54741476
>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.
>>54741477
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
>>54741477
>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
>>54741507
>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
>>54739893
https://www.youtube.com/watch?v=pb3-tq4f_bs
get help
>>54741364
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?
>>54741622
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
>>54741610
not gonna lie, i fucking love youtube accounts like this
>>54741141
>muh generics
>muh operator overloading
typical its-not-like-C++-so-its-bad shilling
>>54741582
Why would you think I'm defending C++? C++ is not a modern programming language.
>>54741606
>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.
>>54741793
No one is praising C++. C++ is crap. ALL decent languages (and most non-decent ones) support generic programming.
>>54741477
>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.
>>54739918
>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?
>>54740872
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:
https://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
>>54741141
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
>>54741999
>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.
>>54741887
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.
>>54742144
>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.
>>54742148
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.
>>54741887
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
>>54739630
>Go still a viable language or is it being phased out
Go is an english word you fucking faggot, now suck my dick.
>>54741887
>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?
>>54739630
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
>>54742196
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.
>>54742230
>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.
>>54742366
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)
>>54742230
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.
>>54740216
>2016
>try catching or even testing err for nil
>>54742489
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
>>54742557
>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?
>>54742105
so, no one has found a case where the user can cause a deadlock?
>>54742366
>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.
>>54742632
>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.
>>54742557
I agree completely.
>>54742571
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.
>>54742105
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.
>>54742682
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.
>>54742879
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.
>>54743019
Fair enough, for reference I'm not the Anon 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.
>>54743094
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?
>>54739630
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
>>54740181
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"
>>54743282
>once I don't have to make 10 directories with just one that allows me to actually compile codego 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.
>>54743379
>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.
>>54739630
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.
>>54743413
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
>>54743471
What does that have to do with my question?
>>54743482
? looks p standard to me
>>54740066
so much this
if you cant use java/c#/c++/c/objective-c then you're automatically in the minority of programming
/g/ 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
>>54743511
>objective-c
>>54743482
as ritchie said in the intro of the unix haters handbook, if your argument is purely metaphorical, your argument is shit.
>>54743484
I don't actually assume it, but there are error conditions where exiting is the best solution
>>54741999
>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.
>>54743498
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
>>54742087
>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.
>>54743637
>lets you build abstractions to cut out a lot of needless boilerplate
What prevents you from doing this in Go?
https://blog.golang.org/errors-are-values
>>54743601
that anon 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.
>>54743574
did he actually say that?
>>54743637
please refer to >>54742432 and show a concrete example instead of only asserting things
>>54743677
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!
>>54743574
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.
>>54739630
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++.
>>54743674
>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.
>>54742319
This is true
Go is good when working with other people
1 man show is OK to use functional langauges
http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/
>>54743468
Soon
Microsoft are working on .NET native for F# in the .NET core
It seems obvious that Go and Swift are both going to be extremely popular. They're the only two languages right now that have any hope of getting anywhere near as popular as C++, Java or C#.
>>54743752
i won't really bother arguing about syntax with you because it's generally pretty pointless
if you didn't like C, you're not gonna like Go
on your second argument, go's integer literal are constants, and constants in go are mostly untyped (they've got pretty much unlimited precision as well).
if you don't declare the type of the array, how is the compiler gonna know which one of the following you mean?
uint8
uint16
uint32
uint64
int8
int16
int32
int64
int
uint
is it supposed to just default to the one that's used the most?
either way, in the case of that array literal, go doesn't actually see integer literals, it sees untyped constants, which yields a lot of other benefits related to constants in go (which are pretty neat).
>>54743838
Swift is definitely on the other side of philosophy, add stuff!
Tbqh in years to come, these languages (not go) would look like functional languages with a worse syntax
>>54743752
>1) baby duck and also wrong
>var a [2]string
>var a : variable 'a'
>is an array : [
>of 2 : 2]
>strings : string
>variable 'a' is an array of 2 strings
How isn't that left to right?
>since integer literals should obviously be of type int if nothing else has been declared
Why have the compiler make assumptions instead of forcing the programmer to be explicit, in addition why create inconsistencies with the syntax? The syntax is amount, type, data, this is true for all types, standard or user defined, no special exceptions just to save 3 keystrokes for "int". I don't see how being explicit is "terribly wrong", you shouldn't assume that just because someone is supplying integer literals that they want plain integer values, if you do you're assuming/asserting the size and signedness of them, the compiler doesn't know what you want, you have to and should tell it.
>>54743872
The Swift developers have said they're not interesting in adding much and the language is pretty simple as it is. Of the few rough edges it has most are there for Objective C interop.
>>54743890
>>54743752
Great I fucked up my example and now I look like an idiot. The first line of the reading is obviously in the wrong order, I couldn't decide which would be more appropriate and I drank a shitload of coffee. Will you forgive me Anon?
>>54743857
>if you didn't like C, you're not gonna like Go
fair enough. After all my usecase is quite.. fringe, so I honestly can't expect many langs to do it for me.
>Go's integer literal are constants, and constants in go are mostly untyped
in that case that argument obviously falls flat on it's ass, yes.
>>54743942
>>54743890
first off
>expecting mathematical constructs to read like a mathematical construc == babyduck
fuk right off with that attitude. You can call me petty for nitpicking syntactical elements, but referring to that as baby duck is uncalled for.
fair enough you can read it like that, yes. but then it would only be consistent to say
[i,j,k]M is the tensor element M(i,j,k), or depending on convention M(k,j,i)
>>54743942
also, you are forgiven. Not a morning person as well?
>>54744088
I'm not sure where I actually stand on it, should programs be looked at as more mathematical or more logical? Admittedly I'm not super familiar with the syntax of either of those 2, the amount of symbols in mathmatics has always been too much for me which is why I gravitated towards programming, even logical problems have crazy symbols sometimes, it's too much for me.
>Not a morning person as well?
I have to get a lot done before tomorrow, I figured coffee would help but here I am procrastinating and being mean instead of understanding.
>>54744324
I don't think it's something that can be made into a blanket statement. But as for numerical code I would say adherence to a more mathematical look helps translating formulas (well, which is literally what Fortran stands for). In the end it boils down to a matter of taste anyway.
Also, it's ok man. A rougher tone on 4chan is nothing I take to heart. Hope you get your shit done by tomorrow, deadlines suck.
>>54743511
>YOU GUYS NEED A REALITY CHECK.
>Intentionally ignore JavaScript, a language that EVERY webdev needs to know, because he doesn't like it.
kek.
>>54743717
>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.
Unix people should be thankful that their little hack got that far, but no, let's twist the knife in the wound.
When other people where inventing the GUI and the modern PC they were fiddling with text streams (actually they still are).
>>54739748
slobin on that google knob eh?
>>54741999
>what is the purpose of abstractions? to make programming more difficult
Go sucks.
I like that it's a clean and relatively minimal language, but there are a few too many traits I disfavor.
> GC - absolutely pajeet
> return tuples - generally quite inferior to union systems like Expected<T>, Rust enums, etc.
> panic/recover - basically exceptions in a non-OO language, which is retarded. defer is still a great mechanism though.
> forced canonical source formatting/indentation - great to keep legions of sweatshop POO IN LOOS in line, shit otherwise
> Rob Pike - what went wrong with him?
>>54739630
go back to >>>/leddit/ faggot
I've been into Lua recently
Golang is one of my favorite languages.
Go code is readable. Explicit error handling makes your control flow set-in-stone and easy to reason about. Composition and interfaces are intuitive and are a welcome departure from the rigid traditional OOP methodologies. And the concurrency primitives are just sweet.
The canonical formatting bothered me at first (muh opening braces), but it grew on me.
>>54747216
> dynamic typing
> 2016
Come on now.
>>54739777
Turnt down for what?
>>54739630
Goroutines are great. Interfaces are pretty good. Syntax is comfortable for anyone familiar to the C linage and enforces consistent style. I like the policy of "anything worth warning about should be an error" and attaching meaning to capitalization of functions.
The standard library needs a lot more. This will come with time.
make() and range are annoying and feel inconsistent. Type syntax for maps is awful. Slices are too inconsistent. Huge binary sizes are a mark against it for the intended purpose of system software.
Enforced directory structure for projects is terrible.
> delete element 3 from slice a
> a = append(a[:3], a[4:])
>>54743511
Go powers Docker. Netflix, New York Times, and a huge amount of companies [1] are using Go to power services that millions of people use daily. Go is good because it is simple. Crying about code style or not being able to leave unused variables in source(lol) is something only a junior dev or hobbyist would do. Go is also closing in on Java in terms of performance. Go is leaning towards a very bright future in the world of server-side software.
[1] https://github.com/golang/go/wiki/GoUsers
>>54739630
>it being phased out?
It never "phased in" in the first place.
Go is useless, utterly shit language pushed by Google for no other reason than propaganda and for the sole purpose of infecting others with their useless cancer shit.
Just use a proper language like everyone else does.
>>54739712
penis
>>54748806
Found the Oracle PR guy.
>>54747837
Pretty much how I feel. A nice thing I have noticed is that the team behind Go are at least aware of some of these problems, the binary size has been mentioned as an issue and so has the fact that new() and make() should not both exist but be one or the other. They've the ability to range over something without assignment which is nice but they can't change too much in Go1 due to their compatibility promise, I'll be excited if/when they start talking about the next revision of the language and am curious as to what they'd change.
>>54739630
In order for something to be phased out, it first has to be "in".
> no set implementation in the standard library
> impossible to create a type safe generic set
> most people end up using ridiculous map workarounds
Go is objectively awful.
>>54751050
>a map with no values and only keys is used like a set
>ridiculous workarounds
>>54751200
Yes, that's a ridiculous workaround.
>>54739630
Still?
It's young, has a niche and fills it well.
Learn it, if it looks like it might be useful to you.
>>54740872
you forgot
>the toolkit
is there anything more AWESOME than the toolkit?
>>54741141
>I like Go. I use it for a number of things (including this blog, at the time of writing). Go is useful. With that said, Go is not a good language. It's not bad; it's just not good.
that doesn't mean you shouldn't learn it
