7 ms·

Go is missing 2 things that I care about: 1) proper dependencies management system (the new module system might address this) and 2) gener... nah, just kiddin

by vesak 8y ago

Go is missing 2 things that I care about: 1) proper dependencies management system (the new module system might address this) and 2) gener... nah, just kidding -- actually null protection. I don't want to see another segfault or null pointer failure ever again. If it had these two features, I'd probably stop toying around with Rust and Crystal and just use Go. Unfortunately, 2) is probably impossible without seriously breaking old code, and they're not gonna break old code.

invest_gc11 8y ago
Why not try Kotlin. I don't understand why people use Rust for non System programming
regecks 8y ago
When have you seen segfaults in Go? I think 100% of the time, it is either a bug in the Go runtime, or you're using cgo (which is not really Go anymore). A language as simple as Go without nilable types would be great, though.
- pknopf 8y ago
  nil pointers exist in Go. It is common to run into them, especially when using "&".
- jdoliner 8y ago
  C programs tend to call nil-pointer panics "segfaults" even though go runtime doesn't print the word "segfault" anywhere. I'm guilty of the same thing.
  - regecks 8y ago
    Well, I think they're worth separating. I've seen a raw SIGSEGV in Go due to a runtime bug years ago, and the only safe outcome is process termination. On the other hand, dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. For common cases like HTTP and RPC handlers, no big deal, safely recoverable. Edit: on second thought, forget that. I agree that it's not a good thing (not safe) for recovery from goroutine crash to be possible.
    - vesak 8y ago
      > dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. Yeah, these are exactly the things I don't want to see: production log messages saying that something or other referred to a nil pointer and thus crashed some process. I don't think they belong to modern programming. Sure, segfaults are even worse since you don't even get the log message, but I still kinda lump both of these problems together as "errors from the 1900s that shouldn't happen anymore".
      - matthewmacleod 8y ago
        Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or error handling issue somewhere in your code and I find it weird that there's no support for a known technique for eliminating them.
        SamReidHughes 8y ago
        You can't actually accomplish that without making the language really complicated.
        vesak 8y ago
        Are Crystal, Kotlin and Swift really complicated? Is Rust's complications due to null protections or something else?
        SamReidHughes 8y ago
        Are you joking? They're all way more complicated than Go.
        vesak 8y ago
        Okay, let's pretend that's true. Are the complications due to null protection being there, or are they due some other things?
sheeshkebab 8y ago
Couldn’t agree more. Nil exception handling is horrible in go. The thing wasn’t designed to handle pointers and blows up left and right once someone tries to use them (or untyped objects). Dependency management is a total mess.
kellengreen 8y ago
Try out dep for dependency management. It's still young, but is getting better all the time.
- cube2222 8y ago
  The new official way of package management is vGo. Dep was an experiment which was suucceded by vGo, which in 1.11 is officialy (beta) included in the Go toolkit and will be the main way in Go 1.12. There's a great blog post series about it (though it's dense, plan to spend a few hours to read it all: https://research.swtch.com/vgo https://research.swtch.com/vgo)
DelightOne 8y ago
Why isn't Go implementing Optionals like Swift with guard let, if let, etc.?
- apta 8y ago
  Because it would need generics
  - ainar-g 8y ago
    No it wouldn't. There are already built-in generic types like map[K]V and slices. If the Go Team wanted, they could easily add built-ins like option[T] and result[T]. But in Go 1.0 they would stand out like a sore thumb, because the stdlib wouldn't use them. Maybe for Go 2.0.
    - tmaly 8y ago
      I would like to see a set library as part of standard library if they are going to do something more on this front.
      - zlynx 8y ago
        It seems to me that's just a map[set_key]bool
        masklinn 8y ago
        1. because you can't build opaque abstractions in Go, you have to wonder if there's a difference between having a true and a false value mapped to a key 2. because sets are significantly less useful without set-operations (intersections, unions, differences) and since go does not have user-defined generics you can't build a generic version of those ( 3. because it wastes 1 byte per item (according to the comments in bmap, buckets are implemented column-major `map[K] struct{}` would fix 3 and the second half of 1 (struct{} is a zero-sized singleton) but is somewhat less ergonomic so the impact of what's left of 1 is worse, and it doesn't solve 2 at all
xiaq 8y ago
Re. "null protection": It is kind of hard to fit non-nullable pointers into Go. The fact that non-nullable pointers do not have a natural initial value and always require an initial assignment is especially problematic in Go's struct semantics, because first of all, struct creation is supposed to be light-weight. If a struct contains pointers, the cheapest way to initialize it would be to assign them nil. But the more interestingly problem is how Go's struct "constructor" works. It is very low-level, you just assign some fields in a struct like &SomeStruct{X: 1, Y: "y"}; you can also assign all fields, in which case you can omit the keys, like &SomeStruct{1, "y"}. let's call those the key-value variant and positional variant of "free-form constructor". You can provide a "function constructor", which is simply a function that returns SomeStruct or * SomeStruct, but it is not required, nor can you forbid the free-form constructor. This is in stark contrast with, say, Java, where the function constructor is both required and the only allowed form. That makes it easy to make sure that non-nullable pointer fields are always initialized, because the compiler only needs to check the constructors. In Go it is much harder. You can make the free-form constructor check that non-nullable pointer fields get initial values, but then Go has this promise that the author of a struct can add new fields without breaking users of the free-form constructor, as long as they are using the key-value variant instead of the positional variant. So if a struct was originally: type SomeStruct { X int Y string } A user can make an instance with &SomeStruct{X: 1, Y: "y"}. If the author of the struct decides to add a new field, the code should still work. That should be the case even if the new field is a non-nullable pointer field. This now defeats the purpose of non-nullable pointer fields.
- nicoburns 8y ago
  > but then Go has this promise that the author of a struct can add new fields without breaking users of the free-form constructor, as long as they are using the key-value variant instead of the positional varian This is the bit that would need to change. And actually, doing so would provide the same benefits that non-nullable types do in other contexts. Say a Go library user is using a struct in 5 places, and the library author adds a new field. The user updates the free-form constructor to properly initialise the new field in 4 of those 5 places, but overlooks the 5th. As it stands, that will fail silently if the program is relying on using a non-null value somewhere else in the code. If upgrading the library caused a compile time error then that bug would have been caught. Rust also has "free-form constructors" like Go, and this is the approach it takes: you must provide a value for all fields.
yawn 8y ago
Totally agree on 2. "Learn a language a year" they said. "Learning new languages expands your thinking" they said. What they didn't say was that once you use ADTs to model data, Maybe/Option types to avoid null, exhaustive pattern matching, etc, you want those features in all the languages you use. I don't ask for much. I just want a GC'd Rust (one of the few modern languages that has option types in the std lib) or an F# that isn't tied to the .NET standard lib. Please?
- mastax 8y ago
  OCaml? ReasonML?
- masklinn 8y ago
  > F# that isn't tied to the .NET standard lib. Please? F# is basically OCaml on .Net, so… OCaml?
  - mlevental 8y ago
    I just made this choice (learn fsharp or oval). initially I was leaning ocaml for the same reason as gp but then I tried a simple scraper (make a get request and parse the HTML) and couldn't get it to compile because of cabal hell. well obviously not cabal hell but dependency hell where I had to keep changing installing and uninstalling versions of cohttp and the compiler. in the end I said screw it and installed all the .net/mono/f# stuff and it worked flawlessly the first time. I don't understand how language developers don't prioritize package management in 2018 - it's simply a deal breaker when other languages get it right. yes I realize ocaml and haksell have a different perspective on dependency resolution than other languages but then they should ensure that it works (and yes I also realize dependency resolution is np complete).
    - xfer 8y ago
      It can happen if you happen to install a recent compiler and that package manager has not done the work(probably changing the bounds) to update in opam repo. > I don't understand how language developers don't prioritize package management in 2018 As you already know, Ocaml already has a decent package manager opam, this same situation will happen in any language where the packages get stale(e.g. in rust you installed something used nightly features that didn't make it mainstream).
axaxs 8y ago
Agreed with 2. I honestly don't understand why the compiler doesn't do analysis to catch such cases. As someone who doesn't work on these things, perhaps it's too intensive? I've made silly nil pointer mistakes before and wondered why the compiler didn't say 'hey dummy, look what you did here'.

by vesak 8y ago

invest_gc11 8y ago

Why not try Kotlin. I don't understand why people use Rust for non System programming

regecks 8y ago

When have you seen segfaults in Go? I think 100% of the time, it is either a bug in the Go runtime, or you're using cgo (which is not really Go anymore). A language as simple as Go without nilable types would be great, though.

pknopf 8y ago
nil pointers exist in Go. It is common to run into them, especially when using "&".
jdoliner 8y ago
C programs tend to call nil-pointer panics "segfaults" even though go runtime doesn't print the word "segfault" anywhere. I'm guilty of the same thing.
- regecks 8y ago
  Well, I think they're worth separating. I've seen a raw SIGSEGV in Go due to a runtime bug years ago, and the only safe outcome is process termination. On the other hand, dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. For common cases like HTTP and RPC handlers, no big deal, safely recoverable. Edit: on second thought, forget that. I agree that it's not a good thing (not safe) for recovery from goroutine crash to be possible.
  - vesak 8y ago
    > dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. Yeah, these are exactly the things I don't want to see: production log messages saying that something or other referred to a nil pointer and thus crashed some process. I don't think they belong to modern programming. Sure, segfaults are even worse since you don't even get the log message, but I still kinda lump both of these problems together as "errors from the 1900s that shouldn't happen anymore".
    - matthewmacleod 8y ago
      Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or error handling issue somewhere in your code and I find it weird that there's no support for a known technique for eliminating them.
      - SamReidHughes 8y ago
        You can't actually accomplish that without making the language really complicated.
        vesak 8y ago
        Are Crystal, Kotlin and Swift really complicated? Is Rust's complications due to null protections or something else?
        SamReidHughes 8y ago
        Are you joking? They're all way more complicated than Go.
        vesak 8y ago
        Okay, let's pretend that's true. Are the complications due to null protection being there, or are they due some other things?

sheeshkebab 8y ago

Couldn’t agree more. Nil exception handling is horrible in go. The thing wasn’t designed to handle pointers and blows up left and right once someone tries to use them (or untyped objects). Dependency management is a total mess.

kellengreen 8y ago

Try out dep for dependency management. It's still young, but is getting better all the time.

cube2222 8y ago
The new official way of package management is vGo. Dep was an experiment which was suucceded by vGo, which in 1.11 is officialy (beta) included in the Go toolkit and will be the main way in Go 1.12. There's a great blog post series about it (though it's dense, plan to spend a few hours to read it all: https://research.swtch.com/vgo https://research.swtch.com/vgo)

DelightOne 8y ago

Why isn't Go implementing Optionals like Swift with guard let, if let, etc.?

apta 8y ago
Because it would need generics
- ainar-g 8y ago
  No it wouldn't. There are already built-in generic types like map[K]V and slices. If the Go Team wanted, they could easily add built-ins like option[T] and result[T]. But in Go 1.0 they would stand out like a sore thumb, because the stdlib wouldn't use them. Maybe for Go 2.0.
  - tmaly 8y ago
    I would like to see a set library as part of standard library if they are going to do something more on this front.
    - zlynx 8y ago
      It seems to me that's just a map[set_key]bool
      - masklinn 8y ago
        1. because you can't build opaque abstractions in Go, you have to wonder if there's a difference between having a true and a false value mapped to a key 2. because sets are significantly less useful without set-operations (intersections, unions, differences) and since go does not have user-defined generics you can't build a generic version of those ( 3. because it wastes 1 byte per item (according to the comments in bmap, buckets are implemented column-major `map[K] struct{}` would fix 3 and the second half of 1 (struct{} is a zero-sized singleton) but is somewhat less ergonomic so the impact of what's left of 1 is worse, and it doesn't solve 2 at all

xiaq 8y ago

Re. "null protection": It is kind of hard to fit non-nullable pointers into Go. The fact that non-nullable pointers do not have a natural initial value and always require an initial assignment is especially problematic in Go's struct semantics, because first of all, struct creation is supposed to be light-weight. If a struct contains pointers, the cheapest way to initialize it would be to assign them nil. But the more interestingly problem is how Go's struct "constructor" works. It is very low-level, you just assign some fields in a struct like &SomeStruct{X: 1, Y: "y"}; you can also assign all fields, in which case you can omit the keys, like &SomeStruct{1, "y"}. let's call those the key-value variant and positional variant of "free-form constructor". You can provide a "function constructor", which is simply a function that returns SomeStruct or * SomeStruct, but it is not required, nor can you forbid the free-form constructor. This is in stark contrast with, say, Java, where the function constructor is both required and the only allowed form. That makes it easy to make sure that non-nullable pointer fields are always initialized, because the compiler only needs to check the constructors. In Go it is much harder. You can make the free-form constructor check that non-nullable pointer fields get initial values, but then Go has this promise that the author of a struct can add new fields without breaking users of the free-form constructor, as long as they are using the key-value variant instead of the positional variant. So if a struct was originally: type SomeStruct { X int Y string } A user can make an instance with &SomeStruct{X: 1, Y: "y"}. If the author of the struct decides to add a new field, the code should still work. That should be the case even if the new field is a non-nullable pointer field. This now defeats the purpose of non-nullable pointer fields.

nicoburns 8y ago
> but then Go has this promise that the author of a struct can add new fields without breaking users of the free-form constructor, as long as they are using the key-value variant instead of the positional varian This is the bit that would need to change. And actually, doing so would provide the same benefits that non-nullable types do in other contexts. Say a Go library user is using a struct in 5 places, and the library author adds a new field. The user updates the free-form constructor to properly initialise the new field in 4 of those 5 places, but overlooks the 5th. As it stands, that will fail silently if the program is relying on using a non-null value somewhere else in the code. If upgrading the library caused a compile time error then that bug would have been caught. Rust also has "free-form constructors" like Go, and this is the approach it takes: you must provide a value for all fields.

yawn 8y ago

Totally agree on 2. "Learn a language a year" they said. "Learning new languages expands your thinking" they said. What they didn't say was that once you use ADTs to model data, Maybe/Option types to avoid null, exhaustive pattern matching, etc, you want those features in all the languages you use. I don't ask for much. I just want a GC'd Rust (one of the few modern languages that has option types in the std lib) or an F# that isn't tied to the .NET standard lib. Please?

mastax 8y ago
OCaml? ReasonML?
masklinn 8y ago
> F# that isn't tied to the .NET standard lib. Please? F# is basically OCaml on .Net, so… OCaml?
- mlevental 8y ago
  I just made this choice (learn fsharp or oval). initially I was leaning ocaml for the same reason as gp but then I tried a simple scraper (make a get request and parse the HTML) and couldn't get it to compile because of cabal hell. well obviously not cabal hell but dependency hell where I had to keep changing installing and uninstalling versions of cohttp and the compiler. in the end I said screw it and installed all the .net/mono/f# stuff and it worked flawlessly the first time. I don't understand how language developers don't prioritize package management in 2018 - it's simply a deal breaker when other languages get it right. yes I realize ocaml and haksell have a different perspective on dependency resolution than other languages but then they should ensure that it works (and yes I also realize dependency resolution is np complete).
  - xfer 8y ago
    It can happen if you happen to install a recent compiler and that package manager has not done the work(probably changing the bounds) to update in opam repo. > I don't understand how language developers don't prioritize package management in 2018 As you already know, Ocaml already has a decent package manager opam, this same situation will happen in any language where the packages get stale(e.g. in rust you installed something used nightly features that didn't make it mainstream).

axaxs 8y ago

Agreed with 2. I honestly don't understand why the compiler doesn't do analysis to catch such cases. As someone who doesn't work on these things, perhaps it's too intensive? I've made silly nil pointer mistakes before and wondered why the compiler didn't say 'hey dummy, look what you did here'.