Nil safety(the lack of it) is really the most frustrating part of GO. It would be so nice to have Option type from Rust instead of using stupid pointers in structs. Using pointers in a DTO is also semantically wrong. If I want to point to a User in my DTO, I would use `userId` field instead, not a pointer in a dynamic memory! If a User field is optional, I prefer to mark it as optional. So I'm using a struct for every nullable field: {value T, isNil bool}. But in JSON some field could also be undefined (not present in the DTO at wire), so for those cases I have to add `isUndefined bool` parameter to distinguish missing fields. The problem with this approach - it is not standardised. So most of the projects and libs are not using this approach and not compatible with it. And even when one is using it, the interface is most like incompatible anyways. So you can't reuse functions, structs and entire modules simply because of this stupid nil wrapper you had to invent yourself. Such a wonderful experience. This is the biggest downside of Go for me.
Interesting nuance with Go interface objects. I haven’t done anything overly sophisticated with Go, but I had never thought to try to return a nil-initialized error object. I always explicitly returned nil for happy path errors and declared errors as necessary.
I haven’t had this happen in go but I’ve been doing go now for only 3.5 months 😂But I also haven’t had this happen in C and C++ code basis for ages. I always check my pointers. The last null error I had was literally 10 years ago and even that was a freak accident and that was a pointer read after a free and set to null 😅It so rare it happens to me that I still remember what it caused. I guess this is because these days people don’t learn to write in C, C++ and assembly anymore in school. We would run into this most common error and we’d be drilled by the teachers: “always check your input and pointers!” Always be explicit!!!
Go lack of option type will always be a turn of for me, if i have something it should always be the thing, if i have an option, its either the thing or not the thing and i have to open the box up to see if there is a thing or not. Prevents so many silly errors
thanks, i read this a while back and was hoping someone could explain it clearly as i have recently started learning golang but mainly use json so far so no dealing with pointers
@@MelkeyDev most solutions i have read just say to use the sql lib built in nullable types. is that a good solution? for more general purpose cases, is it worth making our own nullable types?
Gleam does an excellent job at that, forces pattern matching by removing if statements and only having case statements so you handle all cases Since it's built on erlang it uses erlang processes which are sequential in how it receives messages which guarantees you aren't accessing a variable as it's being modified (I know golang has mutex, but this is safer). If you want to handle a message concurrently you just make a process to handle the user in, processes are very efficient in sending messages between one another too
Put that aside that they made a mistake in the code, but for a service that costs so much they should have had some kind of testing which would have caught this before deploying to production. Sounds bit like they were really asking for it.
This feels less like a Golang problem and more like a DB and more general null problem. I see similar issues come up between different databases and languages. If you have a DB that allows null values, you need to understand how to handle those, and how to handle transferring them out of it. One example I've seen recently is .NET/C#'s handling of nulls can cause issues with serializing JSON because some serializers will ignore a field with a value of null by default instead of creating a field with a null value. TLDR understand how your systems handle nulls. Other fun things I've seen in the wild is joins on nulls where null was the lack of a match from a previous join, and an explicit null on the other resulting in data set to null joining with anything that didn't match.
Just for some added reference. I've worked on the programming and ETL side. Nulls suck and people just don't understand what they mean or how to use them properly in data. I've seen the storage of NULL, "null", "NULL", "", and more sometimes within the same table/dataset to refer to no value.
Awesome take man. Thanks for leaving a comment, and i absolutely agree. At the end of the day, nulls have be to handled and its up to the engineer to do this
Hot take, but I am not automatically against nil/null in a language because some guy made a quote back in the 90's that gets parroted by every programmer since. Not having a null value adds complexity to a language and will inevitably dictate much of its syntax. I don't need the safety of Rust for everything, and neither do I want the looseness of Lua/Ruby for everything at the other extreme, but there is a time and place for each. It is simply one of the tradeoffs to keep in mind when selecting the appropriate language to solve the task at hand.
What complexity? The whole point is that the syntax should be different, that's not a bad thing. Programmers get used to a style and tend to get biased in favor of what they're used to.
@@lightfeather9953 I hope that you are joking, but literally look at any two pieces of equivalent code in languages with/without null, compare the compile times of each, and then actually understand how "no null" is achieved by the compiler/runtime. I can understand arguing the merits of each, but it is rather silly to deny that there is way more complexity to languages without it. Spend an afternoon making a toy language, then do it again without null and tell me which was more difficult.
@@benkogan1579 I think you may be confusing "statically-typed" with "memory safety". These are very different things. There are tons of statically-typed languages, only a few of which that are considered memory-safe, meaning the language itself does not allow for dereferencing null pointers, accessing freed or out-of-bounds memory, etc.
Nil safety(the lack of it) is really the most frustrating part of GO.
It would be so nice to have Option type from Rust instead of using stupid pointers in structs.
Using pointers in a DTO is also semantically wrong. If I want to point to a User in my DTO, I would use `userId` field instead, not a pointer in a dynamic memory! If a User field is optional, I prefer to mark it as optional. So I'm using a struct for every nullable field: {value T, isNil bool}. But in JSON some field could also be undefined (not present in the DTO at wire), so for those cases I have to add `isUndefined bool` parameter to distinguish missing fields. The problem with this approach - it is not standardised. So most of the projects and libs are not using this approach and not compatible with it. And even when one is using it, the interface is most like incompatible anyways. So you can't reuse functions, structs and entire modules simply because of this stupid nil wrapper you had to invent yourself.
Such a wonderful experience. This is the biggest downside of Go for me.
The Go footgun of all footguns
The idea that a service should crash on error is an archaic idea.
Interesting nuance with Go interface objects. I haven’t done anything overly sophisticated with Go, but I had never thought to try to return a nil-initialized error object. I always explicitly returned nil for happy path errors and declared errors as necessary.
I haven’t had this happen in go but I’ve been doing go now for only 3.5 months 😂But I also haven’t had this happen in C and C++ code basis for ages. I always check my pointers. The last null error I had was literally 10 years ago and even that was a freak accident and that was a pointer read after a free and set to null 😅It so rare it happens to me that I still remember what it caused.
I guess this is because these days people don’t learn to write in C, C++ and assembly anymore in school. We would run into this most common error and we’d be drilled by the teachers: “always check your input and pointers!” Always be explicit!!!
I wasn't aware of this behaviour, it's an absolute nasty design mistake imo
Could be a COSTLY one
Great video once again Melkey.
Best Go content
Go lack of option type will always be a turn of for me, if i have something it should always be the thing, if i have an option, its either the thing or not the thing and i have to open the box up to see if there is a thing or not. Prevents so many silly errors
Confirmed. I’ve made this mistake so many times 😂💀
Its a classic one for sure lol
I usually just check if it's not nil do stuff.
just solved a billion dollar mistake.
thanks, i read this a while back and was hoping someone could explain it clearly as i have recently started learning golang but mainly use json so far so no dealing with pointers
Hopefully it makes some more sense now!
@@MelkeyDev most solutions i have read just say to use the sql lib built in nullable types. is that a good solution? for more general purpose cases, is it worth making our own nullable types?
I just want go with pattern matching and option types.
me too
Elixirs pattern matching has really pulled me away from go
Gleam does an excellent job at that, forces pattern matching by removing if statements and only having case statements so you handle all cases
Since it's built on erlang it uses erlang processes which are sequential in how it receives messages which guarantees you aren't accessing a variable as it's being modified (I know golang has mutex, but this is safer). If you want to handle a message concurrently you just make a process to handle the user in, processes are very efficient in sending messages between one another too
Put that aside that they made a mistake in the code, but for a service that costs so much they should have had some kind of testing which would have caught this before deploying to production. Sounds bit like they were really asking for it.
Yeah - that was also my take.
Like it seems this could have easily been caught early on
This feels less like a Golang problem and more like a DB and more general null problem. I see similar issues come up between different databases and languages. If you have a DB that allows null values, you need to understand how to handle those, and how to handle transferring them out of it. One example I've seen recently is .NET/C#'s handling of nulls can cause issues with serializing JSON because some serializers will ignore a field with a value of null by default instead of creating a field with a null value. TLDR understand how your systems handle nulls. Other fun things I've seen in the wild is joins on nulls where null was the lack of a match from a previous join, and an explicit null on the other resulting in data set to null joining with anything that didn't match.
Just for some added reference. I've worked on the programming and ETL side. Nulls suck and people just don't understand what they mean or how to use them properly in data. I've seen the storage of NULL, "null", "NULL", "", and more sometimes within the same table/dataset to refer to no value.
Awesome take man.
Thanks for leaving a comment, and i absolutely agree. At the end of the day, nulls have be to handled and its up to the engineer to do this
Hot take, but I am not automatically against nil/null in a language because some guy made a quote back in the 90's that gets parroted by every programmer since. Not having a null value adds complexity to a language and will inevitably dictate much of its syntax. I don't need the safety of Rust for everything, and neither do I want the looseness of Lua/Ruby for everything at the other extreme, but there is a time and place for each. It is simply one of the tradeoffs to keep in mind when selecting the appropriate language to solve the task at hand.
What complexity? The whole point is that the syntax should be different, that's not a bad thing.
Programmers get used to a style and tend to get biased in favor of what they're used to.
@@lightfeather9953 I hope that you are joking, but literally look at any two pieces of equivalent code in languages with/without null, compare the compile times of each, and then actually understand how "no null" is achieved by the compiler/runtime. I can understand arguing the merits of each, but it is rather silly to deny that there is way more complexity to languages without it. Spend an afternoon making a toy language, then do it again without null and tell me which was more difficult.
You can have null in your language and make it safe. Typescript for example.
@@benkogan1579 I think you may be confusing "statically-typed" with "memory safety". These are very different things.
There are tons of statically-typed languages, only a few of which that are considered memory-safe, meaning the language itself does not allow for dereferencing null pointers, accessing freed or out-of-bounds memory, etc.
@@ForeverZer0 no, I mean safety against null pointer exceptions. Static typing is also very important, but it doesn't imply null safety.
first like first view first comment
Lol I am here too
Legend!
Just see how dart handles null, and you will realize what a totally preventable, dumpster fire is golang nil
screw nil
thats what im saying
very very strange code. I have never seen such code in the projects.
eh - i have seen it a few times.
Happens alot with non-instantiated maps
skill issue, use make
Why is your forehead much bigger on Twitter?
Lmfaoooo
Sorry but Rust and F# have must better null handling :P
I stopped the video, when he says "with real users". :3
Why