On 3 July 2014 02:15, Sergio Tortosa Benedito <[email protected]> wrote:
> I do concern myself mainly with low level platform development. However, >> most of the problems of userspace development are shared between the two >> groups. >> >> > > >> Well, it mostly boils down to two problems: >> 1) non-optional garbage collector that needs complex runtime support to >> work efficiently, and >> 2) even the most basic libraries pull a lot of unnecessary and largely >> unused code into the executable >> >> In effect, using Go artificially inflates the "trusted computing base" of >> the server. >> This problem is not unique to Go. Writing server in Java, C#, or any >> interpreted language would suffer the same considerations. >> > > The first point seems to be a very common complain in Go, while the second > I dont even imagine how something like that is posible. > Imagine package "fmt" for formatted output, akin to snprintf() in C. You have handling in there for all sorts of arguments, and it uses other libraries for some conversions. Even if you really only ever print ints, you still pull all the libraries that can ever possibly be used for some input argument type, because analysis that could optimize that away would be too expensive for Go's ideal of build performance. Normally, if you really cared about individual binary size, you could use gccgo and dynamic linking, but here you'd have to include that library in initrd image, and the whole library is huge. > So in regard to writing servers everything not compiled directly to > assembly code (plus go) is out of the question, right? > > Not necessarily. But if it needs a virtual machine or complex garbage collector, it might be better to avoid it. > I'd prefer using namespaces as module paths. I.e. all HelenOS specific >> interfaces would be in namespace helenos::, and each self-contained library >> would have it's own namespace within. E.g. helenos::vfs::open(), >> helenos::ddf::*, helenos::fibril::create(). Of course, if you only use a >> single namespace in your file, you can always put "using namespace >> helenos;" or "using namespace helenos::vfs;" there to avoid typing. >> > >> > In effect, all HelenOS code would become C++, with us just being really >> picky about which features we allow using in mainline code. There are tools >> for generating bindings for C or other languages directly from C++ >> interface, so interoperability should not be a great concern. >> > > I don't really like C++, thought it may improve a bit from C and the > namespace would help in having a cleaner API. Truth be told, I'm uncertain > what the conversion would imply (time to implement, bugs ...), also it may > be worthwhile to convert the servers to the new language; in any way seems > there will be some rewrite. > > I don't think it is worthwhile to convert them into an entirely different language. I currently don't see any widespread language out there that would fit, and rewriting them in some custom experimental language could very well just kill the chances of attracting more contributors. On the other hand, switching to C++ means very little effort initially (most of the code would compile as C++ without change), and it would be possible to start using new safety features incrementally, without vast overall changes. Even the libraries can be moved to namespaces one at a time.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
