Please have commit messages more informative than "update $filename"
Please try to contribute something actually relevant to the post.
Show HN: My notes on Working with Go
31–40 of 91 posts
Re: Show HN: My notes on Working with Go
#32It's just code with comments what code is doing. Can we call them notes?
Go is very readable. It seems I can understand what he's doing / means, even with Chinese comments!
My first click was the link for "Accessing a value of an unexported identifier". Figured I'd see some reflection trick or similar. In looking at that code I still have no idea what it's doing in relation to accessing an unexported identifier.
So I went to the next link down, "Unexported fields from an exported struct". Figured this would be the clever way to access the "message" field. But again I don't get it. It seems it's the same code as the last example.
This either says something about my ability to understand Go code or that maybe a bit more exposition would be useful for at least some of the examples.
Re: Show HN: My notes on Working with Go
#33Earlier quoted context omitted.
While I am no fan of Go, Rust is not a better alternative for most use cases of the average Go program. A better alternative would more likely be Java/Kotlin/Scala/C#. All with proper generics, good standard libraries/ecosystems, and fast run times.
What if you need to compile to native? Some places don't accept having to have a VM like .NET or Java installed to run.
.Net Core compiles to native and can be packaged to not need common runtime installed. And targets linux. You can even have it create a single file executable though admittedly it unpacks to temp folder at runtime if you do this. Down side is everything is like 80 MB minimum if you do this.
Re: Show HN: My notes on Working with Go
#34Thank you. I am just beginning to learn Go. This will be very useful to me. If anyone knows similar notes for Python & C#, please reply.
What make you keep learning Go once you've tasted C# delights?
Re: Show HN: My notes on Working with Go
#35Warning: opinions inbound I clicked one part (enums) and noticed a pretty glaring issue. The way you are doing enums is really _not_ conventional Go code and probably not something I would allow past a PR review. I’m saying this as someone who has built many production systems with Go and taught it to many devs coming from Java. This guide is more in-line with how Go enums should be designed: https://blog.learngoprog…
> So, while I dig a little further, I think it’s fair to warn people to take this with a grain of salt. Use the language yourself and come to your own conclusions as OP did.
I'm sure with the experience you have with Go, you can open a pull request to their notes to fix this issue.
Re: Show HN: My notes on Working with Go
#36Thank you. I am just beginning to learn Go. This will be very useful to me. If anyone knows similar notes for Python & C#, please reply.
What make you keep learning Go once you've tasted C# delights?
I started with Java, C#, and Python and one thing I really appreciated about Go was the simplicity. I like how many features it strips from C#. Some people take the tack that a language that is the union of all features is the best possible language on the grounds that one can choose their own feature set, but this is pretty obviously fallacious when you consider that you need to collaborate with others, use 3rd party libraries, etc. I also like the fact that it compiles to a single static binary by default.
Don't get me wrong, I think C# and .Net in general are pretty cool pieces of technology, but I never find myself reaching for them because I'm very often confident that I can get the job done more quickly with Go.
Re: Show HN: My notes on Working with Go
#37Earlier quoted context omitted.
It ignores some historical bad design decisions, the worst of them being having null in the language, the famous one billion dollar mistake. And well, no support for functional/immutable data structures is something I dislike. My squad did a micro-service in Go at work and was not pleasant as we expected.
Mh, so you wrote one micro-service and came to that conclusion? What did you do to learn the language beforehand? For what it's worth, I've been programming with Go professionally for a few years, and I do agree with the "null" issue. Although in practice - with a good development culture - it's less of a problem than you might think initially. We tend to avoid using pointers (because, they're not even faster than st…
I'm a big fan of ML-like type systems, but I never understand why Go gets so much more grief than Python, JS, etc for having nil. At least in Go, only reference types can be nil as opposed to literally any variable. Same with conversation about generics: "How can anyone write software in a language without [type-safe] generics?" of course lots of profitable software is written in languages with no type safety whatsoever and that doesn't seem to bother people.
Re: Show HN: My notes on Working with Go
#38Warning: opinions inbound I clicked one part (enums) and noticed a pretty glaring issue. The way you are doing enums is really _not_ conventional Go code and probably not something I would allow past a PR review. I’m saying this as someone who has built many production systems with Go and taught it to many devs coming from Java. This guide is more in-line with how Go enums should be designed: https://blog.learngoprog…
> So, while I dig a little further, I think it’s fair to warn people to take this with a grain of salt. Use the language yourself and come to your own conclusions as OP did. I'm sure with the experience you have with Go, you can open a pull request to their notes to fix this issue.
If no one has by EOD today, I will! Good idea. :)
Re: Show HN: My notes on Working with Go
#39Re: Show HN: My notes on Working with Go
#40Earlier quoted context omitted.
What make you keep learning Go once you've tasted C# delights?
I started with Java, C#, and Python and one thing I really appreciated about Go was the simplicity. I like how many features it strips from C#. Some people take the tack that a language that is the union of all features is the best possible language on the grounds that one can choose their own feature set, but this is pretty obviously fallacious when you consider that you need to collaborate with others, use 3rd part…
Just don't use the features you haven't yet learn.
In a few years of experience you will reach a plateau of productivity in go that you'll only be able to beat by migrating toward a more featureful/better thought language