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

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

Post reply on HN
Print view View original

481–490 of 508 posts

Re: I Want Off Mr. Golang's Wild Ride

#481

Post by joshuamorton »

dilap wrote: post #480
joshuamorton wrote: post #479

Earlier quoted context omitted.

> So notice the lambda (i.e. what we are assigning to the variable 'closure') is now capturing v, not x, which is why it doesn't see the change we make to x, i.e., why it returns 2 instead of 4. Yes, but this goes back to the scoping issue: in python, lambdas (and functions in general) don't capture. The only way to close over something is to pass as an argument. So to get the lexical closure behavior that rust provi…

Run my examples, they work! Python absolutely has real closures...

Yes your digression example works, but it works equally well without a mutable ref. You need to mutate the thing in the callback (and to have the callback actually close over the ref) to require mutable ref semantics.

And yes, python closures don't capture environemtnal vars like rusts do. If you need them to capture env vars, you have to do what I did in the example.

Re: I Want Off Mr. Golang's Wild Ride

#482

Post by dilap »

joshuamorton wrote: post #481
dilap wrote: post #480

Earlier quoted context omitted.

Run my examples, they work! Python absolutely has real closures...

Yes your digression example works, but it works equally well without a mutable ref. You need to mutate the thing in the callback (and to have the callback actually close over the ref) to require mutable ref semantics. And yes, python closures don't capture environemtnal vars like rusts do. If you need them to capture env vars, you have to do what I did in the example.

I think our understandings are too far apart to converge in a HN thread. Nevertheless, it has been a pleasure!

Re: I Want Off Mr. Golang's Wild Ride

#484

Post by dwohnitmok »

pron wrote: post #474
dwohnitmok wrote: post #469

Earlier quoted context omitted.

I mean personally I happen to agree that Java's checked exceptions represent a reasonable experiment, although I think they suffer from low-level problems, namely the way they interact with lambdas, the way they're at odds with the community's interface-happy habits, and the self-inflicted tension between whether something should be checked or unchecked (should an out of bounds exception on a dynamically sized array…

There are many Java developers who like checked exceptions. True, there are issues about polymorphizing them (which is what you feel when you use them with lambdas), but they're solvable. As to file vs. array, I do see a fundamental difference. Whether the index is out of bounds or not is up to the program; whether the file exists is not.

There are many who do. There are many who don't and among those who don't they can have pretty strong opinions and be fairly influential (see e.g. Robert Martin's Clean Code). When I say controversial I don't mean that as a back-handed way of saying no one likes checked exceptions, I mean that to say there are large contingents on either side. Unfortunately that means practically speaking checked exceptions lose a lot of their power since you have to proactively rewrap and rethrow a lot of your underlying libraries since a lot of them eschew checked exceptions (e.g. big examples that can pervade entire codebases are Spring and Hibernate). That's not impossible to do (I've done it for personal projects before), but I've never had success in convincing coworkers to do it and you're at the mercy of the accuracy of the documentation (or just seeing it blow up enough times).

I was thinking of the fact that the array can be dynamically sized as not being up to the program, but it's certainly true you can ensure the array isn't out of bounds (just check the array length in a single-threaded context or lock and then check the array length in a multithreaded context) in a way that's not possible for files.

Perhaps a more blurry example is ParseException (checked) vs DateTimeParseException (unchecked). I'm pretty sure I know the reasoning behind it, which is that ParseException is thrown by methods that directly ingest user data whereas DateTimeParseException is presumably not and is probably meant mostly for hard-coded strings. But there doesn't seem to be any real distinction between the two cases; it seems reasonable enough to parse strings passed in by the user as datetimes.

When you solvable, I'm curious do you mean currently in Java or with future features? Because right now if I want to play nice with checked exceptions and lambdas I do an ugly thing of wrapping the exception in a RuntimeException, then catching the RuntimeException, downcasting the wrapped exception, and rethrowing it. It'd be nice to know if there's a better way than that to use.

Re: I Want Off Mr. Golang's Wild Ride

#485

Post by pron »

dwohnitmok wrote: post #484
pron wrote: post #474

Earlier quoted context omitted.

There are many Java developers who like checked exceptions. True, there are issues about polymorphizing them (which is what you feel when you use them with lambdas), but they're solvable. As to file vs. array, I do see a fundamental difference. Whether the index is out of bounds or not is up to the program; whether the file exists is not.

There are many who do. There are many who don't and among those who don't they can have pretty strong opinions and be fairly influential (see e.g. Robert Martin's Clean Code). When I say controversial I don't mean that as a back-handed way of saying no one likes checked exceptions, I mean that to say there are large contingents on either side. Unfortunately that means practically speaking checked exceptions lose a lo…

> When you [say] solvable, I'm curious do you mean currently in Java or with future features?

I meant future releases. That people can manage now make the problem not one of extreme urgency, so we're waiting until there's a solution we like.

Re: I Want Off Mr. Golang's Wild Ride

#486

Post by kragen »

ric2b wrote: post #462
strbean wrote: post #350

Earlier quoted context omitted.

That is quite a disingenuous quote... the actual content is: > Smalltalk, Perl, Ruby, Python, and Self are all "strongly typed" in the sense that typing errors are prevented at runtime and they do little implicit type conversion, but these languages make no use of static type checking: the compiler does not check or enforce type constraint rules. The term duck typing is now used to describe the dynamic typing paradig…

Do you have an example of Python doing implicit type conversion?

Python2 implicitly converts int to long and str to unicode:

    >>> 2**100
    1267650600228229401496703205376L
    >>> 'x' + u'y'
    u'xy'
All Pythons implicitly convert int to float and int or float to complex:

    >>> 1 + .5
    1.5
    >>> 2 * 3j
    6j
Methods like list.extend now, in recent versions of Python (since 2.1), accept arbitrary iterables rather than just lists; it's more debatable whether this is an “implicit type conversion” or not.

    >>> x = [3, 4]; x.extend((5, 6)); x
    [3, 4, 5, 6]

Re: I Want Off Mr. Golang's Wild Ride

#487

Post by api »

nif2ee wrote: post #423
physicles wrote: post #403

Earlier quoted context omitted.

I’ve written go full-time for the last 3.5 years and it still amazes me that by default the linter doesn’t at least warn about unused/uncaptured return error values.

Golang is such a joke of a language. The compiler won't even compile if there is an unused variable but won't warn you if there is an unchecked error! This language is meant to produce buggy incorrect code that can only be mitigated with writing excessive repetitive tests that have nothing to do with business logic itself. Golang is probably the biggest embarrassment of a modern programming language ever conceived. A…

This doesn't match my experience. Go apps tend to be extremely clean and reliable. It's of course possible to write crap code in Go, but you can write crap code in any language.

The unused variable thing is mildly annoying but fits with the cleanliness philosophy. Not checking errors is very easily detected by a LINTer such as the one built into the JetBrains GoLand IDE. It highlights failure to check errors and requires that you explicitly ignore the error return with something like "_, foo = bar.baz()".

Go is spectacularly productive when used properly. It's a very nice language.

Re: I Want Off Mr. Golang's Wild Ride

#488

Post by donatj »

sitzkrieg wrote: post #217

i wrote go professionally on a project for a year in a single very intense push, and i was burned by every single thing listed in the article. felt like uphill impedance mismatch the whole way. its nice to see it articulated well

> burned by every single thing listed in the article

Really? That seems absolutely bizarre to me, I've been writing it professionally for ~8 years now and never hit… any of these.

I mean I basically never interact with Windows on any level, but none of this has ever bit me.

Re: I Want Off Mr. Golang's Wild Ride

#489

Post by donatj »

I'm late to the show here, but I think the whole argument around filepaths needing to potentially be encoded before being presented to end users is a non-issue / how most languages I've worked in have handled it?

Does rust have some fancy handling? Sure? Is it syntactic sugar? Absolutely.

Maybe I've been working in Web too long, but encoding a value before handing it to the user seems second nature.

Re: I Want Off Mr. Golang's Wild Ride

#490

Post by dwohnitmok »

pron wrote: post #485
dwohnitmok wrote: post #484

Earlier quoted context omitted.

There are many who do. There are many who don't and among those who don't they can have pretty strong opinions and be fairly influential (see e.g. Robert Martin's Clean Code). When I say controversial I don't mean that as a back-handed way of saying no one likes checked exceptions, I mean that to say there are large contingents on either side. Unfortunately that means practically speaking checked exceptions lose a lo…

> When you [say] solvable, I'm curious do you mean currently in Java or with future features? I meant future releases. That people can manage now make the problem not one of extreme urgency, so we're waiting until there's a solution we like.

I suspect the proportion of Java programmers who like checked exceptions even in principle is decreasing over time unfortunately. So waiting might just result in it never being implemented :/ (although I guess that's probably a point in favor of waiting and never expending the wasted energy).

Just looking at the developments of past decade the community seems to be going hard for all exceptions being unchecked. Other statically typed JVM languages (Scala and Kotlin) advertise a lack of checked exceptions as an improvement over Java. Various Java plugins also tout the ability to remove checked exceptions. Manifold is particularly exuberant about it. Lombok offers this capability but is much more reserved about it, in no small part because the way it does so has pretty big downsides.

It's a bit sad (from my tiny personal perspective) because checked exceptions in Java have some ergonomic benefits over Result/Either types in other languages, but social dynamics are what they are.

Post reply on HN