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

551–560 of 614 posts

Re: Go 1.18

#551

Post by acchow »

cube2222 wrote: post #267
acchow wrote: post #252

Earlier quoted context omitted.

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

> 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.

On the other hand, I think people are stuck in Monads all over the place without even realizing it's a Monad or having the language capabilities to work with them ergonomically.

Re: Go 1.18

#552

Post by morelisp »

stouset wrote: post #160
philosopher1234 wrote: post #3

This is very exciting! 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 would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> 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. This is a needlessly dismissive perspective. Put another way, now that one of golang's most prominent deficiencies has been addressed, people will switch their focus to other areas of frustration. > Sometimes I think the core i…

None of your proposals truncate a Unicode string to the first 63 characters. Go and Rust are at least honest about this. Ruby lies about what you're indexing and makes you pay O(n) to do it. (And no, that's not the way you're "supposed to" truncate to a codepoint offset in Go, but it's also true that there's no function to do it in the standard library - in part because that's rarely what you really want to do and it would get abused to do such.)

> When you're handed a string you can generally assume it's been parsed and validated under that character set

But it might not have been. It's a weakass guarantee, the same Go gives you, except in Go it's UTF-8-or-garbage, vs. Ruby's could-be-anything-and-could-still-be-garbage.

Re: Go 1.18

#553

Post by jshen »

pie_flavor wrote: post #527
jshen wrote: post #402

Earlier quoted context omitted.

I’m not talking about generics specifically. I’ve been coding for decades. Go is by far the easiest language I’ve used when it comes to jumping into an arbitrary code base and making sense of it. Again I ask, why insist that go become the same as all the other languages when you can just use one of those? Why demand less diversity?

Which part of this is not generalizable to literally every conceivable complaint about a language whether it makes sense or not? Why would I want diversity between languages where you do have to copy-paste lots of boilerplate, and languages where you don't ? If there was a good, simple-in-the-Go-way solution to this problem other than generics, feel free to suggest it, but repeating 'why care about anything ever' is…

As I've said, this isn't about generics specifically. There are a whole lot of us who find Go code bases far easier to read and understand that most other languages. We believe there is a value to the language's simplicity, and we want to keep it that way. We've written Go for years, and haven't missed many of these features you want. In fact, we think there is a decent chance that Go code bases are easier to jump into and understand BECAUSE of it's simplicity.

You have many many choices that work the way you want. Go use them, why try to dictate to us that we can't have the choice we want? We disagree about the value of these things, and their trade-offs. That's what diversity is for, you have languages that work your way. Why insist that one of the few that doesn't has become like all the others?

Re: Go 1.18

#554

Post by jshen »

pjmlp wrote: post #526
jshen wrote: post #524

Earlier quoted context omitted.

So you want to diminish the diversity in programming languages because it’s an inconvenience to you personally. I respect the honesty.

Thanks, the same way that people in Go community see as inconvenience to learn how to write better code. The old ways of code generators are good enough.

I've been coding for decades. I've written large scale systems in functional languages. I was a believer, but after many years of experience, I didn't find it to add a whole lot of value. I didn't find that there were fewer bugs as promised, it wasn't faster to develop and ship features, and most importantly, it was hard to jump into other peoples code and make sense of it.

You might have a different opinion, that's fine, you have tons of languages that work the way you want. That's what diversity is for. Yet so many of you want to remove that diversity for a reason that I don't understand. There is no science that has proved which of us is right, so the best option in my opinion is to let diversity flourish. I can't understand why you all are against that.

Re: Go 1.18

#555

Post by jatone »

exdsq wrote: post #250
avl999 wrote: post #216

Earlier quoted context omitted.

Or an expectation of competence from developers and expecting them to consider tradeoffs of their design- in other words doing their damn jobs as opposed to the language baby sitting them away from tools they might use incorrectly.

There’s nothing wrong with a language being strict with what you can do to force good programming styles. An expectation of competence is nice if you can afford it, but it’s also nice to have languages that mean you don’t have to take that risk. It’s why I liked Go and why I disliked working in Haskell. Look at Lisp - large teams get tied in knots because of the freedom. Go was nice because it just stopped you doing…

having used rust that isn't a sane trade off. rust is a wonderful language but its orders of magnitude slower than go for development.

Re: Go 1.18

#556

Post by pipe_connector »

stouset wrote: post #547
pipe_connector wrote: post #537

Earlier quoted context omitted.

I think you overestimate my ability. I've spent > 10 years programming in languages that have features like this (take and select excluded I think? Or maybe they had different names?) and I've just never internalized functions that are generic like this. Usually what I end up doing is opening up a REPL or making a toy program so I can iteratively see what happens to the collection. This probably makes me a bad progra…

I think you underestimate your ability. As a programmer, you've already learned and internalized abstractions that are far more complicated than anything here. `select` is often aliased to `find_all` and that's what it does: finds all elements matching what's passed to it. `take` is sometimes aliased to `first`. Expanded ever so slightly: nums.first(20).find_all { |n| n.odd? }.reduce { |sum, n| sum + n } This reads:…

Perhaps it comes down to a difference in where we spend most of our time? I'll give you an example.

I once spent a full day debugging a problem that came down to the implementation details of .zip. The author had assumed that .zip would add extra null elements to the output array if the inputs didn't match in length, which is sadly not the behavior of our programming language. We determined this was the bug after breaking out the REPL and running line by line because it was hard for us to visualize exactly what was happening in functional methods like these (there were more around the .zip call). We ripped out the .zip and turned it into an explicit for loop because we wanted the behavior for the case of "these arrays are different length" to be extremely obvious to the reader. The author and myself probably learned that zip had this behavior at some point, but its terseness hid a ton of nuance in code review that we decided we cared about later on in a way that explicit looping did not.

So, I get that internalizing functions like this can reduce cognitive load in some cases and it's certainly shorter. However, I spend a large percentage of my time looking at code where small semantics like the above matter a great deal. What happens if the length of this array is less than 20? What is the default return value if there are no items: None or 0? When I loop over something, it's often extremely important -- something that operates on an absolute ton of elements, altering its behavior is a big change in business logic type of stuff. Too often we've run into edge cases like the above that just flat out need to be explicit.

I think if I were working on smaller teams/codebases with more homogeneous experience levels I might feel differently. On my current team I will take the tradeoff of "the average function takes a bit longer to parse" if it means that everyone can reason about any given bit of code without trouble. We're trying to minimize how bad things can be, e.g. never have multiple programmers sitting around a computer trying to figure out what the bug is in a nested list comprehension with gratuitous use of function chaining. We use Go over other languages nowadays because we believe that for our team, explicitness results in the lowest cognitive burden on a global level. I think it's fine that other languages make other choices -- sometimes I program in Haskell for fun -- but if I come back to something I wrote long ago, I always break out the manual to remind myself what exactly certain expressions do.

Re: Go 1.18

#557

Post by pipe_connector »

stouset wrote: post #347
azornathogron wrote: post #345

Earlier quoted context omitted.

Two things... I think (?) - declaring `adminUsernames` and then using `userNames` (but I assume that's not what you're talking about because that won't even compile) - you're making an array with its length N instead of length 0 capacity N (I totally agree with your point, I just like looking for bugs)

Yep, the `userNames` thing was my own dumb mistake while editing in a comment box and was not intended as a reflection of the language. The capacity/length issue is the actual bug I was intending to include. But... also it's a mistake that's not even possible in the Ruby example due to not having to handle the "irrelevant" internal details of appending to the array, so maybe there's a point to it after all.

I grant you that the API for capacity and length when creating a slice in Go is bad because of this exact mistake, and I believe a few of the Go authors said they regretted it and would like to change it. However, it's odd to classify this as an advantage of Ruby, because pre-allocating memory for a large slice like this has been one of the biggest single performance advantages when we moved from Python to Go, and it's effectively a one line change. For known-to-be-tiny slices we don't even bother.

Re: Go 1.18

#558

Post by pie_flavor »

jshen wrote: post #553
pie_flavor wrote: post #527

Earlier quoted context omitted.

Which part of this is not generalizable to literally every conceivable complaint about a language whether it makes sense or not? Why would I want diversity between languages where you do have to copy-paste lots of boilerplate, and languages where you don't ? If there was a good, simple-in-the-Go-way solution to this problem other than generics, feel free to suggest it, but repeating 'why care about anything ever' is…

As I've said, this isn't about generics specifically. There are a whole lot of us who find Go code bases far easier to read and understand that most other languages. We believe there is a value to the language's simplicity, and we want to keep it that way. We've written Go for years, and haven't missed many of these features you want. In fact, we think there is a decent chance that Go code bases are easier to jump in…

You are posting a criticism of the feature, in response to a comment that is an answer to that criticism.

If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.

But just because you don't interact with a problem doesn't mean it doesn't exist, and the problem has historically been solved with dynamic downcasting, code generation, or copy-pasting, all of which result in codebases far harder to read and understand than most other languages. For these problems, you are not trading off generic code vs simple code, you are trading off generic code vs incomprehensible code. It is great that you have never needed a tree-map instead of a hash-map, but many have.

Go's simplicity is in many ways it being the spiritual successor to C, and even C has generics nowadays because they are an enormous value add.

Re: Go 1.18

#559

Post by alophawen »

andrewjf wrote: post #517
alophawen wrote: post #377

Earlier quoted context omitted.

(Assuming we are discussing the Option type from rust) Some(null) is not a valid result. The whole point of the Option type is to let you know: a) we got a result: Some(value) b) there is no result: None

It's trivial to store a null pointer in an Option::Some(). struct Foo; fn main() { let option_with_null: Option = Some(std::ptr::null()); dbg!(option_with_null); dbg!(option_with_null.is_none()); } Output: [src/main.rs:6] option_with_null = Some( 0x0000000000000000, ) [src/main.rs:7] option_with_null.is_none() = false https://play.rust-lang.org/?version=stable&mode=debug&editio...

As the creator of the function, you should try to adhere to the conventions and not try to break them.

Re: Go 1.18

#560

Post by pie_flavor »

jchw wrote: post #548
pie_flavor wrote: post #529

Earlier quoted context omitted.

I really, really try to ignore my own impulses on Go simplicity, because I don't understand it and lots of people who say they do understand it are prone to saying the same things which are different from the things I say, so there is clearly an Outside View to take. But I cannot help but view this as a case of special pleading. You have this great spiritual successor to classic C, and then there's also channels tack…

I don’t think Go channels really panned out well. However, I do think that Go’s thread model and scheduler have turned out great. I think channels could’ve made sense, but they wound up being both more complicated to use and less performant than I think was hoped for. However… channels aren’t a solution for iterators. They’re a solution for communicating between threads. Go, like C, simply doesn’t have anything geare…

Sum types are indeed great. That's why they're in Go 1.18. Pipe syntax and all.
Post reply on HN