The intention of the password entry dots isn’t to prevent folks with unrestricted physical access to the machine from exfiltrating information, it’s to stop it from appearing in screenshares and casual “over the shoulder” observations.
Honestly I’m surprised they even acknowledged that as a bug, given there are many ways to get a whole lot more info than what you demonstrated, for instance the builtin “eye” button that is purpose built to reveal the full password to anyone with physical access to the machine wishing to see it.
We’ll need to fire all the industry plants in the EPA before we can legally have a small (fuel efficient) truck here in US. Our emissions laws were written by Big Truck.
This isn't argumentative. Do you have anything i can look at to see why the EPA et al would not want a light, cheap, fuel efficient truck?
is it capture by Ford and GM? Are there even trucks as small as the Nissans that had the 2400 motors (or 2600)? I live near enough texas that every truck is way too big, so i don't see many new, small trucks. A lot of people have the old, nearly all metal, small trucks.
Right, because the EPA has made them illegal in favor of larger, less fuel efficient trucks. This paper covers the topic well^, you can also see many examples searching online for “EPA Small Truck Footprint”.
Hey, thanks for replying! I read the title of that paper and immediately knew what it was going to prove. I have a recollection about this from 10 years ago, but for some reason it didn't comport with "it's the EPA's fault we can't have nice things"
you'd think the https://www.nhtsa.gov/ would have something to say about regulations encouraging increased "box height" or grille height; which results in worse outcomes in nearly all accidents (could be all, but i don't feel comfortable asserting that.)
The fact that Go is considered a “modern” language and nil pointer exceptions are downright common blows my mind every day. Is there a static checker config that folks use to reduce this risk? Because coming from a TS background it’s legitimately bizarre to me that at $COMP insufficient nil pointer checking regularly causes major production outages.
Does it regularly cause major production outages? I’d love to see some data to back that claim because I’ve got Go services with uptimes of literally years.
Also it might seem weird to you given Typescript is a completely different idiom and doesn’t even have pointers to begin with.
That all said, I’m not going to defend the nil pointer problem in Go. It is something that can be largely mitigated with a few relatively small changes to the language. Though I couldn’t see them being entirely backwards compatible.
The issue isn’t the services that stay up forever, it’s the ones subject to a huge amount of churn where maintainers lose context on what is or isn’t possibly nil, and get loose with their checks.
Edit, responded to pointer vs reference down thread.
The issue I’m addressing is your exaggerated verbiage which sounds like it’s a reasoned argument but is actually just biased nonsense.
I’m not disagreeing that nil pointers are an ugly sore for Go. What I’m arguing against is your claim that Go services are constantly failing in production because of that sore point.
The reason I make that argument is because:
- sore points are a problem for every programming language. designing a programming language is a constant trade off of concerns. so there will always be stuff that doesnt work well. And I know this as an author of a programming language myself.
- however if sore points prevent a language from being usable in a production context (assuming that’s its intended role), then that becomes an insurmountable problem.
Nil pointers aren’t an insurmountable problem for Go. They’re ugly and arguably a terrible design choice, but not an insurmountable problem. Which is why Go succeeds despite this sore spot.
Typescript has its own WTF moments too. Every language does.
Assume all pointers are non-nil and use a generic Option type to represent values that may or may not exist:
type Option[Value any] struct {
value Value
exists bool
}
func (o Option[Value]) Get() (Value, bool) {
return o.value, o.exists
}
So long as all such values use this type instead of abusing the nullability of pointers, you'll eliminate the problem of programmers forgetting to check for nil.
It's not without its issues though, the ecosystem does not use such a type and you need a little bit of discipline to stick with it.
But it's not that big of a deal if you're getting regular major outages...
You're replying to someone who is claiming to come from typescript where nullability must be expressly opted into and once opted into must be branched upon without use of a monad (isomorphism notwithstanding). Kotlin would be another example of that. Even with python type hints the same thing can be achieved or with Java and annotations. The problems in all of these cases is the boundaries between the languages where the nullability or lack thereof is often just assumed and not asserted upon.
There are language decisions other than options that can work, but they boil down to the same thing: force a branch before use. If go does not have this sort of secondary type system now, it won't be too long before someone sees the value.
> This applies to all languages with nil. The alternative being options (like ocaml)
It actually doesn't. Languages like Kotlin, C# and TypeScript special case null in the type system and allow you to specify whether or not a given type should include null or not.
Not entirely true - e.g. Kotlin has null safety built into its type system, and I find it much nicer than the option/optional approaches used in various other languages.
That’s not the same thing as a nil pointer though.
Go data types cannot be null but a pointer to a data type can be. And what a nil pointers is, is a valid type of pointer but which points to an invalid point or memory.
Typescript doesn’t have the same problem because it doesn’t have pointers.
Rust somewhat this problem with its borrow checker but it’s still entirely possible to create a nil pointers in Rust and without using ‘unsafe’, but admittedly it’s not by writing idiomatic Rust.
Go really should do more to prevent issues here but the real problem is around the creation of “objects” (since Go isn’t fully OOP) and how you can’t really create an image struct (nor even map) and have it default as empty. I’m sure the logic behind that is for performance, but why not expose the option of an uninitialised struct pointer behind ‘unsafe’ for those who are willing to accept that risk?
Nil pointers aren’t the same thing as optional types in python.
You can achieve the same thing as optional types in Go using ‘…any’ and the standard library has made use of that pattern since the very first release of Go.
Nil pointers in Go are a completely different problem and there isn’t really a direct comparison in dynamic languages like Python nor Typescript because they use references rather than pointers.
I don’t think there is a difference between go pointers and references in python. For normal pointers to structs at runtime I suspect the implementation is very similar. Maybe it’s different for typescript because the compiler can protect you from null references statically and I assume if you are using python types the python type checker can also protect you at compile time.
A nil pointer isn’t a type. It’s a pointer to a type and that type hasn’t been created. In short, it’s an initialisation problem rather than a type system problem.
Where “references” differ is you have to initialise the type to get a reference. In Python and Typescript, you don’t create naked pointers. You create structs then pass that reference in functions.
The problem with Go is that you can create those naked pointers and then you need to remember to create your struct and then point that pointer to the struct. And you’re sometimes you’re incentivised to write code this way because Gos garbage collector needs to do more work than if you create pointers adhoc after (like references). But you can use pointers like references if you wanted too.
So there isn’t really a direct comparison with languages like Python and Typescript because they don’t have the same primitive to begin with.
There are benefits to Gos approach: you get more control over memory usage as well as improved performance. But like any idiom, it comes with disadvantages too. And the reason Go panics is because the alternative is the risk of silent memory corruption, which is what a lot of other languages can suffer from with pointers. Though this isnt to say that there are also languages that do solve this problem in a much better way too. But they’re are also a completely different language to Python and Typescript again too.
So the comparisons to Python and Typescript simply don’t work for this type of problem.
Actually there is. In your first example you’re passing an object as a reference, and in your second example you’re creating an empty pointer with no object attached.
A better example will be:
foo := Foo{}
useFoo(&foo)
That go code would be functionally equivalent to your Typescript code and if everyone used pointers like references in Go, like the above code, then you wouldn’t have any nil pointer bugs.
Nil pointer bugs happen when you need to use pointers as pointers. (Shock horror!) And sometimes you do need a pointer with no object attached when solving specific problems are aren’t well suited for Typescript.
Python and Typescript doesn’t have pointers. Those languages made different trade offs so they lose performance and memory management controls as a result.
It’s no secret that Python needs to call FFIs to (for example) C++ code when performance and memory management concerns arise. Likewise with node too. In fact I’m in the process of debugging a 3rd party Rust library for Node that’s not handling pointers correctly and thus causing sporadic crashes of the node runtime. And that Rust library only exists in the first place because JavaScript doesn’t have primitives to write the required code natively in node at the performance required for scale.
Maybe WASM will be the saviour here. But it feels like we are now just piling on more abstractions between the code and CPU rather than trying to learn how to use our existing set of tools better.
No… I’m sorry I don’t have time to explain TS now. But that’s not what’s happening at all. What you’re proposing would be the equivalent of ‘var foo = new Foo()’. The default value in TS is undefined, which behaves generally isomorphically to nil.
I really really disliked working with undefined in Typescript. You might dislike the way Go throws an exception with nil pointers, but undefined types go too far the other way and can be a cause for subtle hard-to-find bugs if you’re not doing exactly the same kind of null checks.
That said, Im sure there are better ways of handling undefined types in Typescript than I was doing. I’m certainly not an expect in Javascript nor Typescript. Though a large part of that reason is because there are far far far too many design choices in those languages that really rub me the wrong way, so I usually limit my Javascript/Typescript usage the bare minimum I can get away with.
That all said, I will say I found Typescript to be a massive improvement over vanilla Javascript. It’s a pity we can’t just do away with JS completely and have TS run everywhere instead.
python does have pointers under the hood. objects are passed via pointers. i think the implementation is tagged values in order to support dynamic typing and passing non-pointer values efficiently. but if there was no object tagging the runtime would be very similar to go. both have objects passed around as pointers using some form of garbage collection to handle memory safety.
the optional static type checking in python gives you a stronger typing than what golang does because you don't have to type everything as (None | Foo) and presumably its a type error to perform Foo operations on a (None | Foo) type.
Honestly I’m surprised they even acknowledged that as a bug, given there are many ways to get a whole lot more info than what you demonstrated, for instance the builtin “eye” button that is purpose built to reveal the full password to anyone with physical access to the machine wishing to see it.