5 ms·

Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function wil

by welder 5y ago

Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function will never return nil). That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors. https://wakatime.com/blog/48-go-desperately-needs-nil-safe-types https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...

jchw 5y ago
I’d kill for union types as well. … and pattern matching. Maybe just some extensions for `switch`. … and one of the `try` proposals. That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great together, though; it’d enable Go to do something like `Result` in Rust with few language-level changes. I even remain somewhat skeptical about generics, but I am hopeful.
- halfmatthalfcat 5y ago
  At that point, let's just write Scala.
  - noisy_boy 5y ago
    I think a language that doesn't focus much on backwards compatibility isn't a great comparison to Go :) Having written some Scala, I really like the language. I also like Go's excellent performance, easy concurrency, ability to produce a single binary without having to rely on JVM etc. I think it would be a bad idea to get overly complicated constructs into Go but union types/pattern matching are relatively accessible, not uncommon now and provide a lot of expressiveness without the risk of code becoming unreadable. Those combined with maybe some alternative approaches for error handling will make me want to write Go again (I've written one component in Go that is working perfectly but it was just too much code with bulk of it being err != nil).
  - jchw 5y ago
    I don’t enjoy writing Scala even if the pattern matching syntax is basically the same as Rust. Some of it is the build tool, some of it is the JVM, and some of it is simply distaste for the language. I don’t hate Scala and I’ve even written a few PRs in Scala, but I have had trouble picking it up for actual projects. Go is extremely pragmatic and often favors clarity in how code will execute and simplicity in syntax and grammar. It’s basically a GC’d successor to C in many regards. It eschews classes for interface-based polymorphism, it compiles and runs code very fast, and above all, I’ve found it easy and rewarding to pick up. I don’t want all of the expressiveness of Scala. Just a bit more than Go has today. Not much more.
- masklinn 5y ago
  > I’d kill for union types as well. > … and pattern matching. Maybe just some extensions for `switch`. Go has type switches which are… ok. If it were possible to “close up” interfaces and type switches took that in account (match completeness) you’d be done about done, you would not have the structural / patterned unpacking but that’s probably less of a concern.
  - zemo 5y ago
    the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.
    - masklinn 5y ago
      > "closed interfaces" are broadly an antipattern in Go. That is complete nonsense. The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive. But go currently has only one of the two, which significantly limits its expressivity and type safety.
      - zemo 5y ago
        you can make an exported interface with an unexported method in it and voila, nobody else can implement it. That’s just broadly not that useful so it doesn’t come up a lot.
        masklinn 5y ago
        Congratulation on getting within inches of the point yet still completely whiffing. But i guess that’s the blub paradox for you.
        zemo 5y ago
        lol the arrogance. Hilarious. there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language. If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive https://github.com/nishanths/exhaustive here, have fun. You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess. You know everything! I am but a simple blubbite, too dim, too dim to get it.
- weatherlight 5y ago
  I agree. I don't understand why the designers wouldn't want the language to be expressive. Wouldn't it be better to have an expressive language with conventions than one that's as rigid as it is today?
  - Veelox 5y ago
    In C++ there could be 7 or 8 different ways go about implementing similar functionality. This is powerful in that it lets you do exactly what you want because each of those ways is subtly different and sometimes you need each one. Go's proponents think it's okay to be a bit less powerful so that there is only 1 maybe 2 ways to do something. This makes code at different companies more similar. It also mean that a new grad can join the team, read the code, copy it, modify it some, and it's pretty much right. A staff SWE and a new grad will right very similar code in Go. In C++ it's anyone's guess how similar their code will be.
    - weatherlight 5y ago
      Ruby is all about conventions, most Ruby, and by extension Ruby on Rails apps look pretty similar despite the fact that the language is extremely expressive. I don't buy that a staff SWE and a new grad will write very similar code in Go. As far as simple language. It is possible to design simple languages that are very expressive, Lisp and Erlang come to mind.
    - jcelerier 5y ago
      Yet every year I onboard new grads on very c++y projects with no restrictions on features used and they manage just fine.
Cthulhu_ 5y ago
> Good, now we just need the ability to declare function parameters and return values non-nullable But that's already possible, just declare arguments and return values as values instead of references. I mean you'll get the zero value if you don't use those functions properly, but those won't cause nil pointer dereference errors. I mean, it's a tradeoff between performance and developer competency. To be harsh, I think nil pointer dereferences are developer error, not a flaw in the language.
- deleted 5y ago
  [deleted]

by welder 5y ago

jchw 5y ago

I’d kill for union types as well. … and pattern matching. Maybe just some extensions for `switch`. … and one of the `try` proposals. That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great together, though; it’d enable Go to do something like `Result` in Rust with few language-level changes. I even remain somewhat skeptical about generics, but I am hopeful.

halfmatthalfcat 5y ago
At that point, let's just write Scala.
- noisy_boy 5y ago
  I think a language that doesn't focus much on backwards compatibility isn't a great comparison to Go :) Having written some Scala, I really like the language. I also like Go's excellent performance, easy concurrency, ability to produce a single binary without having to rely on JVM etc. I think it would be a bad idea to get overly complicated constructs into Go but union types/pattern matching are relatively accessible, not uncommon now and provide a lot of expressiveness without the risk of code becoming unreadable. Those combined with maybe some alternative approaches for error handling will make me want to write Go again (I've written one component in Go that is working perfectly but it was just too much code with bulk of it being err != nil).
- jchw 5y ago
  I don’t enjoy writing Scala even if the pattern matching syntax is basically the same as Rust. Some of it is the build tool, some of it is the JVM, and some of it is simply distaste for the language. I don’t hate Scala and I’ve even written a few PRs in Scala, but I have had trouble picking it up for actual projects. Go is extremely pragmatic and often favors clarity in how code will execute and simplicity in syntax and grammar. It’s basically a GC’d successor to C in many regards. It eschews classes for interface-based polymorphism, it compiles and runs code very fast, and above all, I’ve found it easy and rewarding to pick up. I don’t want all of the expressiveness of Scala. Just a bit more than Go has today. Not much more.
masklinn 5y ago
> I’d kill for union types as well. > … and pattern matching. Maybe just some extensions for `switch`. Go has type switches which are… ok. If it were possible to “close up” interfaces and type switches took that in account (match completeness) you’d be done about done, you would not have the structural / patterned unpacking but that’s probably less of a concern.
- zemo 5y ago
  the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.
  - masklinn 5y ago
    > "closed interfaces" are broadly an antipattern in Go. That is complete nonsense. The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive. But go currently has only one of the two, which significantly limits its expressivity and type safety.
    - zemo 5y ago
      you can make an exported interface with an unexported method in it and voila, nobody else can implement it. That’s just broadly not that useful so it doesn’t come up a lot.
      - masklinn 5y ago
        Congratulation on getting within inches of the point yet still completely whiffing. But i guess that’s the blub paradox for you.
        zemo 5y ago
        lol the arrogance. Hilarious. there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language. If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive https://github.com/nishanths/exhaustive here, have fun. You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess. You know everything! I am but a simple blubbite, too dim, too dim to get it.
weatherlight 5y ago
I agree. I don't understand why the designers wouldn't want the language to be expressive. Wouldn't it be better to have an expressive language with conventions than one that's as rigid as it is today?
- Veelox 5y ago
  In C++ there could be 7 or 8 different ways go about implementing similar functionality. This is powerful in that it lets you do exactly what you want because each of those ways is subtly different and sometimes you need each one. Go's proponents think it's okay to be a bit less powerful so that there is only 1 maybe 2 ways to do something. This makes code at different companies more similar. It also mean that a new grad can join the team, read the code, copy it, modify it some, and it's pretty much right. A staff SWE and a new grad will right very similar code in Go. In C++ it's anyone's guess how similar their code will be.
  - weatherlight 5y ago
    Ruby is all about conventions, most Ruby, and by extension Ruby on Rails apps look pretty similar despite the fact that the language is extremely expressive. I don't buy that a staff SWE and a new grad will write very similar code in Go. As far as simple language. It is possible to design simple languages that are very expressive, Lisp and Erlang come to mind.
  - jcelerier 5y ago
    Yet every year I onboard new grads on very c++y projects with no restrictions on features used and they manage just fine.

Cthulhu_ 5y ago

> Good, now we just need the ability to declare function parameters and return values non-nullable But that's already possible, just declare arguments and return values as values instead of references. I mean you'll get the zero value if you don't use those functions properly, but those won't cause nil pointer dereference errors. I mean, it's a tradeoff between performance and developer competency. To be harsh, I think nil pointer dereferences are developer error, not a flaw in the language.

deleted 5y ago
[deleted]