Live data from Hacker News

Learn Go in five minutes

gist.github.com

101–110 of 137 posts

Re: Learn Go in five minutes

#101
post #89

No offense to the author here ... but I need to vent some personal frustration. Every tutorial goes through these exact same motions for learning a new language. It sucks! Programmers can figure out what a variable is, or how to use an array or a map. Those things really don't change a whole lot between languages. What about how to import code from different modules? Best practices for organizing code? How your langu…

Seconded. Especially for Go, because it's mostly a lowest common denominator of language features it's not hard to write the code itself. The problem is that the module system is different and had plenty of changes along the years, What I would really like is an up to date "learn how to handle Go project in 30 minutes" tutorial (initialize new project with all best practices, add modules, publish, fork&clone&submit&p…

>What I would really like is an up to date "learn how to handle Go project in 30 minutes"

1. git init

2. git remote add %something%

3. go mod init %name_of_your_module% (where in most common case name is your repo address without the https part)

4. https://github.com/golang-standards/project-layout - this repo has the default project structure. Each subfolder has README that describes the purpose of the folder

5. go get -u github.com/gin-gonic/gin to add gin (web lib) for your project. Same for any other package. The will be added to your go.mod and go.sum files

5.1 import "github.com/gin-gonic/gin" in your code to use gin

5.2 package may have more than one major version (tag). If you want to use package at latest tag 2 - you add '/v2' when you 'go get' the package (i.e. go get -u github.com/gin-gonic/gin/v2)

6. git commit && git push to publish

7. Not sure what to you mean by 'fork&clone&submit&pr including 3rd party submodules'. You may use vendoring but in most cases you don't need it as you have your dependencies in your go.mod && go.sum files. You may want to read more about vendoring and gomodproxy though.

8. Testing is pretty easy but I guess you want and article about best practices? I won't post any link as I find the topic as too controversial regardless of the language\stack

9. CI - not sure that does this have to do with the language

10. haven't done much profiling or debugging to fill you in.

Re: Learn Go in five minutes

#102

Earlier quoted context omitted.

I have used Go in production. I found it roughly takes 2-3x additional time it takes to develop the same functionality in Node.js (with typescript). But it runs faster. If you want to write code that is probably not going to be thrown away it may be wise to invest the additional time in Go. However can't recommend that for building experimental code/APIs etc which are time bound and may/can get replaced (or split int…

And that's saying something give that neither Node nor TypeScript have ever had productivity as a main selling point! Imagine evaluating the time to market for an experimental back-end written in Rails, Laravel, Phoenix, etc vs Go! The difference is staggering.

>Rails, Laravel, Phoenix, etc vs Go!

Comparing frameworks and a language, really?

Re: Learn Go in five minutes

#103

Learn linear algebra ... in just 5mins! Learn the lambda calculus ... in just 5mins! Learn how to write a novel ... in just 5mins! Learn how to be a stand up comedian ... in just 5mins! Learn kung fu ... in just 5mins! Learn how to be a world class lover in bed (or out!) ... in just 5mins! Man, that was the best half-hour I've ever spent in my life. Sorry, I couldn't fit in Go, though.

should have opted for the four minute courses ;)

Re: Learn Go in five minutes

#104
post #38

Earlier quoted context omitted.

The last couple of years are showing that Go delivers, it's pretty easy to find dozen of "real" software written in Go that are weidly used.

Sometimes I don't know why I bother talking about Go. It's proponents are so quick to go defensive that no one is capable of reading any complaint in an even mildly charitable light. I mean I shouldn't literally have to say "I'm not saying you can't use Go for real work before someone flies at me." When talking about a language as widely used as Go right? Like that's common sense! And yet of course I'm getting replie…

Maybe don't use things like " to a language more suited for real work."

Re: Learn Go in five minutes

#105

Earlier quoted context omitted.

The Go authors have (ab)used comments to extend the language in experimental ways for code generation, build pragmas and recently file embedding. They’ve done this to avoid breaking the language stability guarantee, not sure if there were other reasons. I think it’s a mistake personally to create this sort of metalanguage in comments (now you have two problems!) but it’s easy to avoid using this most of the time as t…

File embedding is a common enough use case (HTML templates, config files) that it really makes me cringe that it's being done with comments.

I just keep my templates and config in separate files.

There are good reasons to keep them separate anyway (allows config without recompile for example) and for the apps I work on distribution isn’t a problem. So I haven’t really had to use comments as code in 7-8 years of go. Perhaps it’ll become more common with the embed stuff. But then I don’t use struct tags either so I guess I’d prefer Go to be even simpler.

Re: Learn Go in five minutes

#106

Earlier quoted context omitted.

Take Go's slices, for example Realize a Go []int ("slice of int") is just a C struct like this, passed by value: struct intSlice { int* addr; int len; int cap; }; The memory at addr is not owned by the slice. All the slice operations are simply notation for manipulating the struct. Go's garbage collection makes the whole thing work well This can be confusing if you're used to C++'s std::vector (which owns the memory)…

Go's slices don't act like what I thought were called "non-owning references"(Rust's &/&mut [T] or C++'s std::span ), which reference memory whose lifetime is bounded by something else (like a vector or array or shared pointer). Instead it's "shared ownership" where memory is referenced by one or more slices (and no single owner) which can reference and mutate the slice simultaneously, and it's freed by the GC someti…

Slices are kind of a mess. They should either be uniqueness types or passed by reference (the way maps and channels are, and NIO buffers from Java). Instead they’re passed by value so multiple copies exist whose sizes and sometimes contents aren’t in sync.

Re: Learn Go in five minutes

#107

Earlier quoted context omitted.

> I loved playing with Go, but eventually it feels like you're conditioning yourself to be ok with a lot of "bad" code. Tons of repetition, tons of boilerplate by other names. Not well or hastily written Go is easily like that. I can only guess why you point out the repetition but when you look at well written Go code like in the Go std library, there isn't much repetition happening and it looks rather elegant. At th…

Not having generics, by definition, invites a lot of repetition and boiler plate. I know generics are overrated and coming soon, but right off the bat that stuck out. I recall a point where I had written a function that needed to return a channel, but of course had to forgo types due to the lack of generics. The end result was having to wrap that channel in another channel that added typing at each call site. I asked…

It probably doesn't work to convince you, still I see that differently ;)

About generics, it depends on the problem at hand. When writing a generic Matrix multiplication type that for instance should work both on real and complex numbers (or more obscure types) generics are a thing. On the other hand, when working for instance with golang.org/x/net/html, I really appreciate the interface definitions and the possibility to do type switches on those.

The error handling problem can also be dealt with. I also prefer to not shadow variables, IMHO the ideal function has all its variables defined already in the signature.

I mean there are stack traces when a panic is called, or something that wraps it like a log.Fatalf. I guess the idea is the author is giving much more thought to how errors are dealt with and how they are printed in a both useful (=greppable) and beautiful way. As an end user that doesn't want to dive into the code I probably always prefer to see a nicely formatted error message (or even a gracefully handled error) instead of a 100 line stack trace. Probably Go is not just the language spec but also how to use it. Therefore saying "Learning Go in 5 minutes" is probably a bit far-fetched ;-) (Probably for any language that would be true...)

Re: Learn Go in five minutes

#108
post #104

Earlier quoted context omitted.

Sometimes I don't know why I bother talking about Go. It's proponents are so quick to go defensive that no one is capable of reading any complaint in an even mildly charitable light. I mean I shouldn't literally have to say "I'm not saying you can't use Go for real work before someone flies at me." When talking about a language as widely used as Go right? Like that's common sense! And yet of course I'm getting replie…

Maybe don't use things like " to a language more suited for real work."

There is a literal full paragraph dedicated to explaining it, maybe don't ignore the oodles of context I left to avoid exactly what you did.

Saying other languages are more suited to real work doesn't mean Go isn't suited at all, it literally means other languages are more angled towards the "end product" or the "real meat and potatoes" of just making a thing work than Go.

It's literally a strength of Go. Go doesn't want to include the kitchen sink or even confine you to having a kitchen at all and I respect that.

But I'm saying that other languages that include more in the way of affordances can help one be more productive, and I believe combining a language that includes more, with the mindset of not abusing the buffet is a winning combination.

Ymmv, I'm not an oracle, I just expect people to read things in a reasonably charitable way which usually works fine as long as they're not being defensive.

Re: Learn Go in five minutes

#109

Earlier quoted context omitted.

Not having generics, by definition, invites a lot of repetition and boiler plate. I know generics are overrated and coming soon, but right off the bat that stuck out. I recall a point where I had written a function that needed to return a channel, but of course had to forgo types due to the lack of generics. The end result was having to wrap that channel in another channel that added typing at each call site. I asked…

It probably doesn't work to convince you, still I see that differently ;) About generics, it depends on the problem at hand. When writing a generic Matrix multiplication type that for instance should work both on real and complex numbers (or more obscure types) generics are a thing. On the other hand, when working for instance with golang.org/x/net/html, I really appreciate the interface definitions and the possibili…

I'm aware of stack traces on panics, but my understanding is you only get them if you let them bubble up and kill the application (so not really a "first class" option for errors in places like web handlers) Has that changed, or did I misunderstand?

But I also think the stack trace message example is the perfect example of what I mean by "take the Go mentality with you"

In a language like Kotlin for example, Go got my in the habit of attaching more information to exceptions as they bubble up.

I was already generally in the habit of wrapping library exceptions, but I started religiously using a Result nomad implementation and wrapping errors with additional information so that my stack traces looked very "Go-like" in terms of human readability, but kept traditional stack trace information.

It's small things that I think using Go makes you "re-appreciate" in other languages

Re: Learn Go in five minutes

#110
post #101
post #89

Earlier quoted context omitted.

Seconded. Especially for Go, because it's mostly a lowest common denominator of language features it's not hard to write the code itself. The problem is that the module system is different and had plenty of changes along the years, What I would really like is an up to date "learn how to handle Go project in 30 minutes" tutorial (initialize new project with all best practices, add modules, publish, fork&clone&submit&p…

>What I would really like is an up to date "learn how to handle Go project in 30 minutes" 1. git init 2. git remote add %something% 3. go mod init %name_of_your_module% (where in most common case name is your repo address without the https part) 4. https://github.com/golang-standards/project-layout - this repo has the default project structure. Each subfolder has README that describes the purpose of the folder 5. go…

Damn.

> https://github.com/golang-standards/project-layout

I was almost with you but please don't share that repo. It's a terrible layout and the docs aren't accurate. The issues are full of Go community folk saying it's misleading and looks official but isn't.

Post reply on HN