Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn Go in five minutes

gist.github.com

Post reply on HN
Print view View original

61–70 of 137 posts

Re: Learn Go in five minutes

#61

Post by cesarb »

corytheboyd wrote: post #52
cute_boi wrote: post #19

Earlier quoted context omitted.

I like C but I would prefer Rust over Go. Go may be simple but I really hate using conventions like init(), comments working like syntax, captial letter means published etc.

Doesn’t Rust have “comments working like syntax” in the form of #[derive] etc.? I’ve only read through the rust book without using it for anything (yet) and have done no work on golang, so I’m legitimately curious to hear your input, not challenging you on semantics :p Edit: Rust does not use # for comments. Sorry I just had that mixed up in my head, but thanks for the answers!

These #[...] and #![...] are not comments; they're attributes (somewhat similar to Java's @Something annotations). Comments in Rust start with // or / like in C or C++. There's only the special case that "doc comments" (starting with /// or / or //! or /!) are automatically converted into #[doc="..."] or #![doc="..."] attributes.

The difference is that attributes are always meaningful to the compiler (and can only be used in specific places); other than doc comments (which turn into attributes), comments never are meaningful to the compiler.

(edit: HN's comment markup eats the * character, I replaced them with above)

Re: Learn Go in five minutes

#62

Post by AlchemistCamp »

murukesh_s wrote: post #54
BoorishBears wrote: post #43

Earlier quoted context omitted.

I explicitly added the "ps" to avoid the situation where all the replies are fairly empty comment saying "Well we use it!" I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages. That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional ef…

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.

Re: Learn Go in five minutes

#63

Post by corytheboyd »

brundolf wrote: post #55
corytheboyd wrote: post #52

Earlier quoted context omitted.

Doesn’t Rust have “comments working like syntax” in the form of #[derive] etc.? I’ve only read through the rust book without using it for anything (yet) and have done no work on golang, so I’m legitimately curious to hear your input, not challenging you on semantics :p Edit: Rust does not use # for comments. Sorry I just had that mixed up in my head, but thanks for the answers!

#[...] is an attribute, more like @foo annotations in Java, not a comment. Comments do not use # in Rust

> Comments do not use # in Rust

Oof what a dumb mistake, sorry about that!

Re: Learn Go in five minutes

#64

Post by bird_monster »

mynameisash wrote: post #30
cfors wrote: post #12

This is neat, and a testament to the simplicity of Go. I normally point people to this tutorial if they want to learn Go quickly, it is interactive (able to navigate straight to go playground) and very well done in my opinion. https://gobyexample.com/

> the simplicity of Go As someone who's not written any Go, I found fasterthanlime's critique of the language[0] damning enough that I likely won't ever touch the thing. Maybe he's cherry-picked examples, but his article was thorough and technical enough to convince me that the Go mantra of simplicity is just surface-level. [0] https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

It sounds like you've made up your mind, but I might suggest reading less overwhelmingly biased critiques. That post makes incorrect assumptions about go, and then exhibits the result of their incorrect assumptions, and then brings up how, when making the correct assumptions in Rust, the outcome is different. Can you see how this is a flawed strategy?

Go isn't for everyone, and that's okay, but it seems kind of silly to make a judgement based off of a negative review hinging on a pretty poor understanding of a language.

Re: Learn Go in five minutes

#65

Post by jtdev »

murukesh_s wrote: post #54
BoorishBears wrote: post #43

Earlier quoted context omitted.

I explicitly added the "ps" to avoid the situation where all the replies are fairly empty comment saying "Well we use it!" I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages. That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional ef…

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…

Any examples of Node being faster to write than Go? Did this have anything to do with the plethora of npm packages available?

Re: Learn Go in five minutes

#66

Post by H1Supreme »

murukesh_s wrote: post #54
BoorishBears wrote: post #43

Earlier quoted context omitted.

I explicitly added the "ps" to avoid the situation where all the replies are fairly empty comment saying "Well we use it!" I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages. That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional ef…

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…

This is purely anecdotal, and simply suggests you know Node.js better than Go.

Re: Learn Go in five minutes

#67

Post by mhh__ »

37ef_ced3 wrote: post #29
Lariscus wrote: post #5

Earlier quoted context omitted.

I like C but strongly dislike Go. They share nothing other than having a small(ish) feature set.

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)…

Slices should be the absolute bare minimum for a modern systems language, it's not really a reason to switch in my case

If I want to write flat/simple code I'll just C, Go doesn't really offer anything to me because I want to be relatively low-level and able to make the compiler save my time.

Re: Learn Go in five minutes

#68

Post by BoorishBears »

blablabla123 wrote: post #56
BoorishBears wrote: post #14

Earlier quoted context omitted.

I agree. Go feels like it's aimed at creating applications that run at a level above where C traditionally runs while keeping the pared down feature set of C, and it just doesn't work well imo. 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. It's like the simplicity gets in the way of itself.…

> 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 around in go circles if that made sense, and called out how bad the felt but the answer was "no that's great! channels are cheap! the repetition is good because it's simple!"

-

The error handling has some sore points to that end too, and the implicit shadowing with shorthand assignments on one hand makes it easier to deal with multiple errors, but on the other hand introduced subtle logic bugs on one than more occasion where "err" was silently shadowed, which I greatly disliked.

I'm actually suprised Go didn't forgo shadowing for the shorthand operator and force people to label their errors when dealing with multiple, it seems very "in brand", but I guess even Go draws the line somewhere lol

-

Then there's the whole stack trace situation. Which after plenty of reading still just wasn't making sense. I mean the idea of logging a stack of wrapped messages sounds very nice, but man proper stack traces not being the first class citizen of error handling just did not make sense to me in a language I hear referenced for systems work so much (and I realize they can be had)

I saw proposals to rework Go's error handling, I don't know if any progress has been made to that end, but it's another example where simplicity can get in the way of itself

-

And I'll balance this all out by saying it was still fun to write, I don't want to seem like I'm just shitting on Go for existing.

It's just these little warts that I kept getting over with just a little bit of "idiomatic Go" which I often found was just writing a little bit more code than you're used to, started to add up.

And eventually I realized I was creating something that, while very easy to reason about, had a lot more to reason about than it needed to. That's where I kind of petered out in my personal usage.

Re: Learn Go in five minutes

#69

Post by xscott »

37ef_ced3 wrote: post #2

Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.) Go puts essential C idioms directly into the language (pointer/length is formalized as slic…

> Go fixes C's well-understood flaws (declaration resembling use

This seems to be a common belief, but since Go kept pointer syntax as prefix, you're still stuck needing parens in some unfortunate cases:

https://blog.golang.org/declaration-syntax (see the part about pointers near the bottom)

As Rob Pike writes in that link, they could've fixed it and still had declaration resembling use if they had chosen a suffix operator for pointers. He notes that Pascal uses ^, but it seems like @ might be a better choice:

    int foo         // an integer
    int foo@        // pointer to int
    int foo[10]@    // 10 pointers
    int foo@[10]    // pointer to array
    int foo()[10]@  // function that returns an array of 10 pointers
In my opinion, they almost fixed it and then punted. As such, it's just different, but not really better.

Re: Learn Go in five minutes

#70

Post by diehunde »

Something it's missing in the CS teaching industry is material (and probably a method too) for experienced programmers who want to learn a new language. It's so hard to find resources to learn the spirit and philosophy behind a language and at the same time learn the syntax without spending time on basic stuff like declaring variables or functions.
Post reply on HN