91–100 of 209 posts
Earlier quoted context omitted.
I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.
If you don’t have a result type then you don’t have better error handling!
Earlier quoted context omitted.
Saying this about one of the fastest growing languages on the scene right now feels… weird?
I would say, many people also look down on much more popular languages, such as PHP. Go is still an absolute niche language, even more niche than languages like Scala or R.
Meanwhile, as a non Java programmer, I've never seen a Scala app. I know about R, but nothing on my PC is written in it.
Agreed that PHP is massive in comparison to all of them.
Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
If you are interested in generics in Go 1.18 please read https://go.googlesource.com/proposal/+/refs/heads/master/des...
Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
It's funny how codegen has become widespread in Golang to work around its deficiency.
> We expect that some package authors will be eager to adopt generics. If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts. I have a feeling this won't happen.
You're right. I maintain a very large code base in a private repo and a successful open source project. Generics will allow me to clean up a lot of code duplication internally, but given that Go modules are distributed as source code, this would force everyone to use Go 1.18. My plan is to not use generics for quite a while, as it's pointless to have two separate implementations, one for 1.18 and one for < 1.18, whic…
I hope that the publicity caused by generics doesn't taint this release causing people to unnecessary procrastinate a toolchains update they would have otherwise done if it wasn't for generics.
Earlier quoted context omitted.
Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics? The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something…
Right, I suppose I forgot that a big reason `Result` works well in Rust is the `?` operator. At the very least, I'll appreciate having some more sugar over loops that are essentially just map/filter.
Before Rust 1.12, Rust has a macro, named try! which does a similar thing to its argument although the built-in operator has some fancier features.
Earlier quoted context omitted.
On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?
Canadians now roll with the term Indigenous instead of Aboriginal
Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
I love the reply: “c++ allows zero width spaces in variable names. where’s your god now?”
[0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p194...
Earlier quoted context omitted.
I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.
I like what Chris Lattner said about language design in Lex Fridman podcast, that you know when you're doing something right because it "feels" right. Rust has a bunch of syntactic sugar which gets critised in many languages, but to me things like error returns with ? "feels" right. Love Go as well, and the error handling makes a lot of sense in concept but it just doesn't "feel" nice to look at or use. I like there'…
I do appreciate rusts match syntax though.