Consider rewriting the C code in Swift for memory safety

[AkihiroSuda]

[nirs]

It will be harder to contribute with esoteric language, but it is also an opportunity to learn new language.

[jandubois]

It will be harder to contribute with esoteric language

I do share this concern. Is memory safety really the reason for the remaining issues with this driver?

[AkihiroSuda]

It will be harder to contribute with esoteric language

I guess it is inevitable for macOS devs to learn Swift at some point.
We may also consider using Go instead, but calling vmnet.framework via cgo (w/ Apple-flavored C) might be quite cumbersome

Is memory safety really the reason for the remaining issues with this driver?

Probably no

[tamird]

I did an experiment rewriting the client to Swift. The result is pretty awkward, since nice abstractions for interacting with C string aren't readily available.

What's more alarming though is that the binary size went from 34kB to 2.1mB in release mode.

The client is probably special enough that writing it in swift isn't worth it.

I also discovered a bug in the -- handling in the client:

tamird@Mac socket_vmnet % $(brew --prefix socket_vmnet)/bin/socket_vmnet_client $(brew --prefix)/var/run/socket_vmnet --               
zsh: segmentation fault  $(brew --prefix socket_vmnet)/bin/socket_vmnet_client  --

I'll try writing the main app in swift once #69 settles.

[jandubois]

What's more alarming though is that the binary size went from 34kB to 2.1mB in release mode.

I would not worry about that; this is normal for most languages runtimes. Writing it in Go would result in a similar size.

I'll try writing the main app in swift once #69 settles.

Experimentation is of course good, and I'm curious how it will look.

But I continue to have reservations about adding more languages to the Lima project. Historically it has always been a problem when a project combines parts in too many languages (and it has sometimes been my own fault in adding them).

I understand that using VMNET makes this special, but in general I recommend sticking to:

• TypeScript for frontend stuff
• Go for compiled code
• Bash for scripting

This also gives you the biggest chance that a user of the code will debug and fix a problem themselves instead of just filing an issue and waiting for the maintainers to figure it out.

So rewriting it in Swift must provide some tangible benefit beyond just wanting to use a different language. I would have the same concerns if this was about rewriting it in Rust or Zig.

[tamird]

Interesting. Perhaps then the client should be in Go.

Is there much C in Lima? If not, we might still consider writing this (the server) in swift given that high quality bindings for vmnet aren't available in other languages.

[afbjorklund]

TypeScript for frontend stuff

I used C++ for the GUI, because it was the most portable and generated small enough binaries (with Qt libs, compared with Electron apps)

But the interface with the Lima and container backends is all in JSON, and I suppose one could have used a GUI design tool for the layout... It is also quite readable, no modern C++ templates etc

https://github.com/afbjorklund/lima-gui

[nirs]

I did an experiment rewriting the client to Swift. The result is pretty awkward, since nice abstractions for interacting with C string aren't readily available.

I see very little benefit in rewriting the client, it is a very trivial and short C program.

I also discovered a bug in the -- handling in the client:

tamird@Mac socket_vmnet % $(brew --prefix socket_vmnet)/bin/socket_vmnet_client $(brew --prefix)/var/run/socket_vmnet --               
zsh: segmentation fault  $(brew --prefix socket_vmnet)/bin/socket_vmnet_client  --

Can you open an issue?

This should be a trivial fix returning an error if argc is zero after processing all arguments. The current code does not decrease argc when consuming arguments from argv.

Adding a test for the client will also be useful.