(untitled)

Golang thread 3.0 Our favorite garbage collected language edition. 1st thread: >>>/λ/6019 2nd one >>>/λ/24586 turned into name calling tournament due to lack of any reaction from mod's side and get locked. Please don't misbehave this time.

>>24685 Question! What's the idea behind the decision of not having function overloading & default parameters & generics? Seems like it hurts the expressiveness of the language a lot, but what for?

>Question! I'm not a Rob Pike, but if you really want me I can try. >What's the idea behind the decision of not having function overloading & default parameters & generics? coz it 1) is like kicking dead whales down the beach 2) implementation is more complex and expensive than it's worth it 3) most programmers who need them is like kicking dead whales down the beach 4) most of use function overloading in existing code makes no sense and only obfuscate readability and ease of navigation >Seems like it hurts the expressiveness of the language a lot I see no connection between these things. > but what for? ease, simplicity, clean design, speed of compilation, not having features that most of programmers use to cut themselves and produce code that melts your eyeballs

>>24694 The purpose of Go is simplicity and decent performance. I don't understand the gripe about generics. If you want them, there are plenty of other languages to use. Go has filled a good niche for me, that is, for http services that I used to write in Python. Performance is quite a bit better and the code is simple and readable. I code for money and I don't obsess over being a "real" programmer so I don't care how intellectually stimulating Go is /isn't .

>>24694 >function overloading >default parameters What value does this bring? >generics contrary to common belief devs where never against it, they just have not found the right way to add it to the language. now that is changed and they are developing it. >>24697 >The purpose of Go is simplicity and decent performance. Generics would make go more simple and performant. Interfaces and type assertions have run-time cost as opposed to generics. Using generic containers and algorithms from widely used libraries(hopefully we will get a dsa lib in stdlib) are simpler than a bunch of ad hoc hacks. They are also likely more performant as much time could go into optimizing the dsa lib. >I code for money and I don't obsess over being a "real" programmer so I don't care how intellectually stimulating Go is /isn't . honestly you just seem dumb.

>>24696 >1) is like kicking dead whales down the beach So in other words, it would fit in just right with the rest of the language (^: >2) implementation is more complex and expensive than it's worth it Too hard and complex a feature for those poor compiler programmers at Google, eh? Rob Pike was right; Googlers really aren't the brightest. >3) most programmers who need them is like kicking dead whales down the beach At least try to make your sentences grammatically (if not semantically) valid. >4) most of use function overloading in existing code makes no sense and only obfuscate readability and ease of navigation Wrong. No one bats an eyelid when a language overloads the + operator for integers and floats. So why should overloading be forbidden for your own custom type (e.g. you define a quaternion type and want it to have addition)? >I see no connection between these things. It's pretty obvious, though. These features allow to express the same things in a more concise, natural and straightforward manner by abstracting away unnecessary details. In other words, they enhance expressiveness. >ease Sure. It has to be easy enough for dumb Googlers. >simplicity More like simplisticness. There's a point where simplicity can turn into a liability. The simplest language is no language. >clean design Lack of those features means Go code is more verbose than it could be. Excessive verbosity is not what I would call "clean". >speed of compilation Kind of true, but sometimes making nice, concise code is more important. And something like generics will only seriously harm compilation times if abused. >not having features that most of programmers use to cut themselves None of these features are particularly dangerous, actually. Unless by "most of programmers" you mean dumb code monkeys, but why should anyone cater to those? >produce code that melts your eyeballs You should probably practice reading other people's code in many different languages. Try to get comfortable with various kinds of abstractions and ways to write.

>>24694 overloading isn't universally accepted as a good thing like type polymorphism is. and obviously neither is "default parameters"

>>24772 >makes for a language that's [...] easy to read Many languages claim to be easy to read, but in my limited experience I have to concede that Go has a better claim than most to that title. But rather than the items you list, I think the main reason is that there's not much of it at all. Python also claims to focus on readability, but Python is deceptively complex. You won't be able to read much of the code that people write with the Python you can learn on your first week, to follow your example. Scheme is definitely a small and simple language, but it has a heavy focus on extensibility and abstraction. A lot of the macros and idioms that seasoned schemers make frequent use of are non-trivial to wrap your head around. Haskell has beautifully clean syntax and few constructs (it's basically made out of function definition and function application), but, because of partial application, you can never tell from syntax alone whether a function is returning a primitive type or another function. All of these are languages that are easy to read, provided that you have a decent grasp on the language and standard library. Go, I'll have to agree, manages to set the bar lower than that, because of how little of it there is to learn and how predictable the standard library is. It's also easy to jump into Go and make useful stuff even with a loose grasp on the language itself - I speak from personal experience here. Obviously that's both good and bad, although my reckoning is that, all things considered, it leans more toward the good.

>>24776 >I think the main reason is that there's not much of it at all. If you're referring to the relatively small number of keywords and other aspects to the language (such as it only having one looping construct) then yes, that's what I was suggesting by "simplicity". I think another reason for its rapid uptake is how easy it is to get started with the tooling. It's all in a self-contained ~120MB archive. Install or decompress as appropriate for the OS, maybe install a language extension in one's IDE of choice, make sure the bin directory is in the path, and you're done. One of the funniest misplaced criticisms of Go is that it's somehow a "Google language", just because some of the developers are on Google's payroll. (If we go by that standard, Python is a Google language.) If anything I think Google's management is highly annoyed that slow-and-steady-development-pace Go has *totally* upstaged the floundering in-house-darling Dart, which they've been desperately promoting for various purposes without success for almost a decade.

An FYI for those unaware and who have wanted to get into crossplatform GUI programming in Go without dealing with Electron nonsense. Fyne (https://developer.fyne.io/) has hit v2, which includes data bindings and greatly improved widgets and theming.

https://www.youtube.com/watch?v=a6oP24CSdUg

How do you handle running of cleanup functions in main? obviousyl defer is not sufficient since they are not run on sigint

>>24977 I usually just start a second goroutine that waits for sigint.

>>24978 can u post example?

>>24979 I hope this works: package main import ( "fmt" "os" "os/signal" "time" ) func main() { c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt) go func() { <-c fmt.Println("Look away") os.Exit(1) }() for { fmt.Println("Look at me") time.Sleep(1 * time.Second) } }

>>24981 >>24979 >>24978 >>24977 ended up with this func main() { m, err := model.New("db.bolt", 50) if err != nil { log.Fatalln(err) } exit := make(chan struct{}) c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt) go func() { <-c log.Println("signal: interrupt") exit <- struct{}{} }() go func() { log.Println("Listening on localhost:3003") http.HandleFunc("/api/snippets", api.NewHandler(m)) log.Println(http.ListenAndServe(":3003", nil)) exit <- struct{}{} }() <-exit err = m.Close() if err != nil { log.Println(err) } os.Exit(1) }

>>24795 This looks pretty rad. I'm interested in seeing how this would be used for mobile.

>>24782 >One of the funniest misplaced criticisms of Go is that it's somehow a "Google language" A Google account is necessary to contribute to Go. Go is tied to Google, like it or not.

>>25033 >A Google account is necessary to contribute to Go. Yes, Go has deep Google ties. But you don't need to be part of the Google ecosystem to write in Go. If you want to see a real Google-infestation horrorshow, check out Dart. That language actually has telemetry in its tooling, and it's on by default. I'll give you one guess which language Google is ignoring for their experimental Fuchsia OS, and which one they're aggressively pushing. >>25030 >This looks pretty rad. I'm interested in seeing how this would be used for mobile. It's very cool so far. I've played with it for android work (I won't use anything IOS). It's definitely beta-quality in terms of features - it doesn't really integrate with some mobile-specific stuff yet aside from rotation sensors. And I've had some odd issues with CGo stuff like sqlite. But in terms of stability it's been great so far. No weird crashes, no graphical glitches. I think after another year of polish it'll be a really solid choice for cross-platform mobile development. The Fyne devs seem to be positioning it a memory-efficient alternative to Electron, rather than as a high-performance GUI toolkit (gioui is a better bet on that front). Fyne is all about ease of use and getting a cross-platform 2D GUI program up and running fast, without having to write a single line of CSS or HTML or javascript.

does anyone have an example of a well-written well-tested Go REST API I can study? Either a repository or a video/book where I can study a professional Go REST API.

>>25079 Maybe someone else can point you to an actual repo, but I really liked "Lets Go!" by Alex Edwards for learning how to use Go for webdev.

>>25052 It astounds me that what started as a search engine has turned into a tech manifestation of orwellianism. The fuarrrk?

>>25115 "Contributions to this project must be accompanied by a Contributor License Agreement (CLA)" really sums up what's wrong with big tech... CLA's are the anti-GPL

[that last snippet should have the break removed forgot to remove it while fuarrrking with in browser formatting braindamage]

disregard previous post fam my bad too many mistakes it wasnt clear. mods pls delete >>25676 and 25677 again now: OuterLoop: for { select { case x := <-chan1: f(x) break OuterLoop case <-chan2: if someshit { abc() break } lol() dongs() } } What the fuarrrk is wrong with Rob Pike and his beta orbiters? Why even have `break` in `select` when there is no default fallthrough? Just use an `if` and make `break` apply only to for loops LMAOOO. This isn't even an edge case, half or more of `select` statements are inside a `for` like what are you doing nigguh KEKLION. Here's how it would look if Go wasn't retarded: for { select { case x := <-chan1: f(x) break // breaks out of the for case <-chan2: if someshit { abc() } else { lol() dongs() } } } Imagine going through all the rabbit hole of discovering you can have intuitive switches (like what all other languages aside from C had from 70s onward), but then get so tunnel visioned about C you add a fallthrough keyword for "backwards compatability [of people with C braindamage]" and completely forget that structured progrmaming exists so you think you need a `break` keyword.

>>24694 The thing you need to understand about go is that the go team has put a lot of effort into consciously avoiding a C++ situation where you just add a bunch of garbage into the language bc it's nice to have with every minor update, then a year from now you realize you did a bad job implementing x or y feature, rewrite it, and then have to either make lots of compatibility-breaking changes (the solution chosen by e.g. Rust) or just add another api for the new functionality and count on people's IDEs or compiler warnings to remind everyone not to use the old API. Like a decade ago, Go had lots of compatibility-breaking changes, since the language was still being built on a basic level, but Go is a language that its creators needed to sell to corporations (particularly Google) as usable before they even started writing, so as soon as the basic functionality was nailed down the devs promised not to break compatibility in the future. A consequence of this is that they mandate a VERY rigorous process for making any substantial changes like adding generics, bc they don't want to add generics until they're done 100% correctly, dont violate the spirit of the language, and dont undercut any of the language's selling points, like fast compile times and overall simplicity.

>>24700 >So why should overloading be forbidden for your own custom type (e.g. you define a quaternion type and want it to have addition)? You can do that, just call it .Add All that capability sounds good on paper, but it is always abused. Like, "oh this operation is sort of vaguely similar to addition, so I'll overload + even though it's not associative. If you look at any big C++ project they all essentially use their own language. The people who've been working on the project see no problem with "oh obviously operator* is dot product for vectors, and of course cross product is .crossProductWithThisOtherVector" but anybody who stumbles on a bug and just wants to fix it and submit a pull request to get back to whatever they were doing is going to have a soykaf time.

Is Golang basically a new Java? Is it trying to replace Java?

>>26414 the language it's explicitly trying to replace is C Good luck!!

>>26415 I mean, Rust is trying to replace C formerly C++ Remember when Java too didn't have some of its features, like Golang with generics? And docker is basically a virtual machine with some performance benefit

>>26422 I'm not sure how each of the three lines in your post relate to each other exactly, not that I disagree with them individually.

>>26414 It's more like the "NodeJS is too slow or memory-gobbling for this microservice, let's write it in Go instead" language. >>26415 They refuse to make a GC-less version of Go, so Go will never be a system programming language.

Very cool language in case you love C but don't want to be tearing your hair out over forgetting to close files, memory management, finding good libraries, dangerous side effects and everything else that makes C frustrating to use. The only thing I don't understand is the relationship between Handle, Handler and HandleFunc. I've read a hundred articles about it but I need an eli5. I also don't get this weird thing where they apply methods to functions, it just feels extremely unnatural to me.

>>26426 >the relationship between Handle, Handler and HandleFunc Handle is just the name of the method that the server calls when it gets an incoming request. Handler is whatever data type you put the Handle method on. You can use it to store information you'll need for requests like database handles or whatever. And HandleFunc sets it up to work without the handler type (just a function not a method). If you've ever done any Linux kernel work, it's very familiar. Drivers will typically register a struct containing function pointers with the subsystem, then the subsystem will call those functions when things happen (e.g. device is added or removed) and will have access to a structure you can store information on the specific device in and information on the driver. >apply methods to functions Haven't seen that can you give an example? Normally you put methods on structs but you can also put them on other things.

>>26414 i think its more like statically typed python

>>24699 >contrary to common belief devs where never against it, they just have not found the right way to add it to the language. now that is changed and they are developing it. this also the general consensus among experienced go programmers was that it becomes an actual problem very rarely, so that's why they weren't pressed on adding generics for a long time. once the idea of go 2 (which won't actually happen since they dont have to break backwards compatibility) came around they took the oppurtunity to look into it more

>>26426 >Very cool language in case you love C but don't want to be tearing your hair out over forgetting to close files, memory management, finding good libraries, dangerous side effects and everything else that makes C frustrating to use. Yeah, this is largely why Go has carved out a nice niche as a network service language. Entire classes of C and C++ security problems simply cannot happen in Go, yet Go stays within spitting distance of C and C++ for memory efficiency and speed. And you get to take advantage of multiple CPU cores without any boilerplate at all, it's simply built-in to the runtime. It's a fantastic choice for network services. >>26424 >They refuse to make a GC-less version of Go, so Go will never be a system programming language. It might be worth taking a look at the new unnamed language that Drew DeVault and some others are working on (https://drewdevault.com/2021/06/24/finger-client.html). It looks like it's aimed at the same problem set C is aimed at, but with lessons learned from other modern languages like Go.

does Go have anything like IPython?

>>26435 So Handle is actually like a restaurant (which is the server) receiving an request to order food. Handler is the type of food the customer wants to order, let's say pizza and HandleFunc is when ... Nope. I don't understand. Let's try again but this time with explaining what methods are first since there is barely any material covering them properly. I've never touched the Linux kernel by the way.

>Haven't seen that can you give an example? func (app *application) home(w http.ResponseWriter, r *http.Request)

>>26435 Alright, I understand now: // If lainon visits https://lainchan.org/zzz we define in the zzzHandler function what we want to do upon an incoming request http.Handle("/zzz", zzzHandler) // HandleFunc allows us to pass in an entire function instead of the name of a Handler, what is this useful for? Looks very clumsy to me. http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {fmt.Fprintf(w, "Hello, %q",html.EscapeString(r.URL.Path))})

>>26460 Exactly right. As far as using Handle/Handler vs using HandleFunc, it's really just a matter of preference in how one organizes one's code. Sometimes careful organization with Handlers functions for complex logic, sometimes HandleFuncs for a simple one- or two-liner.

>>26456 Handler and HandleFunc are not used at the same time (for a given endpoint). They are two different ways to do it, either you use a Handler if you want to use a method to service the request or HandleFunc if you want to use a function. >>26460 Basically yeah. You don't have to inline the function, you can also pass a global function. HandleFunc is quicker for simple endpoints because you don't have to declare an implementation for the Handler type.

>>26456 why do you attach an image of a 14 year old on every post u make its kinda weird

>>26457 That's just declaring a method. application is some data type like a struct and you would call the method like myapp.home() app is like "self" in python or "this" in c++.

>>26467 lol, saved sometimes I wish there was a "don't nag me can't you see I'm working on it" flag, but then I think about all the big C projects I've worked on and the absolute abomination of Wno-error and UNUSED_PARAMETERs scattered throughout the code and makefiles and I start to think they had the right idea.

>>26468 No, the right idea would be for this """error""" not to exist, not even as an option.

>>26481 Why are you trying to compile code with an unused import? The main solution to an unused import error is to actually use the import. The solution to an editor automatically removing unused imports on save (which is a legitimate issue, fuarrrk vscode and its stupid defaults) is to either turn off that behaviour or stop using that editor. (Fun fact: gofmt doesn't remove unused imports. Only goimports does.) If you're looking to import a module for the initialization side effects, for example database drivers, just put an underscore before the module name like _ "github.com/mattn/go-sqlite3" These underscored imports don't trigger the unused-import error. Your cup runneth over with options.

>>26482 >Why are you trying to compile code with an unused import? Imagine you add a fmt.Println somewhere to check something, then remove it when no longer wanted, but you aren't gopher enough yet to have muscle memory to scroll back to the top of the file and remove the import. >inb4 hurr durr just use a debugger with conditional breakpoint triggered fancy logging which magically works in every context Imagine you are digging through code and import some struct somewhere to pass somewhere, then remove the instance of that struct, but you aren't Gopher enough to instinctivley scroll back up to the top of the file and select the line containing the import for that struct whose package you don't give enough fuccs to remember, then you go to compile soykaf, and it errors, and you have to go back to the file and remove the import. >b-b-but you outta memorize the entire project layout and its conventions before working on it not an argument since gophers are the "pragmatic" clique who's primary value is being informal. >The solution to an editor automatically removing unused imports on save (which is a legitimate issue, fuarrrk vscode and its stupid defaults) is to either turn off that behaviour or stop using that editor. (Fun fact: gofmt doesn't remove unused imports. Only goimports does.) No, once again, Go is at fault for making something that triggers your OCD autism into a compile error. But thank you, this is a very example of the rabbit hole you go down due to Go's retarded behavior. Now you have this: >delete line muhpackage.MuhFunc() <IDE automatically deletes the import >re-add line muhpackage.MuhFunc() <muhpackage is not defined <IDE remembers that muhpackage was previous defind by import muhpackage "soykafhub.com/lol/nogenerics/blah/blah/v3" <suggests to add it back nvm lol you wont understand the implications here

>If you're looking to import a module for the initialization side effects, for example database drivers, just put an underscore before the module name like >_ "github.com/mattn/go-sqlite3" >they want unused variables to be an error >they want a mere import statement to be able to have side effects >they added a syntactic construct to import a package without using it, without it being an "unused variable error"

that reminds me of this retard sh1t x, err := fuarrrkme() y, err := fuarrrkme() x, err := fuarrrkme() // error err := fuarrrkyou() // error WHAT ARE YOU DOING LMFAO NOBODY IS PAYING THIS CLOSE ATTENTION TO := AND = WHY THE FUCC WOULD I NOT WANT TO JUST SHADOW EVERYTHING WHEN I USE := oh yeah, because gophers are afraid of shadows, because they're pseudoscientist neckbeards who come up with false problems that need to be solved and virtue signal that they are saving the poor user (much like lint, CI, muh 100% code coverage unit testing, etc). you can see parallel here how erlang, in the process of copying the semantics of ML, chose to crash or compile error or whatever instead of letting variables shadow. okay, so now we have to have x, err := fuarrrkme(), and so now since it can be assignment, we have to decide if we want x[10], err := fuarrrkme() to be valid, and decide if we want x[10], err_ := fuarrrkme() to be valid, and f(), err := fuarrrkme(), and f(), err_ := fuarrrkme(), and so on, and there have been compiler bugs here, as expected as neckbeards are deterministic NPCs that make the exact same errors by going down their dumbass NOT INVENTED HERE rabbit holes every decade. if fuccing logicians and people doing FORMAL PROOFS said shadowing is the way to do things, you better bet they are right. not make up your retarded conundrum of however the fucc =/:= work in go (i cant remember LOL there are too many edge cases. just because you havent thought of them doesnt mean they arent there)

>>26484 You are not supposed to have unused variables/dependencies. This just forces everyone to follow this. There is no reason not to, if it "nags" you just learn to ignore it. This way all software written in go is guaranteed to adhere to this. >Imagine you add a fmt.Println somewhere to check something, then remove it when no longer wanted, but you aren't gopher enough yet to have muscle memory to scroll back to the top of the file and remove the import. The gopher way is to be reminded that you no longer need it. >>26486 >must shadow instead of giving an error because someone said so And make the code work in ways that the programmer didn't anticipate, and so your code could shadow your libraries' without any errors.

>>26490 Just ignore them, pretty sure that it will just end up in a name-calling tournament. These people that act all confident about not being scared of unused imports are the same people that are grinding their teeth at 4AM over an arithmetic overflow bug that's hidden deep beneath piles of functions with side-effects. If you want to complain about every existing programming language and create drama please go back to 4chan.

>>26484 >>26485 >>26486 If any of you hate these behaviours so much, use another language for personal projects. If you're being paid to use Go, then either continue using Go to collect the paycheque, or find another job. In any event, I'm not sure what these screeds are intended to accomplish.

I’ve been in love with go ever since I started learning how to use it about 2 months ago. Still looking for a project to do tho. >>26486 if you’re this worked up over a programming language I suggest you 1. leave lainchan 2. use any other programming language that you think is superior to Go 3. seek professional help

Holly soykaf imagine being this this triggered by a programming language. >>26552 Look into Gio, it's interesting but still needs work.

>>26552 >>26490 >noooo you cant just criticize my pet language, programming is for developing fetishes on soykafty industry languages >I’ve been in love with go ever since I started learning how to use it about 2 months ago. >>26492 LOL

unused imports for side effects (and to boot: having a special syntax for this to bypass the pointless unused variable checks) are an admission that your language is intended to target retards look at this example: instead of calling a hypothetical image.Decode(src, listOfDecoders), you do: >import _ "image/png" >image.Decode(src) because the user is too gay and lazy to pass in the png decoder the irony is that this code is no more convenient than the sane alternate metashyt-free design. you STILL need to know that unused import is there. you STILL need to look up how to make image.Decode decode a PNG (except now it's less obvious because it relies on global state and you need to skim the full module documentation rather than merely the function you call [or if it was redesigned as an object, the object you invoke]) you STILL need to type the unused import. this "syntactic sugar" (+semantic nightmare) doesn't save you ANY amount of time. the entire init() soykaf is java tier braindamage and has all kinds of weird recursive behavior, just to support a tiny set of retard use cases the gopher official docs do indeed mention several times that they prefer the user experience to appear friendly to noobs when sane design is the other option, so they can have more "muh adoption". TL;DR go is an industry garbage language designed to onboard as many morons as possible to their swiss cheese ship.

>>26491 >You are not supposed to have unused variables/dependencies. </autism voice> this is not an argument, and the rest of your post weirdly restates some rationale that does not really provide any reasoning and is already addressed in the thread. >shadowing is error prone false. >and so your code could shadow your libraries' without any errors. it's unfathomable to figure out what point you are trying to make here.

>>26574 >>26575 Why are you here lmao. We know about the up- and downsides of the language we are using, you don't have to tell us. Can't argue with people like that >muh better programming language go and use it then, no one is stopping you

Here's the problem, kids, tunnel visioned gophers. We are discussing whether unused variable errors is a good feature. "But if the feature wasn't there, people could put unused variables in the code, and trigger my OCD" is not an argument, and does not address the question. It's like arguing that 1+1+666+1=669 is false because there is a 666 in there which is against your morals. You never actually get around to discussing the actual problem, because you think some tiny subgoal matters. The question is whether this is a net benefit for the language. Pro: -The odd unused variable will not be present in code, making the code slightly cleaner Con: -Unused variables have to be manually removed -I don't even care about some unused variable it literally makes no difference to a professional. I do not have aspergers syndrome that causes my brain to explode because someone wrote a meaningless word somewhere in the code [otherwise i would not make it past a single //] -Dogshit code will still be dogshit no matter how many linters and muh clean codeifiers you add to it -For writing some quick test, it's unnecessary and gets in the way (and you will need lots of these quick tests to memorize all the edge cases in Go, such as type T struct{}; var t T = interface{}{}) -For debugging code, it gets in the way -For running a piece of code while in the process of writing it, it gets in the way: e.g normal language: > 1. a,b,err := Thing.GetBlah() > 2. run code to make sure Thing.GetBlah() did what you want > 3. add Thang.BlahBlah(a,b) ...vs Go: > 1. _,_,err := Thing.GetBlah() > 2. run code to make sure Thing.GetBlah() did what you want > 3. type in names: a,b,err := Thing.GetBlah() > 4. add Thang.BlahBlah(a,b) -IDEs can auto remove soykaf for you but then you have to add the entire path to the import again. It becomes a game of heuristics to design the ideal IDE experience for this -It unnecessarily gets in the way of code generation, and Go has 10X more codegen than any other language -You ignored the final fiasco in Java which was concluded to be dumb and useless 20 years ago (by all but the most meatheaded b__mer programmers who cannot code for shyt yet still think highly of their opinion), and brought back the same braindamage to Go also: Obviously 10 problems is worse than 1 problem that was purported to be solved. >but i love goo! stop saying this. you are just admitting you cannot use a language without criticizing it because you are small brain who needs to join a clique brogrammer's club for the language you use. you will never be a man

>>26577 You literally have not even entered into argument with what I am talking about (how Go works), instead made a typical low IQ copout. >Can't argue with people like that Yes, because you do not want to critically think about your language because it's your clique and you sexually identify by it

>>26579 >you do not want to critically think about your language correct, I don't want to right now >because it's your clique and you sexually identify by it wrong, I just don't feel like arguing about it. idk who you are but if you are any of the people that write stuff like >>26486 then I refuse to have any kind of discussion with you. I know that Go isn't the best programming language. Go is the first "easy" language I've actually properly used, after being forced to use Java all the time in Uni and using C in my free time a lot. I've been getting into Rust at the same time as getting into Go. You are assuming that I'm using Go and only Go and I hate every other language because it's "too hard", which is not the case. A lot of the times I just feel like using a simple programming language. I don't want to use Python, Ruby, Lua, or any other kind of "scripting" (or leaning towards it) language so I'm using Go. People that feel hatred towards people that use a specific programming language are disgusting and can't be argued with. That's the point I was making before; there's no reason to talk to those people. Also, if you don't accept that no programming language is perfect and keep going on about "but this language has problem X so it being good for Y doesn't matter" then I won't argue with you either, because you're dead set on the programming language being trash. If that's the case, leave. I've had these kinds of discussions way too many times to care anymore.

>>26575 Wait, so you can literally have code like: a1.go: import _ "image/png" import _ "image/jpg" import _ "image/gif" a2.go: func init() { logo, str, err := image.Decode(r) } and it will break if you rename a1.go to a3.go

>https://golang.org/pkg/image/ >Values of the Image interface are created either by calling functions such as NewRGBA and NewPaletted, or by calling Decode on an io.Reader containing image data in a format such as GIF, JPEG or PNG. Decoding any particular image format requires the prior registration of a decoder function. Registration is typically automatic as a side effect of initializing that format's package so that, to decode a PNG image, it suffices to have > >import _ "image/png" > >in a program's main package. The _ means to import a package purely for its initialization side effects. >in a program's main package This literally will not work in the example I posted >>26583, as main would initialize _after_ the `a` package. >mfw the standard lib devs do not even understand their own "simple" language

>>26584 > ur gay and cancer and stfu bad etiquette. please go back to that other board, thank you. does anyone know why the Go thread is producing/attracting these kinds of rude and obnoxious posters? This seems to be unique to the Go language thread.

>>26588 >does anyone know why the Go thread is producing/attracting these kinds of rude and obnoxious posters? I'd love to know, too, but I'm guessing it's people that try and make the point that Go is bad because it's simple and non-elitists have something "better" to use than JavaScript, thus "tainting the image of the programmer". In actuality it's really nice that Go is this simple. It makes reading as well as writing code easier without sacrificing "power". Sure, you're more explicit in your code, but IMO it's worth the trade off if you're programming something you still want to easily understand a few years later.

>>26596 I don't think it's really unused if you're incrementing it, since that counts as a read and a write. Each write operation of the ++ operator affects each read operation of the subsequent iteration. A decent compiler could tell that `i` really serves no purpose in this case, but there could be more complicated cases where it could be theoretically impossible for a compiler to determine whether a variable really is useful, so all that is reasonable for the compiler to do is check whether the value is ever read, and assume that in that case it is "used".

>>26599 The phrase "pissing in an ocean of piss" comes to mind. Given the current state I have a hard time imagining how go code could make it worse. >>26601 >A decent compiler could tell that `i` really serves no purpose in this case I don't mind the compiler being a little dumb if it prevents "optimizations" from becoming "requirements". The worst thing is projects that set Werror so the build breaks in a million places every time you upgrade the compiler. If the rules can't be made simple enough for every current and future compiler to implement them, they shouldn't break the build.

>>26616 >The phrase "pissing in an ocean of piss" comes to mind. Given the current state I have a hard time imagining how go code could make it worse. Jesus fuarrrking christ, can people like you just knock it the fuarrrk off with this whiny soykafty attitude? If you don't like Go, don't fuarrrking use it, and kindly piss off to somewhere else instead of clogging up the thread with your petty assholeness. Every fuarrrking Go thread this happens. Every fuarrrking one. People like me who enjoy and are experienced with the language, and new users who want to learn it, are constantly bombarded with nonstop vindictive fact-free ignorant rants like yours. What the fuarrrk is your deal? So fuarrrking sick of this bullshit. So fuarrrking sick of people like you. You contribute nothing but complaints. I can name three other languages off the top of my head that I personally think are suitable only for braindamaged drunks, which have active ongoing threads. But do you see me barging into those threads like a bull in a china shop, loudly venting my derogatory opinion on the language in question, the code written in that language, and the people using that language? No. Because I'm not an asshole. I leave those threads alone and in peace despite my unending contempt for the languages in question. I invite you to do the same.

>>26617 JFC chill out buddy. I was actually speaking in defense of go to the guy whining about "polluting the software industry" as though it were some pristine work of beauty and not the wasteland of barely functional 200MB javashit frameworks piled on top of buggy legacy soykaf. I actually like go and use it when I have a choice. Much nicer than java or python. You've certainly convinced me the typical go programmer is a barely literate zealot who can't be reasoned with. Good to know.

>>26617 It's too fun to mock Go. It hits a sweet spot: popular but awful. Google is funding the development of a language worse than an early version of Java. It's ridiculous. People who use it are ridiculous. Fun fun fun.

I’m working on writing a package that implements a standard for image compression, which will hopefully be useful for people who scan books and make PDFs.

>>26624 >>26625 Yeah, I'm done with /lambda/. Nothing but self-admitted trolls everywhere. fuarrrk it all.

>>26635 A common theme with "programming" or "technology" boards from my observations is that there's always a sum of users who thoroughly enjoy arguing with other users over why $X language is terrible and $Y is better because of $Z. These "discussions" usually tend to overshadow any actual discussion worth anyone's time.

>>26635 /g/ is still worse, people pretend to be experts, talk soykaf about other open source projects or whatever without actually contributing anything

>>26625 I think the fun in mockery has little to do with the actual quality of the language and more to do with the corporate approved Community™️ which invariably surrounds languages with big corporate investment. >>26635 Lord forbid someone troll you on an anonymous image board.

>>26490 >>26492 >>26552 >>26561 >>26577 >>26588 >>26617 >>26635 >>26658 >>26663 Stop whining. The person really does offer more insight than you do and it's interesting to me and most likely other people too. On the other hand, your opinions about how someone can't hate a programming language are completely uninteresting, valueless, and contribute nothing to the discussion. Next time you see an argument against something you like, consider either making a counterargument or changing your mind.

>>26595 to be honest I really don't understand why the Go threads have so many angry and rude posters. I understand less why people feel the need to act like preffering or deffering one language over another somehow makes them morally superior to someone else? I like APL but I don't see APL threads full of "APL-tards" and "APL-trolls" like the Go threads consistently are. I don't prefer C but I still go to the C thread to learn C, and I respect the programmers enthusiatic about it, or who also want to learn about it for whatever reason. There really is no sense in being so rude and argumentative over something like programming languages, especially not on a board like lainchan. Can't we all be nice to each other and love lain?

>>26668 > lord forbid trolling on an anonymous image board You're on the wrong image board anon. Different boards have different etiquette. lainchan is not four chan, it's a lot closer to sushichan or early two chan in culture to be honest. If you want to be a nuisance then I would recommend going to an image-board where that behaviour is encouraged. The 'rules' are clear: elaborate your opinions, have fun, and don't spill the soykaf.

>>26658 >there's always a sum of users who thoroughly enjoy arguing with other users over why $X language is terrible and $Y is better because of $Z. That's true and I despise this. These usually get nowhere because both parties think their programming language is superior to the one the other party is using. When this isn't the case these discussion can be very productive, though! >>26668 >I think the fun in mockery has little to do with the actual quality of the language and more to do with the corporate approved Community™️ which invariably surrounds languages with big corporate investment. I see this a lot but I just don't get it. You use the language and interact with it daily, not with the community, right? What do I care that a language has a community full of people with *generic insult* or if it's backed by a big company? If the language is nice I'm going to use it. Caring about the company/community behind it more than the language itself is dismissing the language as something that's not the primary interest on a board about programming. If you care about the community so much then that's fine, but don't make it an argument for the programming language people are using; it doesn't change any properties about it. >Lord forbid someone troll you on an anonymous image board. As >>26685 said, this is lainchan. It's bad etiquette here to start trolling. The rules say: >You should always elaborate on your opinions rather than just spilling the soykaf. so most get deleted anyway. If you feel like trolling I suggest you go somewhere else. I hear 4chan is a safehaven for those. >>26669 >The person really does offer more insight than you do Have you actually read >>26486? I'm pretty sure this is the kind of post we all mean here. No one is against a civil discussion about a programming language. What we are against is people coming here, spilling the soykaf, and treating every counter argument, supporting the language or not, as coming from someone obsessed with that programming language. If you're not trying to have a proper discussion and just try to talk down on people then you are not welcome here. >>26684 >I really don't understand why the Go threads have so many angry and rude posters. Me neither. >and I respect the programmers enthusiatic about it Thank you for this. This is undervalued nowadays. I try my best to do the same. Mostly I get attacked for being a "fuarrrking *language X* enthusiast", tho. >There really is no sense in being so rude and argumentative over something like programming languages I avoid confrontation whenever possible, but I do have to say I overreacted a bit with >>26581, assuming things I shouldn't and being overly aggressive. Lainchan is a place I've been on for a few years, I just don't want to see it declining in quality posts. >Can't we all be nice to each other and love lain? Please, let us! This is one of the reasons I joined lainchan, I want to keep it this way.

>>26694 >>26685 Go programmers can cry "troll" all they want, but complaints about Go are well founded, articulate, and cutting. The Go programmers in this thread are not discussing Go. The Go programmers in this thread are not refuting the "trolls'" arguments. The Go programmers are crying that several people have the audacity to call a spade a spade. Go is trash. Even if Go wasn't a Google language, it would still be trash. Even if Google didn't tell that guy who already created a language named 'Go!' to fuarrrk off, Go would still be trash. Even if Go wasn't designed to make programmers fungible cogs at Google, as Google readily admits, it would still be trash. No generics, awful error handling, and an autistic compiler does not make a good language. Every improvement is some insignificant syntax quirk: just 'for' instead of a 'while' keyword; better type signatures; you can start threads with a keyword instead of a function. "Where's the set data structure? Can I write one?" "No, you can't really. Just use a dictionary and check for membership." Astounding.

>>26694 I hope you realize that what you're doing is as bad as any brewing soykaf that occurs on 4chan: it's irrelevant, off-topic, and doesn't address any argument or substance. Yours is merely garrulous and specious. Also, sage when your post isn't pertinent to the thread's topic. Jesus Christ, this is imageboard protocol 101.

>>26694 I totally agree with you but I think part of the problem is that there’s not much to actually talk about with Go. It’s a boring language, after all, but we like that. I think more substantial Go discussion might come about in the context of specific applications, like web programming, image processing and generation, etc. Like has anyone implemented Sauvola’s or Wolf’s threshold algorithm in Go? And anyone have any tips or packages for working with matrices? I guess if there’s some general Go stuff on my mind, it’s that I’m suspicious that they’d like to make go.dev the new homepage.

Generics are coming! >Generics enabled by default in Go tip https://go-review.googlesource.com/c/go/+/343732/ We already have some packages coming with this features too. >maps https://github.com/golang/go/discussions/47330 >sets https://github.com/golang/go/discussions/47331 >slices https://github.com/golang/go/discussions/47203 I'm really excited to this addition. It will make code conciser as we won't need to implement this type of functions ourselves anymore.

>>27227 Will this make Go as cumbersome as Rust?

Was there any new based criticism og generics in GO?

>>27242 As far as I know there was an DSL that showed some flaws on the current type system implementation. It's fixed now. https://groups.google.com/g/golang-nuts/c/81MlWAgkXd8/m/b0JC2l70BwAJ >>27240 I feel most people will write code without abusing it however libraries might start to get a bit more complex with this change. Nonetheless, I'm really excited for the packages shown here >>27227!

Lainfrens which book about Go would you recommend?

I have hard time believing that GO is not on a path to feature creep like C++ been for well over a decade now

>>30198 The Go Programming Language by Kernighan

>>30200 I some anon saying that is too terse and outdated. I'll probably read it someday just cause Kernighan wrote it but would you recommend it over something newer like "Learning Go" by Jon Bodner?

>>30201 I read it when it came out and didn't seem too terse, and I haven't read any other Go programming book. I think it has a Go programming style for go. Go hasn't changed much in years and it's very small, so I find it strange that someone would say that it is terse or outdated. Some of the tooling instructions in the book may be a little outdated since the ecosystem of the language has evolved, it uses GOPATH instead of go modules, but it doesn't really delve much into that stuff and mainly focuses on the core of the language which hasn't really changed much.

>>30202 I'll go with "The Go Programming Language" then I guess, thanks for the advice.

>>24694 what the lziteral fukkc doeis fiunction overloadiong hoave too doo with genaerics we lainspeak now. we live in a dystopian world where retarded admins keep adding new secret filters

Am I wrong to not see the appeal of Go? I mostly work with .Net (which seems to be even faster than Go for anything other than Goroutines), and to be honest if the biggest wage slave of Go is concurrency I'd rather learn Elixir. Redpill me on this soykaf.

>>30219 Go's kind of like the anti-Java. They're similar in that were both originally envisioned as replacements for the higher-level subset of C++, and both of them are designed to impose discipline on large teams of mediocre programmers. Where they differ is in how they achieve these goals. Go enforces idiomatic coding practices by making them the only option. The designers are very picky about which features they put in, and spend a lot of time deliberating over how they're going to implement new features (like generics) so they don't cause problems further down the line. They also make things that would traditionally be left up to a linter mandatory parts of the language. It'll reject code with unused declarations, and forces you to format your code a certain way. It makes for a very clean, very practical, but not particularly interesting language.

>>30219 Besides the language itself, Go's standard tooling has some advantages. For example, if you need to cross-compile to a stand-alone binary with no runtime dependencies, it's very hard to beat Go. But as far as only the language is concerned, I think anyone who's willing to pick up Elixir should choose it over Go. I'm not dissing Go - it's in fact a surprisingly good language for a hobbyist to learn, especially considering that it was designed for nothing of the sort. But, as the other lain says, its benefits are practical: it's very quick to learn (for a typical imperative programmer) and makes it easy to build concurrent stuff. Neither of those is a deal breaker in the case where Elixir is an option, so, yeah.

I'll soon start writing a web service with it's backend written in Go, and I'm looking for a nice ORM and Query Builder. I'm coming from Rust, which has Diesel, and I'm looking for something that is at least comparable to it. Can anyone recommend a good library? Or a good place to read up on them? I'm not familiar at all with database interaction in Go.

>>30361 I think gorm is the most popular ORM for Go at the moment.

>>30362 >I think gorm is the most popular ORM for Go at the moment. Just had a look, seems like it would be exactly what I'm looking for. Cheers!

why is println some deprecated half working thing when the entire reason i would ever use go is to add a println to see if the codebase im hacking does what i think it does in some certain scenario?

I just joined a shop that said they use a mix of python and Go during interviews. Now that I'm here it is 90% python, and there is a sprinkling of programs in Go. Of course, the senior level devs have no desire to create or migrate anything to Go. I think I'm gonna be sick :(

>why does no wh*teoid programmer understand the semantic problems with exceptions and why does [[[Go]]] manage to fwuuuuuark it up even more than java-tier languages? is this because they're lazy fuarrrks and just want to have some generic half working code handle the errors for them? is this also a result of cognitive dissonance they are met with when they realize how much fundamental changes they would need to do to actually handle errors (i.e, various return values of a function) properly?

>>31335 Not entirely on topic, but I find it sad that cobbled together pseudo-collages have replaced actual original art for things like this.

>>31350 That's not what I said though? You could've drawn stick figures in mtPaint using your feet while fisting yourself for all I care. I just want a bit of variety is all. And I don't even want it that badly. You act like my one-sentence off-the-cuff post was a public freakout

Can someone with a bit more experience (with Go or just programming in general) give me an opinion on this [1] ? I'm a very green hobby programmer who's been working mostly in Scheme after following SICP; I've got a buddy who's also wanting to get into programming, and I suggested SICP to him, but he told me he wants to learn golang because he's been told it's easier to get in to. I asked him who told him, and he said a friend who works in go sent him this link. I can tell it's over his head, because I don't really understand the implications here, and I'm certain I know more than he does. Is there a deeper meaning here, is golang really a good ideal first language, or is golang just a simpler syntax like python and such? [1] https://medium.com/@brianwill/q-what-programming-language-should-i-learn-first-a-go-e1105934266d

>>31358 golang's great at its niche, i.e. highly concurrent server-oriented programs, but i'd never recommend it over python to a beginner

>>31358 You might be overly cautious here - that post isn't as well informed as you seem to believe. It contains a few small inaccuracies and blanket statements. First, and most importantly for you: does your friend want to learn to program, or does he want to learn a programming language? As a programmer, you will typically learn a variety of languages, with varying degrees of skill transferability between them. The general principles of programming that a work like SICP teaches apply to any language. The bottom line for me is that Go is indeed easy to learn and very practical, and I do believe, unlike the previous lain, that it is a fine language for a beginner. However, none of this contradicts your advice, as you can only ever be better off by learning a language from a different paradigm and reading a good general course on programming. And as for the document in question, let us consider its arguments against dynamic languages such as Scheme or the other lain's suggestion, Python: >Go is simpler Than any of the quoted languages, no doubt - but Scheme is still several times simpler. Lua is simple too, and fast. >it runs better From context, I understand he means 'faster'. Mostly true - not that a newbie should be concerned with this. >its tool chain is simpler Than what? I learned to program with Python and mostly use Ruby these days. I've never used a tool other than my interpreter and irb, Ruby's documentation browser. Surely there are good use cases for static analysers or project managers, but they're neither part of the required tooling nor something a newbie should be concerned with. >it gives you static type checking And a weak one at that, as >>31335 elaborates on. When I write in ML, the type checker catches flaws in my logic. When I wrote in Go, the type checker prevented numbers of one kind from being mistakenly decoded as numbers of a different kind - something that can't happen in a dynamic language anyway.

>>31358 >I suggested SICP to him Little Schemer or Simply Scheme (https://people.eecs.berkeley.edu/~bh/ss-toc2.html) would be better at first. I guess Teach Yourself Scheme in Fixnum Days (https://ds26gte.github.io/tyscheme/) would be a decent alternative as well. >he's been told go easier to get in to than Scheme. That's total BS. Scheme (and Ruby/Python/Lua/Perl...) is objectively easier than Go, and there is a lot of less stuff you need to learn if you learn Scheme. Tell him that he really should learn Scheme for pedagogical reasons, since you can focus on the programming concepts instead of syntax and other minute details of the language. But if he wants to get a language that has a large community, large standard library and that's also easy to learn, he should learn Ruby and not Go or Python. Python and Ruby are just as easy to learn but Python uses a syntax that's based on the whitespace (indentation level), while Ruby uses more sane syntax. Python also does OOP in a bad way. Go is harder than Scheme, Python, Ruby or Lua, Perl, etc. but Go is easier than Java/C# (go is only slightly easier), Rust (go is definitely easier) or C/C++ (go is definitely easier). > is golang really a good ideal first language, No, a good first language would be something like Scheme or Lua or Ruby. Go is a good second language. >, or is golang just a simpler syntax like python and such? No, absolutely not. Lisps use the exact same syntax for everything (except the special forms).

>>31371 >That's total BS. Scheme (and Ruby/Python/Lua/Perl...) is objectively easier than Go, and there is a lot of less stuff you need to learn if you learn Scheme Agree, people probably mean that Go is simple as a second PL coming from C or Pythong. I really think people should consider learning the simplest (not R5RS simple, though) form of ML (SML, not Haskell nor OCaml) and Lisp (Scheme or CL if you ignore CLOS at first; yes I know it's bigger but still simple and simply more useful if you want to go further). Avoid "multi-paradigm" garbage heaps like C++, Java, Rust, C#, etc... like the plague. https://madhadron.com/programming/seven_ur_languages.html has some interesting ideas about this; I've found that people who never ventured outside their ur-language (C++/Java/C# corporate drones, Lisp/ML/Python ivory tower academics who don't know the cost of their cool abstractions, etc...) are usually not very good programmers. But the reality is that all good programmers started with C (or Pascal, or Fortran, etc...), because: * It is still the lingua franca of the computing world. * You might need its performances sometimes. * No other PL will force you to become as rigorous as the UB-ridden implementation-defined multiple-fighting-standards (C ISO spec, POSIX/win32, compiler/libc extensions, MSVC incompatibilities, etc...) manual-memory-management mess that is C. * You'll never learn to appreciate the features of more advanced PLs until you had to mess with the retarded preprocessor (or m4, if you're smart) to get generic data structures without void*. * Having to write your hash tables, ring buffers, linked lists, etc... is good for beginners. * Static typing is better for beginners, until you develop the aforementioned rigour to go dynamic.

>>25115 I mean when you think about it, gateways beget gatekeepers, nay?

Can any lainon explain why answer seemingly appends the same slice twice?

>>31371 >>31358 Arguably the Python ecosystem is a mammoth (bigger than elephant) in the room, so unfortunatelly you'll have to make him dip toe on Python at the very least. You could, however, wage slave it Rails as a way to get inmediate results if he is remotely interesed on that. Rails make web bearable for the most part, and is more concise than Django.

>>31605 Arrays and slices are different. An array is a sequence of N objects in memory. Notice the length is part of the type. Thus, copying an array copies its objects. On the other hand, a slice is a fat pointer. It points to an array and tracks the length dynamically. Copying a slice copies the pointer and the length. Your hashset maps arrays to booleans. So, the for-range loop copies the arrays into k. Next, you slice k (i.e., obtain a fat pointer to k) when you append answer. But the values stored in k are modified the next iteration of the loop. That’s why all the values appear to be the same. Consider the behavior of this program: func main() { a := [1]int{0} b := a b[0] = 1 // Prints 0. fmt.Println(a) c := a[:] d := c d[0] = 1 // Prints 1. fmt.Println(c) }

>>31777 Golang thread is really dead huh. Anyway, thanks for the answer! I saw your answer way earlier but forgot to reply.

wtf i just came in this thread to mock go by pretending to be rob bike and saying >go is designed very meticulously in a way where we pick a philosophy and adhere to it no matter what even in the face of the obvious wrong choices it creates but then saw this: >>31605 holy hell this is the most braindamaged thing i've seen in go yet. and i've seen some soykaf. like holy hell, why would you _ever_ consider reusing a slice in this situation in a core language primitive. guaranteed almost no gophers even know about this edge case, just like how slices are not atomic (and can lead to actual RCE under concurrency). this is a retard design choice like how in coffeescript you can refer to temporary variables it makes because its compiler is a regex

C programmer coming to go here. Why don't people write functions like this? func f(a[] int) This feels like the right way to do it, why do people do it the other way: func f(a []int)

Go is a good language for simple scripts, I'm building a TUI with this awesome framework (https://github.com/charmbracelet/bubbletea). Charmbracelet also has a lot of nifty shell tools written in Go

>>32908 wait i didnt even understand it yesterday, i thought it k would become a temporary slice, but it becomes a temporary array, wtf? why wouldnt they just make it a slice or pointer to array? instead: >its a dynamically allocated array, and for each key in the map, the contents are copied over it what the actual fuarrrk is that???

2/? the fact that after 10 years of randomly making excursions into go i still find deeply hidden edge cases, tells how much a crap language this is. this is almost as bad design as C or PHP, in a language 1/10th the size. #aidsniggerPL

>>32929 its because pointer to array is too hard to explain! go is simple! yeah sure its twice as hard to explain the resultant edge case but whatevs

Probably not the right place to ask, but is there anything Go does worse than Java? I know the recent generic in Go has runtime cost so that's one. What else?

>>32971 I wonder about general performance compared to OpenJDK and Graal. Including the GC side, as Go always brags about its low pause times, but I haven't seen a comparison with Shenandoah.

>>31605 https://github.com/golang/go/discussions/56010 I think it wasn't intended.

>>32971 they somehow have more misconceptions about how to handle errors than all other languages that have exceptions. see >>31335 but go is basically the exact same thing as java 1.3 or so. theres not really any benefit of one over the other

why does go run urmom.go freeze for up to an hour every time (actually, it will often sit there doing nothing for minutes before downloading some dependency)? is it masturbating while it tries to lookup dependencies? perhaps the site is throttling me but thats also fuarrrking retarded when the main workflow consists of downloading a fuarrrkton of dependencies every time you want to test something.

>>24685 There are plans to add "transparent telemetry" to Go that Opt-Out/enabled by default: >https://research.swtch.com/telemetry >https://go.dev/s/telemetry-discussion || https://github.com/golang/go/discussions/58409 Running go get (kind of) sends telemetry to Google already in current year : https://sourcehut.org/blog/2023-01-09-gomodulemirror/ >"For example, most Go users are unaware that every package they fetch is accompanied by a request to Google’s servers"

>>>/sec/21024 In addition to these resources, has anyone read a book on modern Go that covers modules and generics (and ofc goroutines)? The Go Programming Language is outdated because it doesn't cover generics (idk about modules). I was looking at Learning Go by Jon Bodner, but has anybody actually read it? I'm new to Golang. >>34280 A little update. >"By far the most common suggestion was to make the system opt-in (default off) instead of opt-out (default on). I have revised the design to do that." >https://research.swtch.com/telemetry-opt-in I'm glad they realized that collecting data without consent is spying.

>>33070 Saying that Go is basically the same thing as Java 1.3 is like saying that Objective C is basically the same thing as C++. They do similar things and have some shared influences, but the specifics are different enough that "basically the same thing" isn't really a fair assessment.

The state of go. rsc's comment link: https://github.com/golang/go/discussions/58409#discussioncomment-4936637 Top level comment: https://github.com/golang/go/discussions/58409#discussioncomment-4906459 >>34491 > I'm glad they realized that collecting data without consent is spying. Don't commemorate too soon.

>>33070 Go's crackhead error handling is a result of contrarianism on the language designers, as are many of its other strange design choices. They refused to add traditional exceptions into the language to stick it to The Man, but they still needed some kind error handling, so they opted for this weird thing that's a lot like exceptions but stupider.

>>34785 It's basically a Result monad without the monad. It's far better than exceptions, but worse than a monadic approach. Somewhere in a limbo between soykaf and good.

>>32971 Thanks to its Streams API, Java is much better at expressing things that can be autovectorized. Go shuns map/filter/reduce in favour of for loops, which makes it very difficult for the compiler to know when to generate SIMD code. Java has better garbage collectors (ZGC and Shenandoah). Go also does not have the concept of thread-local storage or `ScopedValue`. You need to pass stuff like trace IDs and other ancillary metadata through a non-type-safe `context.Context` value, which kinda colours your functions (those with ctx as the first param and those without). Lastly, Java has a variety of dependency injection frameworks and a common API for them. Go has Fx and samber/do. Neither of these are pleasant to work with.

>>30361 Check out ent, an ORM by Facebook https://entgo.io/ There's also a database schema declaration and migration framework written by the same team: https://atlasgo.io/

I've heard Go has very weird error handling. I've seen it compared to both C-style error codes and Haskell style error monads. What I want to know is how it compares to both, because they're very different solutions to the same problem.

I've been messing around with Go a bit, implementing algorithms and writing toy programs. My general impression of the language is that it's a compiled, statically typed version of scripting languages like Python and Ruby; Opinionated, a bit quirky, and elegant to a fault, but not quite to the point where it becomes obtrusive as in PHP or Javascrpt. It's nice to have a general-purpose high-level programming language that's small, simple, portable, and performant, while also letting me do more advanced functional stuff with closures. It does the sort of thing Java tried to do way more sensibly than Java ever did, and I'm honestly surprised something like it wasn't invented way earlier. That said, I find Go's syntax and semantics un-ergonomic in a way that I can't quite explain. There's this subtle disconnect between what I want my code to do and what I actually have to write out in order to make it happen, and when I look at others code, the meaning doesn't immediately 'click' for me the way it does in something like C. It's never to the point where it outright bothers me per-say, but there's definitely some friction there. The way you're supposed to handle errors is probably the most obvious example. I won't deny that having errors as secondary return values doesn't have its perks, but it makes idiomatic error handling look weird written out, in a way that will never not look weird no matter how many times I look at it. Overall, I like Go well enough. It does a lot of little things that I disagree with, but the broad-strokes language does what it sets out to decently well.

Is there a way to handle errors in Go without assigning to a variable? I'm relatively new to the language, so sorry if this is an obvious question.

>>38470 I know what you mean with the un-ergonomic syntax. That alongside the philosophy behind that language is why I dropped it pretty early on. It is fairly verbose without adding information or context. The error handling seems to be a strange concoction to allow exception-style error passing without implementing the automatic stack unwinding. It doesn't really feel pleasant to use. Especially since its just a tuple return and deconstruction, pattern matching over the type (or even better, variant types as >>31335 mentions) would be much more reasonable in my view. But there is only so much you can do with a language whose intention is "easy to understand and easy to adopt" ergonomics wise.

>>37831 It's not very complicated, you just return two values, one is your return value and another is an optional return value that has an error code like C If you want to ignore the error you can but usually you shouldn't Easiest way to imagine it is that every function is returning a struct like {ReturnValue, Error} where error can be nil if there wasn't an issue It's way less complicated than exceptions

I'm just getting into Go, and something that struck me is just how un-C a lot of it feels, despite that being that language people seem to compare it to the most. It honestly reminds me a lot of the 70s/80s languages that C and its ilk "beat", particularly Pascal and BASIC, with bits and pieces that bring to mind Lisp. Replace the curly braces with BEGIN and END , and you'd basically have a Wirth language.

It's too bad Go executes so much slower than C. Otherwise I'd be a lot more interested in it. And I wonder why that is?

>>40469 >so much slower How much slower? Generally Go is faster than all other mainstream GC languages, sitting between C and Java. Between Go and C there is Swift, maybe Julia and a bunch of "alt" languages like D, Nim and Odin - but chances are if Go really is too slow for what you're trying to do then you have no other choice but to use C, C++ or Rust (there's also Zig, I guess).

>>40470 >How much slower? I found a couple of tests people have run. I can't vouch for the accuracy. According to this, GCC is about twice as fast as Go for heavy number crunching: https://github.com/niklas-heer/speed-comparison According to this, Go is only about 17% slower than GCC for more general purpose stuff: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html So I guess you're right. It depends entirely on what the intended purpose is.

>>40469 What domain are you working in? The vast majority don't require C/C++ performance. You can just write the performant bits of code in C/C++ and call them as a library.

>>40516 I'm not saying >>40469 is like this, but in my experience as a C programmer, a lot of my fellow C programmers, especially ones who work on (soft) real-time software like video games, vastly overestimate how much performance you need for a typical application. That's not to say that performance doesn't matter, it always does, but for the vast majority of applications, the overhead of things like garbage collection and bounds checking are more than worth it for the increases they bring in programmer productivity.

>>40542 Time is a flat circle, after all. This has always been the root argument for GCs in languages. As a former C programmer myself (I have little use for it anymore, and I've moved onto Haskell and the like), I know this mindset all too well. It doesn't help though that higher level languages such as Java/#/JavaScript/Go all bring forward programmers who seem to believe that performance is free and its just "up to the compiler". You can make a responsive, efficient program in any of those languages, most just don't. Same can be said for FP languages, but the set of problems is different in my experience.

>>40551 >It doesn't help though that higher level languages such as Java/#/JavaScript/Go all bring forward programmers who seem to believe that performance is free and its just "up to the compiler". I feel like a lot of it also comes from the inverse phenomenon, where people interested in writing performant code avoid high-level languages because they like seeing low numbers in a profiler. I say this because it's something I myself am guilty of. I've started multiple projects in C that I really ought to have done in something like Go or Java. You can get high-level, garbage collected languages running very fast, especially if they're compiled like OCaml or, again, Go. It just seems as if very few people are actually interested in doing that.

>>40565 I really wish more people would pick up OCaml. It is probably the most pleasant language I have ever used, and it's pretty damn fast as you've said. Not to mention that OCaml is mostly predictable in terms of performance and memory consumption, something that Haskell and the high-level OOP languages are not. It makes for a very low friction programming experience, with all the convenience of a strong type system, garbage collector, and functional programming. I am just tired of the endless comparisons to C/C++ for performance benchmarks. You can compile C down to oblivion, and can just write your own hand rolled assembly wrapped into C functions if need be. Go is plenty fast, OCaml is plenty fast, etc. Artificial benchmarks showing the dominance of a well optimized C/C++ program is the same as showing me that a F1 car is faster than a sedan. I already knew that, I didn't pick the sedan because it's the fastest car around.

>>40586 >I really wish more people would pick up OCaml. to be honest I've started using Haskell in the past 2 weeks, but im keeping an eye on OCaml cause yeah, it looks like a fun programming language to learn -- but at the same time I much prefer Haskell syntax somehow; im kinda conflicted if I should keep learning Haskell or just switch to OCaml

>>40629 Haskell certainly wins out overall on the syntax side of things (except for module declarations). I do think OCaml reads better as complexity is introduced however (module prefixes are standard, can just read top down like a page in a book, .mli files save you reading library code, etc), but your experience may differ. The real reason I recommend OCaml over Haskell overall is because of design paralysis I face in Haskell. It provides you with an entire tool shed of options, with all them overlapping in their solution spaces. You could write an entire monadic logic system to add two numbers together, if you wanted. I find myself reading more than anything else when designing a solution in Haskell. Not to mention that since the language is far more dogmatic, mandating purity by default, you're forced to design more than solve. A better programmer than I would feel at home here I'm sure, but I get paralyzed. By contrast, OCaml feels more focused on providing less tools that are more immediately usable. The bulk of your code will be functional, most likely, but procedural logic exists if it makes something easier. It has an advanced module system for modular programming; And if you need message passing and inheritance it has an entire object system bolted on. Not to mention that purity is optional, but still the default. I very much enjoy OCaml and Haskell both. I really think it just depends on how productive you want to be (or perhaps you're just more capable a programmer than I), and what gives you more joy of course.