4 ms·

I have a question to the crowd. If you really like Go and you're already willing to adopt a solution based in making IPC calls to separate processes just to pu

I have a question to the crowd. If you really like Go and you're already willing to adopt a solution based in making IPC calls to separate processes just to put together a GUI... ...why not write your GUI app in something production-ready that makes sense to write a GUI, and have that call your Go process ?

randomdata 2y ago
How are you going to run on X11 systems if you have ruled out making IPC calls to a separate process in order to put together a GUI? Anyway, the primary advantages of the separate process you speak of is that it: 1. Deals with the LGPL concerns for you. 2. Deals with the pains of compilation, and especially cross-compilation for you. That is why you might consider it. Of course, it comes with many disadvantages too. Tradeoffs, as always.
- chipdart 2y ago
  > How are you going to run on X11 systems if (...) I'm not sure you understood the question I asked.
  - randomdata 2y ago
    Perhaps it is actually you who misunderstood my question?
mappu 2y ago
I currently do this at $DAYJOB with a C++/Qt GUI talking to a Go daemon. It's fine but eventually the busywork in marshalling is a headache, and it doesn't scale well for large amounts of data. I can see some advantage of the therecipe/qt "qtbox" idea. Even though the same marshalling is present, you get to write everything still in one language, the cross-language part is hidden from you. In either case, it's great that MIQT now lets you avoid this, and write everything in Go with no IPC marshalling at all.
- chipdart 2y ago
  > Even though the same marshalling is present, you get to write everything still in one language, the cross-language part is hidden from you. The hard part of writing a desktop application is the GUI code, and how to implement user flows and how to manage the application state. Adopting a highly non-standard technology to handle the hard part and on top of that adopt an ad-hoc IPC solution to get it to work sounds like putting all the project risks in all the wrong places.

randomdata 2y ago

How are you going to run on X11 systems if you have ruled out making IPC calls to a separate process in order to put together a GUI? Anyway, the primary advantages of the separate process you speak of is that it: 1. Deals with the LGPL concerns for you. 2. Deals with the pains of compilation, and especially cross-compilation for you. That is why you might consider it. Of course, it comes with many disadvantages too. Tradeoffs, as always.

chipdart 2y ago
> How are you going to run on X11 systems if (...) I'm not sure you understood the question I asked.
- randomdata 2y ago
  Perhaps it is actually you who misunderstood my question?

mappu 2y ago

I currently do this at $DAYJOB with a C++/Qt GUI talking to a Go daemon. It's fine but eventually the busywork in marshalling is a headache, and it doesn't scale well for large amounts of data. I can see some advantage of the therecipe/qt "qtbox" idea. Even though the same marshalling is present, you get to write everything still in one language, the cross-language part is hidden from you. In either case, it's great that MIQT now lets you avoid this, and write everything in Go with no IPC marshalling at all.

chipdart 2y ago
> Even though the same marshalling is present, you get to write everything still in one language, the cross-language part is hidden from you. The hard part of writing a desktop application is the GUI code, and how to implement user flows and how to manage the application state. Adopting a highly non-standard technology to handle the hard part and on top of that adopt an ad-hoc IPC solution to get it to work sounds like putting all the project risks in all the wrong places.