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

Go 1.13 Release Notes

golang.org

Post reply on HN
Print view View original

201–210 of 264 posts

Re: Go 1.13 Release Notes

#201

Post by majewsky »

masklinn wrote: post #183
mseepgood wrote: post #91

Earlier quoted context omitted.

> From 10000000 to 10_000_000 is such a readability improvement and should be no-cost. 1e7

> 1e7 Is a float literal.

Not in Go. Number literals don't have a type until they're assigned to a variable or used in a place that implies a type (e.g. a function argument). For example, the following is valid:

  var u uint32 = 10000000000.0 / 100000
even though 10000000000 overflows uint32 and it's also written like a floating-point literal.

Re: Go 1.13 Release Notes

#202

Post by pjmlp »

bborud wrote: post #148
sime2009 wrote: post #21

How does Go compare to Rust these days with respect to language maturity, community size and general maturity/availability of libraries? So far I've found Rust more interesting and pushes the envelope a bit more. But what is the sales pitch for Go?

The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. Perhaps I’m old and grumpy but I feel that at this point I’ve had every language discussion before and if people start to moan about lack of metaprogramming support I just leave. I have yet to see a project that failed due to lack of high order abstractions

I have yet to see a project that failed due to being written in Assembly, yet we moved on to better abstractions.

Re: Go 1.13 Release Notes

#203

Post by tapirl »

bborud wrote: post #148
sime2009 wrote: post #21

How does Go compare to Rust these days with respect to language maturity, community size and general maturity/availability of libraries? So far I've found Rust more interesting and pushes the envelope a bit more. But what is the sales pitch for Go?

The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. Perhaps I’m old and grumpy but I feel that at this point I’ve had every language discussion before and if people start to moan about lack of metaprogramming support I just leave. I have yet to see a project that failed due to lack of high order abstractions

> The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software.

More accurately speaking, Rust forces people writing software in a specified way. You need to think about how to write software much less in Rust than in Go. In Go, you really need to think more to choose a better solution from many potentials.

Re: Go 1.13 Release Notes

#204

Post by tapirl »

rb808 wrote: post #62
sime2009 wrote: post #21

How does Go compare to Rust these days with respect to language maturity, community size and general maturity/availability of libraries? So far I've found Rust more interesting and pushes the envelope a bit more. But what is the sales pitch for Go?

I just wish there were more jobs for either. They're both much less popular than I expected.

It depends on which fields of your expected jobs are. Go is the language of cloud infrastructure, and half of blockchian projects are written in Go.

Re: Go 1.13 Release Notes

#205

Post by tapirl »

littlestymaar wrote: post #124
ainar-g wrote: post #84

Earlier quoted context omitted.

Genuine question: What does Cargo do that Go 1.11 modules can't?

Applying the bug fixes in a dependency I'm using when a new version of it is published… [1] Sarcasm apart, I wasn't talking about features. But cargo is a really well-designed package manager. I've been using Rust full-time for 2 years now and it had never annoyed even once. [1] the sarcasm was referring to the Minimum Version Selection algorithm used by go's package manager, which is a really bad case of NIH from Go…

> Applying the bug fixes in a dependency I'm using when a new version of it is published…

You can replace a dependency with a local modified copy of the dependency to do this.

Minimum Version Selection is for security reason. It might has some disadvantages, but personally I like it. It gives programmers more control.

Re: Go 1.13 Release Notes

#206

Post by Cthulhu_ »

shkkmo wrote: post #179
cesarb wrote: post #168

Earlier quoted context omitted.

IMO, using an environment variable for that is not robust. If the environment variables have been cleared (for instance, due to "su -" or similar), or if they have never been set (for instance, because you just checked out the code on a new machine and forgot to configure the environment variables there, or because you did remember to configure the environment variables but forgot that startup scripts do not take eff…

You can use a shell script that you check into your repos that explicitly sets these environment values instead of using the go command directly. As long as you habitually never run "go get" or "go build" directly it ameliorates the issues you mentioned.

Indeed; if you're working with multiple developers and you need these policies enforced, you should use e.g. a makefile. I'm not sure if it's possible to force the use of that over straight `go` commands though.

Re: Go 1.13 Release Notes

#207

Post by eptcyka »

nemo1618 wrote: post #86
omaranto wrote: post #74

I haven't been keeping up with Go. Is it still the case that the only datatype than can be used as keys to a map and is not of a fixed size is string?

Strings are fixed-size, though. A string is a pointer and a length. It's true that you can't use a slice as a map key, though, even though slices are also fixed-size (pointer, length, and capacity). As I recall, the argument is that the equality rules for slices are unclear. (maps and funcs can't be used as keys either, for the same reason: they're not comparable.) Is a 0-length slice equal to a nil slice? Is a slice…

Would it be too hard to just compare arbitrary slices and arrays based on the contents of said data structures? Converting arbitrary bytes to strings should fail at least some times, since not all byte sequences are valid UTF-8, and afaiu, in Go, the string type should always contain valid UTF-8.

Re: Go 1.13 Release Notes

#208

Post by tapirl »

Groxx wrote: post #120
sime2009 wrote: post #32

Earlier quoted context omitted.

Would it be fair to say that Go's concurrency support makes it a good match in the network services space? I see Go more often in Docker and cloud contexts.

Personal opinion: no. Go's concurrency is hard to control or monitor, and it's hard to make higher level abstractions that are both safe and convenient. It's of course possible, but the tradeoffs are rather severe. Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools. When you don't care if something gets abandoned or fails to make progress and can just ctrl-…

> Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools

This is not reasonable. Go's concurrency shines for its flexibility. It has nothing related to whether or not the written programs are short/long-lived. It is the only language which gives me a happy and fun experience in concurrent programming.

> For long lived processes though, like most services, it feels very error-prone or very boilerplatey and manual.

This is not reasonable too. Whether or not a written program is robust depends on the experience of the authors. Rust may reduce many mistakes at compile time, but it can't prevent all mistakes. Programmers still need experience to avoid many mistakes.

Re: Go 1.13 Release Notes

#209

Post by Cthulhu_ »

JNRowe wrote: post #51
skunkworker wrote: post #12

Earlier quoted context omitted.

It brought one of my favorite parts about writing numbers in languages such as Ruby over to Go. From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.

While I too like the change, there can be a user cost. For example, it makes using grep across a project slightly more annoying. Much like the flexible identifier rules in nim, it feels great but using common tools suddenly needs more thought.

Would it make sense to have an editor display a number in a more readable fashion while the source code itself has the grep-able version? I'm not a fan of ligatures myself but that is also done purely as presentation logic.

Re: Go 1.13 Release Notes

#210

Post by Cthulhu_ »

derefr wrote: post #27
paulddraper wrote: post #24

Earlier quoted context omitted.

Underscores are nice. 10 * 1000 * 1000 worked pretty well too.

Compile-time integer exponentiation in Go would be neat, e.g. 5 ＊ (1000＊＊4). I know we have scientific-notation integer literals, but it's not the same thing, especially when trying to calculate e.g. Mebibytes.

You say that, but I find that a lot harder to read (and using `e` notation) than just the number - and readability / clarity is more important than cleverness, especially in Go.

10_000_000 can be read, 5 ＊ (1000＊＊4) and 1e7 has to be decoded. By me anyway, I'm just an average developer that never did well in maths - and you have to write code for the average developer, not for yourself and not for the top 10% smartest people.

Post reply on HN