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

Go 1.18

go.dev

Post reply on HN
Print view View original

291–300 of 614 posts

Re: Go 1.18

#291

Post by Thaxll »

SureshG wrote: post #281
zinclozenge wrote: post #193

Earlier quoted context omitted.

None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…

> None with the same performance characteristics, Most JVM languages (Kotlin/Scala/Clojure) including Java :) In fact kotlin/java has better peak performance than Go. Main advantage for go is the reduced memory footprint.

> In fact kotlin/java has better peak performance than Go.

Not really no.

Re: Go 1.18

#292

Post by Thaxll »

kaba0 wrote: post #261
zinclozenge wrote: post #193

Earlier quoted context omitted.

None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…

Scala is pretty close to Go in terms of popularity and I would argue that it has a much bigger ecosystem due to the JVM. It is also pretty much a typed python in terms of ease of use, and the JVM has stellar performance — other than small running scripts, for many kind of workloads Java’s state of the art GC will have better throughput than Go’s.

Scala is on its way to die actually, I worked couple of years with lot of services in Scala, they were all replaced by regular Java or C# over the years, Scala missed the train and it's more and more difficult to find people that want to work with that language.

It's a stagnant language that will not get more popular, it peaked.

Re: Go 1.18

#293

Post by uryga »

dialogbox wrote: post #274
shhsshs wrote: post #204

Earlier quoted context omitted.

I think this is appropriate in some cases but not others. For example how does the JSON value distinguish between `Some(null)` and `None`?

IMO using Optional type means the inner value must be not null. And if it's Some(null), it should mean exactly same as None.

distinguishing `Some(null)` and `None` is often considered a feature of Optional ;)

to use a tired example: when getting a value out of a map via some `myMap.get(key)`, you may want to distinguish "not present" = `None` and "present, with value null" = `Some(null)`

the right solution is to just not have nulls in the first place, then there's no problem ;)

Re: Go 1.18

#294

Post by noselasd »

drdaeman wrote: post #162
mseepgood wrote: post #105

Now Go has everything I need in a programming language!

Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics…

While you perhaps would not want to write the verbose version, I certainly would have much more fun reading and debugging the verbose version.

Re: Go 1.18

#295

Post by acuozzo »

MrDOS wrote: post #234
RodgerTheGreat wrote: post #199

Earlier quoted context omitted.

> A language needs only one conditional control flow construct. And yet, Go has a switch statement.

Not only that, but despite all of the other syntactic sugar Go is lacking (usually sorely, such as a “try” error handler), the switch statement is really just an “if” statement in disguise. var someVar, anotherVar string // ... switch { case someVar == "whatever": fmt.Println("Tell me how, exactly,") case anotherVar == "nope": fmt.Println("this compiles to a jump table?") default: fmt.Println("Spoiler: it doesn't.")…

> the switch statement is really just an “if” statement in disguise

If the switch is over a fixed set of strings, then can't the backend generate a perfect hash function ala gperf and then proceed to use the computed hash value to implement a jump table?

Also, FWIW, the only compiler backends I've ever seen blindly emit a jump table all died in the '80s. Jump tables aren't always the fastest choice: https://www.cipht.net/2017/10/03/are-jump-tables-always-fast...

Re: Go 1.18

#296

Post by collaborative »

Mawr wrote: post #245
drdaeman wrote: post #162

Earlier quoted context omitted.

Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics…

I agree that the latter version is too verbose, but if the alternative is this: err := h(cond(x) ? f(x) : g(x)) ... then I'd much rather stick with the verbosity. There's way too much going on in a single line here. I'd rather have if statements be expressions, with gofmt-enforced line breaks: err := h( if cond(x) { f(x) } else { g(x) }, ) No unnecessary temp variables and no stuffing everything into one line.

I love stuffing things into one-liners. Not hard to see what is happening if you understand it enough

Reason is I prefer to move my eye balls than scroll the screen. Too many lines and you forget what preceded what you're seeing or have to keep scrolling to make sense of everything

Re: Go 1.18

#297

Post by orangecat »

crtc wrote: post #164
drdaeman wrote: post #162

Earlier quoted context omitted.

Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics…

This is by design: https://go.dev/doc/faq#Does_Go_have_a_ternary_form Ken Thompson added ?: to B / C and then he took it from us in Go due to the wisdom he gathered in between.

The if-else form, although longer, is unquestionably clearer.

I disagree:

- The variable name is repeated three times, increasing visual clutter and the chance of typos.

- The variable can't declared immutable. In Java/JS/Dart/etc it's nice to know that after "const x = foo ? bar : baz", x won't change.

And you don't even have to add a new operator, Rust and Kotlin get these benefits with an expression form of if/else.

Re: Go 1.18

#298

Post by lawl »

pkulak wrote: post #71
_0w8t wrote: post #67

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal…

I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.

Hits the sweet spot for me between the one extreme of having to malloc/free everything myself and the other extreme where everything is immutable, garbage collected and you dont know what causes allocation.

The former is a nightmare for security and productivity, the latter is a nightmare for performance.

Re: Go 1.18

#299

Post by everybodyknows »

typical182 wrote: post #174

There is also a new set of FAQs on generics: https://go.dev/doc/faq#Type_Parameters

This is the part anyone writing performance-critical code will find troubling:

> The compiler can choose whether to compile each instantiation separately or whether to compile reasonably similar instantiations as a single implementation. ...

Re: Go 1.18

#300

Post by uryga »

LAC-Tech wrote: post #276
pharmakom wrote: post #207

Earlier quoted context omitted.

Optionals without do notation will be a bad time.

What's do notation? I've used optionals in many languages, and this is the first I've heard of it. What else do you really need except map and... flatMap (aka `then` aka `and_then` aka `>>=` aka `bind`).

https://en.m.wikibooks.org/wiki/Haskell/do_notation

rough analogy: `await` replaces `.then()`, do-notation replaces `.flatMap()`

Post reply on HN