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

51–60 of 137 posts

Re: Learn Go in five minutes

#51

Post by traes »

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

I'm not really sure saying that features in Go can be modeled in C really suggests that they are similar as languages. Syntax is very important.

Re: Learn Go in five minutes

#52

Post by corytheboyd »

cute_boi wrote: post #19
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…

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!

Re: Learn Go in five minutes

#53

Post by fwip »

Thaxll wrote: post #42
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.

init() is not a convention and it's not used that much. For comments I don't understand what you're saying. And for caps I think it's better than public / private keyword.

Certain comments have a special meaning to some tooling. In this sense, it's not very different from Javadocs.

For some examples: A comment that appears right before a type or function definition is exported as documentation by the "go doc" tool.

Another one is build constraints, which appear as a comment at the top of the file, like: `// +build linux` to say "only include this file if the build target is linux."

Other tools use their own comment format to recognize comments meant for them.

Re: Learn Go in five minutes

#54

Post by murukesh_s »

BoorishBears wrote: post #43
bak3y wrote: post #18

Earlier quoted context omitted.

Meanwhile the place I work writes all microservices in go and all of my team's (DevOps) tools are also written in go...

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 into micro services) in future if it becomes massively successful..

Re: Learn Go in five minutes

#55

Post by brundolf »

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!

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

Re: Learn Go in five minutes

#56

Post by blablabla123 »

BoorishBears wrote: post #14
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.

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 the same time it can be quite some effort to create such code and might take several iterations. Documentation-wise I like the official documentation, it gives a lot of pointers why Go is how it is.

Also obviously it's not for every use-case. Where it works really well IMHO is where error handling is a vital part of the application. (And of course anything concurrent is quite a breeze)

Re: Learn Go in five minutes

#57

Post by jrockway »

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-...

How is this damning, exactly? It's a very specific set of library quirks that are kind of expected -- Chmod doesn't do much on Windows. Arguably, maybe Chmod shouldn't be in the core library if it can't do everything on every OS/architecture combination, but I am not sure that damns the language. It does the best it can, but doesn't deliver a POSIX overlay for Windows. (The complaint continues into a discussion of build tags, to make Windows-only code compile only on Windows. Again, what's the alternative here? If you want your program to do different stuff depending on the platform, there's going to be some sort of conditional to apply that.)

There is then a discussion about monotonic time. The author immediately knows they want monotonic time, but there is no method that specifically returns that. Instead, go embeds the wall clock and monotonic time into a time.Time when you create one with time.Now. It uses the wall clock time for display, and monotonic time to compute the difference between two timestamps. This is not what the author expected, but it ultimately allows them to do what they want. (There is then a complaint about how when you boot a Raspberry Pi without giving userspace any time to start up, the time is set incorrectly, and Go doesn't help. Well... yeah. You can add a hardware RTC if you want the time to be correct as soon as the i2c subsystem comes up, or you can wait for NTP, or you can live with the wrong time. Not sure how any of this involves Go -- it does expect the OS to do OS things for it.)

If you were going to write a damning critique of why to never use Go, it would probably be something like "this dumb library uses channels, sync.Mutex, and atomic.AddInt64 all in the same code and it deadlocks and runs out of memory" or "I installed the most popular ORM on Github and it prints colored text to the console when there is a database error rather than returning an error from the function". I think the linked article totally misses the mark on what problems people are likely to encounter with Go. Let's be honest -- 99% of programmers have no idea that their OS has a monotonic clock, and are quite surprised (and have no idea how to fix it) when start := time.Now(); time.Sleep(time.Second); fmt.Println(time.Since(start)) prints a negative number. But... with Go they don't have that problem. Pretty interesting.

Re: Learn Go in five minutes

#58

Post by AlchemistCamp »

bak3y wrote: post #18
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.…

Meanwhile the place I work writes all microservices in go and all of my team's (DevOps) tools are also written in go...

Go can be nice for simple domains where performance is very important. In most cases like that, I'd use Rust, though.

Re: Learn Go in five minutes

#59

Post by nyanpasu64 »

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

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 sometime after all the slices are gone.

This reminds me of Numpy's ndarrays, which act more like "owning containers" (which may sometimes share ownership and alias) than "non-owning references".

Re: Learn Go in five minutes

#60

Post by bmn__ »

enw wrote: post #34
simias wrote: post #20

Earlier quoted context omitted.

My main small day-to-day usability gripes with C are lack of type inference, lack of destructors and terrible ergonomics for error handling. Go solves two out of three, but it really dropped the ball hard on error handling which is very disappointing IMO. Things like generics and garbage collection involve some deep tradeoffs, so I get Go's take on them, even if I don't necessarily agree with it. On the other hand IM…

How would you design the error handling? Personally I'm glad Go has stayed out of exceptions (panics don't count), at scale it's so much easier to reason about flow.

Monadic error handling like in ML work-alikes, Rust etc. would be a good start. Adopt:

• https://github.com/rebeccaskinner/gofpher

• https://speakerdeck.com/rebeccaskinner/monadic-error-handlin...

I've been talking to the local Go user group. No one even knows about that concept. This continues a pattern of general ignorance/lack of looking beyond one's horizon I've noticed.

Post reply on HN