Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-28 Thread Martin Kletzander
On Tue, Nov 28, 2017 at 10:25:37AM +, Daniel P. Berrange wrote: On Tue, Nov 28, 2017 at 10:22:21AM +, Daniel P. Berrange wrote: On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote: > Just a quick note on what I've found out after I dedicated half day to go > through the

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-28 Thread Martin Kletzander
On Tue, Nov 28, 2017 at 10:47:33AM +, Nir Soffer wrote: On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander wrote: On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote: >On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote: >> On Mon, Nov 20,

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-28 Thread Nir Soffer
On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander wrote: > On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote: > >On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote: > >> On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote: > >>

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-28 Thread Daniel P. Berrange
On Tue, Nov 28, 2017 at 10:22:21AM +, Daniel P. Berrange wrote: > On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote: > > Just a quick note on what I've found out after I dedicated half day to go > > through the tour of go and some other tutorials. The learning curve of Go > >

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-28 Thread Daniel P. Berrange
On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote: > On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote: > > On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote: > > > On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote: > > > > > > > >

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-27 Thread Martin Kletzander
On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote: On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote: On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote: > > I shouldn't have used the word "allocation" in my paragraph above. As > you say, both

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-23 Thread Daniel P. Berrange
On Thu, Nov 23, 2017 at 11:32:26AM +0100, Michal Privoznik wrote: > On 11/14/2017 06:27 PM, Daniel P. Berrange wrote: > > > > This might be more tricky than one would initially think. What about > tests for instance? In our test suite we rely heavily on mocking. For > instance, virpcitest uses

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-23 Thread Michal Privoznik
On 11/14/2017 06:27 PM, Daniel P. Berrange wrote: > This might be more tricky than one would initially think. What about tests for instance? In our test suite we rely heavily on mocking. For instance, virpcitest uses virpcimock which reimplements kernel behaviour for detach/attach of PCI

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-21 Thread Chris Friesen
On 11/20/2017 09:25 AM, Daniel P. Berrange wrote: When I worked in OpenStack it was a constant battle to get people to consider enhancements to libvirt instead of reinventing it in Python. It was a hard sell because most python dev just didn't want to use C at all because it has a high curve to

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-20 Thread Daniel P. Berrange
On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote: > On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote: > > > > I shouldn't have used the word "allocation" in my paragraph above. As > > you say, both languages have similar needs around allocation. The difference >

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-20 Thread Martin Kletzander
On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote: On Mon, Nov 20, 2017 at 12:24:22AM +0100, Martin Kletzander wrote: On Tue, Nov 14, 2017 at 05:27:01PM +, Daniel P. Berrange wrote: [...] > I don't have direct experiance in Rust, but it has the same kind of benefits over

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-20 Thread Daniel P. Berrange
On Mon, Nov 20, 2017 at 12:24:22AM +0100, Martin Kletzander wrote: > On Tue, Nov 14, 2017 at 05:27:01PM +, Daniel P. Berrange wrote: > > [...] > > > I don't have direct experiance in Rust, but it has the same kind of > > benefits over > > C as Go does, again without the downsides of

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-19 Thread Martin Kletzander
On Tue, Nov 14, 2017 at 05:27:01PM +, Daniel P. Berrange wrote: [...] I don't have direct experiance in Rust, but it has the same kind of benefits over C as Go does, again without the downsides of languages like Python or Java. There are some interesting unique features to Rust that can

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-17 Thread Daniel P. Berrange
On Fri, Nov 17, 2017 at 10:04:35AM -0600, Chris Friesen wrote: > On 11/17/2017 06:37 AM, Daniel P. Berrange wrote: > > On Fri, Nov 17, 2017 at 01:34:54PM +0100, Markus Armbruster wrote: > > > "Daniel P. Berrange" writes: > > > > > > [...] > > > > Goroutines are basically a

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-17 Thread Chris Friesen
On 11/17/2017 06:37 AM, Daniel P. Berrange wrote: On Fri, Nov 17, 2017 at 01:34:54PM +0100, Markus Armbruster wrote: "Daniel P. Berrange" writes: [...] Goroutines are basically a union of the thread + coroutine concepts. The Go runtime will create N OS level threads,

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-17 Thread Daniel P. Berrange
On Fri, Nov 17, 2017 at 01:34:54PM +0100, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > > [...] > > Goroutines are basically a union of the thread + coroutine concepts. The > > Go runtime will create N OS level threads, where the default N currently > > matches

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-17 Thread Markus Armbruster
"Daniel P. Berrange" writes: [...] > Goroutines are basically a union of the thread + coroutine concepts. The > Go runtime will create N OS level threads, where the default N currently > matches the number of logical CPU cores you host has (but is tunable to > other values).

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-17 Thread Daniel P. Berrange
On Thu, Nov 16, 2017 at 04:55:55PM -0500, John Ferlan wrote: > On 11/14/2017 12:27 PM, Daniel P. Berrange wrote: > > When libvirt was created, C was the only viable choice for anything aiming > > to be > > a core system library component. At that time 2005, aside from C there were > > common

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-16 Thread Chris Friesen
On 11/16/2017 03:55 PM, John Ferlan wrote: On 11/14/2017 12:27 PM, Daniel P. Berrange wrote: Part of the problem is that, despite Linux having very low overhead thread spawning, threads still consume non-trivial resources, so we try to constrain how many we use, which forces an M:N

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-16 Thread John Ferlan
On 11/14/2017 12:27 PM, Daniel P. Berrange wrote: > The Problem(s) > == First off I'll state I'm not opposed to considering adopting or integrating a newer language. Still, I have my concerns, fears, uncertainty, and doubts. In a world where one must "adapt or die", I'm not opposed

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-16 Thread Daniel P. Berrange
On Thu, Nov 16, 2017 at 02:58:33PM +0100, Peter Krempa wrote: > On Tue, Nov 14, 2017 at 17:27:01 +, Daniel Berrange wrote: > > The Problem(s) > > == > > Note at first: This is a personal opinion. I'm not discrediting any > advantages a different language might have in technical

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-16 Thread Peter Krempa
On Tue, Nov 14, 2017 at 17:27:01 +, Daniel Berrange wrote: > The Problem(s) > == Note at first: This is a personal opinion. I'm not discrediting any advantages a different language might have in technical sense. I'm against this. Go is a utterly ugly language. It looks as the

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-15 Thread Richard W.M. Jones
On Wed, Nov 15, 2017 at 02:59:20PM +, Daniel P. Berrange wrote: > On Wed, Nov 15, 2017 at 12:28:30PM +0100, Bjoern Walk wrote: > > Why has there never been a truly satisfying standard library for C for > > this kind of stuff? If such a project would exist, this wheel > > re-inventing would be

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-15 Thread Richard W.M. Jones
As a point of reference, libguestfs started to allow OCaml in the daemon this summer, so effectively you can now use OCaml to implement libguestfs APIs. (I'm not suggesting libvirt should use OCaml). Some points: - We have a mixed C / OCaml daemon. The vast majority of the code is still C

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-15 Thread Daniel P. Berrange
On Wed, Nov 15, 2017 at 12:28:30PM +0100, Bjoern Walk wrote: > Daniel P. Berrange [2017-11-14, 05:27PM +]: > > The Problem(s) > > == > > > > When libvirt was created, C was the only viable choice for anything aiming > > to be > > a core system library

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-15 Thread Bjoern Walk
Hello Daniel, thank you for this interesting insight. The future-proof choice of tools, especially programming languages, is certainly a problem that a lot of project have to solve sooner rather then later. For projects that are currently written in any non-memory-managed language, this issue is

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

2017-11-14 Thread Daniel P. Berrange
The Problem(s) == When libvirt was created, C was the only viable choice for anything aiming to be a core system library component. At that time 2005, aside from C there were common choices of Java, Python, Perl. Java was way too heavy for a low level system component, Python was