4 ms·

Nullable references are far from what they could be. When you use them a lot, you often have to override compiler with ! because it is too stupid. I’d also like

Nullable references are far from what they could be. When you use them a lot, you often have to override compiler with ! because it is too stupid. I’d also like to have better support for const references as in c++. I’d like to see more powerful generics, so that something akin to partial template specialisation is possible without going through boxing and unboxing too much. With regards to safety, well rust has shown what is possible. Async/ await has introduced function colouring which is a kind of bloat. All in all there are many things that could reduce the bloat, instead of some tiny features that help with value types or to optimise some rare case.

tester756 5y ago
>With regards to safety, well rust has shown what is possible. Async/ await has introduced function colouring which is a kind of bloat. I do wonder how much effort it'd require
jayd16 5y ago
People call async/await function coloring bloat but I think it's exactly where it needs to be. IMO execution yielding needs to be explicit not implicit for use cases where thread identity matters. How are you going to write a UI framework if thread context can change unexpectedly?
- coder543 5y ago
  Go doesn't need "coloring bloat", but you can still handle the need to run code on a specific thread using LockOSThread.[0] If you absolutely need your code that interacts with the OS GUI functions to be running on the first thread the OS spawned, the documentation even tells you how to do that. This is an exceptionally low level detail that very few people should ever have to think about. Is there something else you can point to that's pertinent to more developers? Having written Go for years (as well as a good bit of Rust), I love not having to worry about async/await being the concurrency model, and thread identity is never something I think about. With the upcoming Go release that brings generics, I think there are some code patterns that inherently benefit from an async/await style pattern where you spawn several tasks and await their results, so I'm looking forward to having a generic pattern to spawn goroutines that return a value into a Promise... but the infectious nature of "real" async/await is not something I would consider beneficial in most languages. Rust is a language that is all about low level details and performance, so it actually makes sense there, but that's a rare exception, in my opinion. Developers generally shouldn't need to worry about things a good runtime can take care of, just like you don't need to worry about when you're going to free an object in C#... the runtime takes care of these details that are rarely relevant to meeting the developer's objectives. When you absolutely need that control, there are usually escape hatches. If the application you're writing frequently requires unlimited control, you should probably be using an unmanaged language like Rust to begin with. [0]: https://pkg.go.dev/runtime#LockOSThread https://pkg.go.dev/runtime#LockOSThread
  - jayd16 5y ago
    >This is an exceptionally low level detail that very few people should ever have to think about. Every popular UI package uses a UI thread pattern. Every UI dev thinks about this.
    - coder543 5y ago
      This should be handled transparently by the library, not the application developer. Which is not to say that UI frameworks developed decades ago got this right. As I said, Go handles this problem just fine, apparently disproving your original argument, which was the main point. Async/await with explicit yield points isn’t needed to support this pattern.
      - jayd16 5y ago
        As soon as anyone gets it right then perhaps async/await will be the wrong choice but not until then. My understanding is Go UIs are mostly using html or some other languages/frameworks for UI work. Can you link me to a popular native Golang GUI framework to look at?
        coder543 5y ago
        There are definitely libraries, such as bindings to GTK: https://github.com/gotk3/gotk3 https://github.com/gotk3/gotk3 or Win32: https://github.com/rodrigocfd/windigo https://github.com/rodrigocfd/windigo The point remains that it is possible to do these things without async/await, which you seemingly asserted it was not. Everything else is irrelevant, as far as I can tell. Go absolutely isn’t frequently used to develop native UIs, so of course “popular” is a strange thing to discuss here. Why isn’t it popular? Most likely because the kind of visual UI builder tools used in Visual Studio or Android Studio have never had an equivalent funded for use with Go, due to lack of commercial support for that use case. Beyond that, web UI frameworks are immensely popular these days, and most companies would rather use those, further removing motivation to really “make native GUI happen” in Go, but there are niche use cases out there, as evidenced by the existence of libraries. If Go had come out in the early 2000s, native GUI support would likely have been a much higher priority. This is pretty far off topic, though.

tester756 5y ago

>With regards to safety, well rust has shown what is possible. Async/ await has introduced function colouring which is a kind of bloat. I do wonder how much effort it'd require

jayd16 5y ago

People call async/await function coloring bloat but I think it's exactly where it needs to be. IMO execution yielding needs to be explicit not implicit for use cases where thread identity matters. How are you going to write a UI framework if thread context can change unexpectedly?

coder543 5y ago
Go doesn't need "coloring bloat", but you can still handle the need to run code on a specific thread using LockOSThread.[0] If you absolutely need your code that interacts with the OS GUI functions to be running on the first thread the OS spawned, the documentation even tells you how to do that. This is an exceptionally low level detail that very few people should ever have to think about. Is there something else you can point to that's pertinent to more developers? Having written Go for years (as well as a good bit of Rust), I love not having to worry about async/await being the concurrency model, and thread identity is never something I think about. With the upcoming Go release that brings generics, I think there are some code patterns that inherently benefit from an async/await style pattern where you spawn several tasks and await their results, so I'm looking forward to having a generic pattern to spawn goroutines that return a value into a Promise... but the infectious nature of "real" async/await is not something I would consider beneficial in most languages. Rust is a language that is all about low level details and performance, so it actually makes sense there, but that's a rare exception, in my opinion. Developers generally shouldn't need to worry about things a good runtime can take care of, just like you don't need to worry about when you're going to free an object in C#... the runtime takes care of these details that are rarely relevant to meeting the developer's objectives. When you absolutely need that control, there are usually escape hatches. If the application you're writing frequently requires unlimited control, you should probably be using an unmanaged language like Rust to begin with. [0]: https://pkg.go.dev/runtime#LockOSThread https://pkg.go.dev/runtime#LockOSThread
- jayd16 5y ago
  >This is an exceptionally low level detail that very few people should ever have to think about. Every popular UI package uses a UI thread pattern. Every UI dev thinks about this.
  - coder543 5y ago
    This should be handled transparently by the library, not the application developer. Which is not to say that UI frameworks developed decades ago got this right. As I said, Go handles this problem just fine, apparently disproving your original argument, which was the main point. Async/await with explicit yield points isn’t needed to support this pattern.
    - jayd16 5y ago
      As soon as anyone gets it right then perhaps async/await will be the wrong choice but not until then. My understanding is Go UIs are mostly using html or some other languages/frameworks for UI work. Can you link me to a popular native Golang GUI framework to look at?
      - coder543 5y ago
        There are definitely libraries, such as bindings to GTK: https://github.com/gotk3/gotk3 https://github.com/gotk3/gotk3 or Win32: https://github.com/rodrigocfd/windigo https://github.com/rodrigocfd/windigo The point remains that it is possible to do these things without async/await, which you seemingly asserted it was not. Everything else is irrelevant, as far as I can tell. Go absolutely isn’t frequently used to develop native UIs, so of course “popular” is a strange thing to discuss here. Why isn’t it popular? Most likely because the kind of visual UI builder tools used in Visual Studio or Android Studio have never had an equivalent funded for use with Go, due to lack of commercial support for that use case. Beyond that, web UI frameworks are immensely popular these days, and most companies would rather use those, further removing motivation to really “make native GUI happen” in Go, but there are niche use cases out there, as evidenced by the existence of libraries. If Go had come out in the early 2000s, native GUI support would likely have been a much higher priority. This is pretty far off topic, though.