> > 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. So in regard to writing servers everything not compiled directly to assembly code (plus go) is out of the question, right? My anecdotal experience of using Ruby has shown me that the time saved > thanks to easier syntax and features is easily lost tenfold to bugs that > static analysis would have found. The design of interpreted languages makes > most simple errors only discoverable at runtime. > Now that I recall my memories I think you may been right, also when I think about it seems better to waste a little bit more time in developing it than having to solve lots of bugs later. > As for Nimrod, frankly, I find its syntax quite ugly. I can see the appeal > of its features though. > Now, my inner self is crying as I found nimrod to be damn beautiful, as it is really clean and simple, also I think syntax cleanlinnes means readiness, now you talk about that . In regard to features, maybe some of them could be used as inspiration? (for the language I mean) > Indeed you were correct that the main goal is lower level code. But maybe, > with a solid foundation, domain-specific extensions would achive same > benefits as would a language designed for application use? Just an idea. > Incidentally, C++ tries very hard to avoid domain-specific features, while > Ada I think is very friendly to such extensions. > I'm rather exceptic, some language design decisions may be incompatible between a low-level language and a high-level, though it may be interesting to do so. If you plan to take on this count with me, I'll try to help with ideas/new visions ... > 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.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
