81–88 of 88 posts
Earlier quoted context omitted.
Golang wasn't designed in the 1990s. I'm sorry you're bored and also annoyed in the possible universe where GoKart is your project. But it seems like this is a thing people want to talk about in a post about Go static analysis tooling. I don't see why you're trying to police HN conversations.
ML was designed in 1976.
Earlier quoted context omitted.
Right, but my point is, the code which would raise an error because the pointer is nil now raises an error because the Optional is not set. Is there really that much of a difference between those cases? I agree though that in an interface, Optional conveys a more explicit meaning than something pointer-like, which is always a good thing.
One has to be addressed at compile time and the other is a runtime error. Sure, you can address it wrong, but it's better than any reference anywhere being able to throw and in my experience really does cut down on application crashes.
I agree that it's nice to be explicit about optional stuff, but overall it's not been a huge deal in the projects I've been involved with.
Earlier quoted context omitted.
So you get an Optional which haven't been set instead of a nil pointer. What's better about that?
The type system knows about it and you're forced to check it
Earlier quoted context omitted.
The int example was a bit misguided, seeing as int is a primitive type in Go, different from pointer types. In Python, both are references. Basically, it's the difference between returning None from a function `def f() -> MyClass` in Python (which is type error) versus returning nil from `func f() &MyClass`, which is completely normal in Go. Having `Optional` in the function signature makes it explicit that one has t…
Optional parameters are a different thing. Yeah one workaround with the lack of optional parameters are to send nil values, but that's only going to work if the type you want optional is a nil'able type. Plus there's nothing stopping null values from being passed in Python code outside of optional parameters. My point is optional parameters are one reason why null values might creep in but not the cause nor reason fo…
For what it's worth, I completely disagree with your point. Optional arguments are there to set default values. Default values are so useful that even Rob Pike went through some efforts to use them in Go[0] after refusing to have them in the language.
[0] https://commandcenter.blogspot.com/2014/01/self-referential-...
Earlier quoted context omitted.
Optional parameters are a different thing. Yeah one workaround with the lack of optional parameters are to send nil values, but that's only going to work if the type you want optional is a nil'able type. Plus there's nothing stopping null values from being passed in Python code outside of optional parameters. My point is optional parameters are one reason why null values might creep in but not the cause nor reason fo…
You completely missed my point. Both my examples were when a function returned an object, and the caller has no idea whether that object ever null. It has nothing to do with parameters. For what it's worth, I completely disagree with your point. Optional arguments are there to set default values. Default values are so useful that even Rob Pike went through some efforts to use them in Go[0] after refusing to have them…
Type hints then? I don't write much Python so your point might have be clearer had you provided an example. But even in the case of type hints, it requires the developer to be diligent about setting those hints -- Python will happily plod along without them.
That's actually one of the reasons Python isn't my preferred language. I generally prefer something where typing a lot stricter. But this is personal preference and not a judgement on Python.
> For what it's worth, I completely disagree with your point. Optional arguments are there to set default values.
Default values can be set via constructors. Which then allows you to define far more explicit APIs. For example a method that explicitly sets the optional properties when needed might be called `CreateFooWithOnions()` and that method is aware that `.bar` is required to be set for "Onions". Other methods that know the defaults don't need to be set can leave those optional properties with the default. Thus the developer doesn't have to consider if an optional parameter is required in specific use cases, they instead call the method for their use case that is aware of what optionals are required for that use case.
I went through a phase of using optional parameters in the 90s and as I worked with more contributors, and other projects interfaced with my own APIs, I began to realise that optional parameters aren't self documenting. They're not descriptive. Instead it requires the user to understand what's happening under the hood of the API. So I learned from that and moved away from optional parameters.
> Default values are so useful that even Rob Pike went through some efforts to use them in Go[0] after refusing to have them in the language.
That link was from early 2014. Back then methods were only 6 months old (in Go). In fact Rob Pike (and others) tried a lot of things in the early days of Go. Some of those ideas sucked and were never heard from again. And some of the ideas worked and are now part of the core library.
Also the ironic thing here is while the API is called "Option" what Pike is doing is not creating optional parameters but actually creating objects with optional properties. Exactly like I've been describing as the better solution. Albeit Pike's work created a bunch of additional boilerplate and ultimately ends up with something that isn't any more readable. Which is likely why that idiom never made it to Go 1.3 (and beyond).
Earlier quoted context omitted.
Unless something drastically changed in Scala 3, there is nothing to protect you from null in Scala. In fact even Java is effectively safer thanks to all the null checking done by IntelliJ
Null is basically non-existent in idiomatic Scala. So technically you're right but besides calling Java libs there is only an infinitesimal small chance to get NPEs form Scala code. (Scala's NPE is the MatchException ;-)). For Scala 3 there are improvements. It's "null safe" as long as you opt-in (modulo Java libs, and of course doing stupid things like casting a null to some other type). https://docs.scala-lang.org/…
Earlier quoted context omitted.
Null is basically non-existent in idiomatic Scala. So technically you're right but besides calling Java libs there is only an infinitesimal small chance to get NPEs form Scala code. (Scala's NPE is the MatchException ;-)). For Scala 3 there are improvements. It's "null safe" as long as you opt-in (modulo Java libs, and of course doing stupid things like casting a null to some other type). https://docs.scala-lang.org/…
Idiomatic scala yes, but while on boarding engineers hit many cases, where they ended up returning null in places they shouldn’t.
When you have people without clue on the team no language will safe you. You can also crash Haskell programs by throwing exceptions or just using List.head…
Earlier quoted context omitted.
Idiomatic scala yes, but while on boarding engineers hit many cases, where they ended up returning null in places they shouldn’t.
So you actually complaining about people who don't know what they're doing? How is this related to Scala? When you have people without clue on the team no language will safe you. You can also crash Haskell programs by throwing exceptions or just using List.head…