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

261–270 of 614 posts

Re: Go 1.18

#261

Post by kaba0 »

zinclozenge wrote: post #193
ed25519FUUU wrote: post #131

Earlier quoted context omitted.

Plenty of great functional alternatives to Go.

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.

Re: Go 1.18

#262

Post by Zababa »

jrockway wrote: post #97
throwaway894345 wrote: post #12

Earlier quoted context omitted.

> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular beli…

I think people are going to go off the rails with functions that abstract over for loops. I see it all the time in Javascript code, where people iterate over an Array multiple times because that's what the API makes easy. For example, say you want to separate a slice into two slices, one that contains matches and one that contains everything else. Right now, you'd just write: var matches, mismatches []whatever for _,…

This is a wild guess, but maybe the Search function could be a bit better than expected if it was a bit smarter about allocation size than the regular version you posted. From what I understand, the initial capacity of slices is 0, which would mean that you get a few reallocations with the "naive" version. Search, on the other hand, could allocate a slice with a capacity that's a half of xs, so you only need one reallocation at worst.

This, mixed with the "Partition" function proposed by sibling comments (which would only iterate once) could lead to code that's faster than the regular approach, while also being shorter to write.

On the other hand, it's not as free as it seems, as now developers have to know the Partition function, and how it works. It may also have pitfalls that I haven't considered. As always, it's hard to find the perfect sweet spot between how much stuff developers should know and how much stuff should be explicit in the code all the time.

Re: Go 1.18

#263

Post by HideousKojima »

crtc wrote: post #121

Finally! This will be the last day I see the words "Go" "lack of"/"no" and "generics" in one sentence.

I mean in Java vs. C# fights people still bring up that C# generics are reified while Java generics rely on casting and erase type information at runtime, so probably not.

Re: Go 1.18

#264

Post by stingraycharles »

Mawr wrote: post #220
morelisp wrote: post #198

Earlier quoted context omitted.

Whether a pointer is bad for performance in this case seems hard to tell a priori. There are also performance advantages if Optional packs nicely.

It is just an assumption on my part, I figure that the cost of pointer chasing is generally going to outweigh any disadvantages. It can also help enable optimizations, for example slices and maps that do not contain pointers do not get scanned by the GC ([1]). [1]: https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e...

I fully agree with your approach. The important thing is that the user now has the choice to use a pointer or not: they can always use a pointer to the optional if they want to use pointers.

Pointers to pointers are generally something you try to avoid if possible.

Re: Go 1.18

#265

Post by heavyset_go »

daptaq wrote: post #200
frenchie4111 wrote: post #139

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional

My main fear with the introduction of generics was the lack of stdlib support. I know they want to play it safe and are planning to change this in future versions, but the last thing I want is that I have to download some github.com/foobar/... library for every common sense generic type I might want to use.

Agree with this sentiment. It was a very good idea to bring the `typing` module into the Python standard library versus just relying on Mypy.

Re: Go 1.18

#266

Post by Zababa »

ainar-g wrote: post #82
______-_-______ wrote: post #47

Earlier quoted context omitted.

Here's the original Rob Pike quote: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand…

That seems like a pragmatic and honest way of looking at software engineering, consistent with Russ Cox's later thoughts on the difference between programming and software engineering[1]. It sounds to me less like “this is a language for beginners and underperformers” and more like “this is a language using which large teams of programmers with varying levels of experience can be productive together”. > This attitude…

> Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.)

It's not only your personal observation (though I would remove the "purely" from "purely functional languages). A good indication of that: on the Go 2020 survey, the 6 most popular responses to "Which critical language features do you need that are no available in Go?" are features that functional programming languages have. All of these features are in ML and its descendants (SML, OCaml, Haskell, Scala, etc).

The graph: https://go.dev/blog/survey2020/missing_features.svg

The article: https://go.dev/blog/survey2020-results

Re: Go 1.18

#267

Post by cube2222 »

acchow wrote: post #252
cube2222 wrote: post #92

Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.

> That means ergonomic monads are not possible to implement This is a good thing?

Yes. I'm keeping up with the developments in functional languages, and many of them have lots of ways to do the same thing, with the "recommended" way changing once every 2 years.

I intentionally choose Go where idiomatic code 5 years ago is mostly the same as idiomatic code now. Where no matter who writes the code, it ends up being fairly similar. Where I can easily dive into any open source library, understand the code base in 10 minutes, and make the fix I need. Where there's little-to-no bike shedding.

I understand others might have different preferences, but as another comment mentioned, there are a bunch of languages satisfying those preferences very well (which I like very much as well overall, but I don't like using them for serious day-to-day coding). No reason to try to make everybody happy with a single language.

Besides, I also think monads aren't a very good abstraction to use in most of your day-to-day code, so I'm happy I can avoid code using them.

Re: Go 1.18

#268

Post by cardanome »

zinclozenge wrote: post #193
ed25519FUUU wrote: post #131

Earlier quoted context omitted.

Plenty of great functional alternatives to Go.

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…

Ocaml.

Insanely fast compiler. Great type system. Functional programming at its best but still relatively pragmatic and easy to mix in some imperative code if need be.

It is a bit more complicated than Go and the ecosystem is maybe a bit more patchy but other than you will have a good time.

Re: Go 1.18

#269

Post by Zalastax »

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

You may find my MsC thesis, link in profile, interesting! If I remember my writing correctly, I have similar reflections on CSP.

Re: Go 1.18

#270

Post by pie_flavor »

oxplot wrote: post #138

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only…

Certainly a better take than 'I don't like generics, it's somehow less complicated to downcast interface{} everywhere'. It was very interesting reading the justification for not having generic methods, and how that clashed with my assumption of what generics should be, or for that matter what methods should be. Go is the spiritual successor to C, IMO - for all that people use it nowadays for its low-level capability, people forget that its original purpose was to do what every other language of its day did, but way, way more simply.
Post reply on HN