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

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

131–140 of 280 posts

Re: Go's Sweet 16

#131

Post by tmoertel »

The introduction of automatic code modernizers to keep legacy code up to date with modern Go idioms is interesting:

> With gopls v0.18.0, we began exploring automatic code modernizers. As Go evolves, every release brings new capabilities and new idioms; new and better ways to do things that Go programmers have been finding other ways to do. Go stands by its compatibility promise—the old way will continue to work in perpetuity—but nevertheless this creates a bifurcation between old idioms and new idioms. Modernizers are static analysis tools that recognize old idioms and suggest faster, more readable, more secure, more modern replacements, and do so with push-button reliability. What gofmt did for stylistic consistency, we hope modernizers can do for idiomatic consistency.

Modernizers seem like a way make Large-Scale Changes (LSCs) more available to the masses. Google has internal tooling to support them [1], but now Go users get a limited form of opt-in LSC support whenever modernizers make a suggestion.

[1] https://abseil.io/resources/swe-book/html/ch22.html

Re: Go's Sweet 16

#132

Post by j-scott »

Someone wrote: post #125
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

> Which makes sense, it's got the smallest language spec of any of them I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-pr... : “The grammar described he…

My original comment was incorrect. These are being parsed as octals, not decimals: https://go.dev/play/p/hyWPkL_9C5W

Re: Go's Sweet 16

#133

Post by liampulles »

I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily.

This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin up CLI tools which use business logic code to fix things.

Re: Go's Sweet 16

#134

Post by mseepgood »

Someone wrote: post #125
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

> Which makes sense, it's got the smallest language spec of any of them I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-pr... : “The grammar described he…

You're looking at the wrong production. They are octal literals:

    octal_lit      = "0" [ "o" | "O" ] [ "_" ] octal_digits .

Re: Go's Sweet 16

#135

Post by j-scott »

neild wrote: post #129
Someone wrote: post #125

Earlier quoted context omitted.

> Which makes sense, it's got the smallest language spec of any of them I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-pr... : “The grammar described he…

0600 and 0_600 are octal literals: octal_lit = "0" [ "o" | "O" ] [ "_" ] octal_digits .

Never mind, I was wrong. Here’s a playground showing how go parses each one: https://go.dev/play/p/hyWPkL_9C5W

Re: Go's Sweet 16

#136

Post by callc »

pekim wrote: post #101
culebron21 wrote: post #93

Earlier quoted context omitted.

> It has proper enums. Well, then they look awkward and have give a feel like it's a syntax abuse. > Its arrays and slices are exactly the same as how you would do it in C. So while it is true that trips up many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic. In Rust, I see exactly what I work with -- a proper vector, material thing, or…

Inserting elements in to a slice can be done quite easily since the introduction of the slices package to the standard library. https://pkg.go.dev/slices#Insert

You shouldn’t need a library to do this simple operation.

I’m guessing the go language design went too far into “simplicity” at the expense of reasonableness.

For example, we can make a “simpler” language by not supporting multiplication, just use addition and write your own!

Re: Go's Sweet 16

#138

Post by mseepgood »

j-scott wrote: post #135
neild wrote: post #129

Earlier quoted context omitted.

0600 and 0_600 are octal literals: octal_lit = "0" [ "o" | "O" ] [ "_" ] octal_digits .

Never mind, I was wrong. Here’s a playground showing how go parses each one: https://go.dev/play/p/hyWPkL_9C5W

> Octals must start with zero and then o/O literals.

No, the o/O is optional (hence in square brackets), only the leading zero is required. All of these are valid octal literals in Go:

0600 (zero six zero zero)

0_600 (zero underscore six zero zero)

0o600 (zero lower-case-letter-o six zero zero)

0O600 (zero upper-case-letter-o six zero zero)

Re: Go's Sweet 16

#139

Post by j-scott »

mseepgood wrote: post #138
j-scott wrote: post #135

Earlier quoted context omitted.

Never mind, I was wrong. Here’s a playground showing how go parses each one: https://go.dev/play/p/hyWPkL_9C5W

> Octals must start with zero and then o/O literals. No, the o/O is optional (hence in square brackets), only the leading zero is required. All of these are valid octal literals in Go: 0600 (zero six zero zero) 0_600 (zero underscore six zero zero) 0o600 (zero lower-case-letter-o six zero zero) 0O600 (zero upper-case-letter-o six zero zero)

My bad! I was wrong; added a playground demonstration the parsing behavior above.

Re: Go's Sweet 16

#140

Post by tptacek »

stackghost wrote: post #77
throwaway894345 wrote: post #75

Earlier quoted context omitted.

When Go was new, having better package management than Python and C++ was saying a lot. I’m sure Go wasn’t the first, but there weren’t many mainstream languages that didn’t make you learn some imperative DSL just to add dependencies.

Sure, but all those languages didn't have the psychotic design that mandated all your code lives under $GOPATH for the first several versions. I'm not saying it's awful, it's just a pretty mid language, is all.

That was a Plan9ism, I think. Java had something like it with CLASSPATH too, didn't it?
Post reply on HN