Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Miqt: MIT-licensed Qt bindings for Go

github.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Miqt: MIT-licensed Qt bindings for Go

#81

Post by Timon3 »

loeg wrote: post #75
Timon3 wrote: post #71

Earlier quoted context omitted.

The opposite of "some societal good" isn't "less societal good than other alternatives", it's "no societal good". The original statement didn't contain any comparisons. Even the worst alternative can still have some societal good.

The original statement is comparing against non-copyleft licenses like MIT. It is clearly stating the author's preference for the GPL.

It's not stating a preference - it's stating that, no matter what your preference is, there is some societal good from GPL/LGPL. Preferences don't change the existence of that good.

Re: Miqt: MIT-licensed Qt bindings for Go

#82

Post by randomdata »

chipdart wrote: post #79

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 ?

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#84

Post by Timon3 »

airstrike wrote: post #83
Timon3 wrote: post #80

Earlier quoted context omitted.

Sure, if you add words, the meaning changes. So what?

It's called nuance and context.

I honestly don't understand how you read this "nuance" into the original comment. They don't say that GPL/LGPL is absolutely better than MIT/BSD, and they speak positively about the project. There is no comparison here.

The switch from GPL/LGPL to MIT/BSD loses a specific set of restrictions that are "encouraging organisations to release their code under a similar license". This is a specific societal good that is being lost. Even if you don't think that it's a big deal, I can't imagine anyone reasonable saying "literally everything would be better GPL/LGPL" - objectively, the public wouldn't be guaranteed to have open-source-free access to so many products. You can argue that there would be more products or whatever you want, but unless you're taking an absolutist stance, some societal good comes from these licenses.

The only way to arrive at a comparison here would be to ignore the context and the chosen wording by the OP.

Re: Miqt: MIT-licensed Qt bindings for Go

#85

Post by mappu »

chipdart wrote: post #79

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 ?

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.

Re: Miqt: MIT-licensed Qt bindings for Go

#86

Post by mappu »

chipdart wrote: post #78
voidfunc wrote: post #67

Earlier quoted context omitted.

Yea.. that sounds like a non-starter for use.

> Yea.. that sounds like a non-starter for use. I'd also wager that a FLOSS binding to a non-FLOSS framework with steep licensing fees would also kill this option for most.

What non-FLOSS framework do you mean? Qt Widgets is LGPL,

Re: Miqt: MIT-licensed Qt bindings for Go

#87

Post by airstrike »

Timon3 wrote: post #84
airstrike wrote: post #83

Earlier quoted context omitted.

It's called nuance and context.

I honestly don't understand how you read this "nuance" into the original comment. They don't say that GPL/LGPL is absolutely better than MIT/BSD, and they speak positively about the project. There is no comparison here. The switch from GPL/LGPL to MIT/BSD loses a specific set of restrictions that are "encouraging organisations to release their code under a similar license". This is a specific societal good that is be…

You're only seeing the alleged benefits from GPL, without factoring in its costs. Everything is a tradeoff. Some companies don't touch GPL code, which means those projects receive less support than they would with a more permissive license such as MIT/BSD. You're claiming GPL "[encourages] organisations to release their code under a similar license". I'm saying it often discourages organisations from ever touching GPL code and picking other libraries instead.

People have been writing about this in way more detail for a long time. If you're really trying to understand some position you can't possibly fathom and not just argue, then I'd point you to one post from 15 years ago: https://sealedabstract.com/rants/why-the-gpl-sucks/index.htm...

Re: Miqt: MIT-licensed Qt bindings for Go

#88

Post by Timon3 »

airstrike wrote: post #87
Timon3 wrote: post #84

Earlier quoted context omitted.

I honestly don't understand how you read this "nuance" into the original comment. They don't say that GPL/LGPL is absolutely better than MIT/BSD, and they speak positively about the project. There is no comparison here. The switch from GPL/LGPL to MIT/BSD loses a specific set of restrictions that are "encouraging organisations to release their code under a similar license". This is a specific societal good that is be…

You're only seeing the alleged benefits from GPL, without factoring in its costs. Everything is a tradeoff. Some companies don't touch GPL code, which means those projects receive less support than they would with a more permissive license such as MIT/BSD. You're claiming GPL "[encourages] organisations to release their code under a similar license". I'm saying it often discourages organisations from ever touching GP…

No, I'm not only seeing the alleged benefits, as I clearly explained in my previous comment. MIT/BSD brings their own societal good, but it's a different societal good, and it's not an equivalent societal good. Just because you gain some societal good doesn't mean you gain the exact same societal good. Unless you're trying to misunderstand OP, it's not a hard concept.

GPL/LGPL has advantage A. MIT/BSD has advantage B. A and B are different. Even if B is greater than A, it still doesn't mean that A is a subset of B. You keep acting like the only thing that matters is |A| and |B|, because you're somehow fixated on this being a comparison.

Try re-reading the original comment without adding in words like "marginal". You'll see that there is no comparison made between societal goods.

Re: Miqt: MIT-licensed Qt bindings for Go

#89

Post by chipdart »

mappu wrote: post #85
chipdart wrote: post #79

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 ?

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…

> 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.

Re: Miqt: MIT-licensed Qt bindings for Go

#90

Post by chipdart »

randomdata wrote: post #82
chipdart wrote: post #79

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 ?

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.…

> How are you going to run on X11 systems if (...)

I'm not sure you understood the question I asked.

Post reply on HN