This is great, but I think it should be written in Rust.
It will then run way faster and be completely bug free.
Learn Go: Hand-crafted Go exercises and examples
31–40 of 68 posts
Re: Learn Go: Hand-crafted Go exercises and examples
#32This doesn't ask the most important question: why would I learn Go at all?
In case the question isn't facetious:
Go's main advantage, IMO, is that is both simple and opinionated to the extreme. It's a language that makes a lot of choices for you (from "no while loop" through "no exceptions" to where the brackets go formatting the file). Those choices might be the best choice or not, but the point is that they're already made and they're enforced.
The result is that in a big company, all projects made in go are very similar to each other in a lot of ways (much more than the average language) and so it is as easy as possible to have people contributing in each other's projects or moving between teams. There's no arcane syntax, no discussion about linters, nothing like that.
It's basically an amazing language to make programmers interchangeable. Whether that's good or not is a different discussion, but at the very least it looks that it's gonna make it very attractive for employers and so be a highly demanded skill in the near future.
Re: Learn Go: Hand-crafted Go exercises and examples
#33Earlier quoted context omitted.
To answer the question: what would a language look like if you put it's designers in a time capsule for 20+ years and had them make a language that was uninformed by all the language advances and learnings they'd missed out on.
This doesn’t answer the question at all. Also it’s very disingenuous. The designers of Go were very much aware of the the last 20 years of language development. They decided on a subset that catered to software engineering between teams of people spanning a length of time. It purposefully leaves out lots of features and cutting edge design philosophies because many Of those make things difficult when sharing code bet…
This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head:
Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect.
Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers for that matter), or creating constructs that make them much safer (such as what typescript is doing). Instead go doubles down on both of these. In the last decade of programming in kernel level c, python, ruby, c++, java, typescript, scala I've never worked with code that crashes so much and is as buggy as go.
Both of these problems could have been addressed fairly easily without bloating the language. Google has people on the c++ committee; it very much feels like the creators of go had too much hubris to walk down the hall or across the campus and kindly ask a good language designer to shoot holes in their design.
Another example is "iota". How does that make code sharing easy at scale? Any time I see iota, I have to start manually counting lines, and remember the rules for if blank lines or comments bump the counter, and it completely circumvents the ability to quickly grep for a value seen in a log message. It is completely antithetical to teams of people and spans of time and whatnot. It seems more like a team of three people who randomly had ideas and ran with them without thinking the consequences through very well, or consulting the wisdom of others.
Re: Learn Go: Hand-crafted Go exercises and examples
#34Observation: I see that you do 26 exercises before doing anything with pointers. I often wonder if one of the reasons Go is more "simple" or approachable to some is because you can, to a large extent, ignore pointers and interfaces and "just write that weird little * or & in some places" and get away with it. Whereas, I believe in other languages, this is much less possible (e.g. in Java or Rust you need to learn abo…
So true. When I first stated writing Go I would always try and * or &
Re: Learn Go: Hand-crafted Go exercises and examples
#35Earlier quoted context omitted.
That is really interesting to me! I never used VB, is the only difference here that it is "named" ByVal and ByRef that you think made it easier for people to understand than "pointers"?
Well, I use those terms (ByVal/Ref) and then say, one is a copy (byVal) and the other is a reference (pointer to you and me) to the thing. So, pass small things ByVal (int, float), it's on the Stack. Pass big things (Object) ByRef cause they're in the Heap. Then I start saying pointer more than ByRef and the link is made. Then on to ByRef/Pointer to how that then manipulate the shared data. Once that basic is done, w…
I'm not sure I've seen this explained so well in so few words. Thanks!
Re: Learn Go: Hand-crafted Go exercises and examples
#36Observation: I see that you do 26 exercises before doing anything with pointers. I often wonder if one of the reasons Go is more "simple" or approachable to some is because you can, to a large extent, ignore pointers and interfaces and "just write that weird little * or & in some places" and get away with it. Whereas, I believe in other languages, this is much less possible (e.g. in Java or Rust you need to learn abo…
Your can't really do anything real without pointers in Go though because you won't be able to mutate states out of a function.
Yes you can, lots of functional languages work without mutation. I'd go as far as to say mutating should be the exception, not the default, in more traditional languages.
Re: Learn Go: Hand-crafted Go exercises and examples
#37Earlier quoted context omitted.
I was wondering the same thing, and it's sad to see this question downvoted. HN discussion quality is turning into Reddit.
It’s downvoted because it’s being facetious. If you actually want to learn about what Go programming is like or used for, go to the Go website and try the tour.
And I could go to the official documentation to learn the language too. Your post doesn’t help. I can’t imagine being so miserable in life that I’d assume the worst and label people facetious. Good luck with life
Re: Learn Go: Hand-crafted Go exercises and examples
#38If you're interested in interactive language learning exercises, then try codewars(https://www.codewars.com)
Re: Learn Go: Hand-crafted Go exercises and examples
#39This doesn't ask the most important question: why would I learn Go at all?
In case the question isn't facetious: Go's main advantage, IMO, is that is both simple and opinionated to the extreme. It's a language that makes a lot of choices for you (from "no while loop" through "no exceptions" to where the brackets go formatting the file). Those choices might be the best choice or not, but the point is that they're already made and they're enforced. The result is that in a big company, all pro…
This is very weak argument. Once these restrictions are embedded in language, it cannot be removed by anyone. On the other hand, same thing can be accomplished by using company-wise style enforcers. If you think that is harder, I'd say forcing every project in big company to use same language is even more harder.
My main quip with Go is that its rather more of the same but more poorly done in the name of minimalism. Extreme minimalism is as bad as extreme richness. The entire art of language design is achieving just the right balance for a specific audience and set of goals.
Re: Learn Go: Hand-crafted Go exercises and examples
#40Earlier quoted context omitted.
This doesn’t answer the question at all. Also it’s very disingenuous. The designers of Go were very much aware of the the last 20 years of language development. They decided on a subset that catered to software engineering between teams of people spanning a length of time. It purposefully leaves out lots of features and cutting edge design philosophies because many Of those make things difficult when sharing code bet…
This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head: Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect. Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers fo…
I'd read some post where Go designers boasted about how they simplified compiler code by cutting down a language feature. It seemed to me they were obsessed about keeping compiler simple which resulted in half-assed language that was then re-casted as achievement in minimalism. I've felt that Go is optimized for compiler designers as opposed to actual developers.