On 2 July 2014 19:56, Sergio Tortosa Benedito <[email protected]> wrote:
> Hello Jirka. > > The first question, is which languages do we support for use in end-user >> applications, and which of them do we further support for development of >> core servers. > > > Maybe it didnt seem so but I was talking about the higher-level/more > end-user applications/libraries, for the low-level part I don't have any > experiencie at all,thought it seems reasonable to replace C there (where it > makes sense, of course). > > I do concern myself mainly with low level platform development. However, most of the problems of userspace development are shared between the two groups. As my bachelor thesis, I implemented an alternative VFS server in Go. >> However, I abandoned Go for servers due to some conceptual problems I >> encountered, and due to lack of time or demand, I haven't finished Go >> support either. > > > Since Go is a so acclaimed language I would like to hear those problems > you found, maybe you posted them? If you did they went unnoticed for me, > > 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. > My personal opinion is that the preferred language must make it easy to >> develop safe and error-free software. That means strong static type system, >> lack of undefined/counterintuitive behaviors, support from at least one >> sound static analyzer, and enough expressiveness to make most common >> patterns easy to read and write. [0] > > > This sounds pretty much like rust, though excepting it's memory model and > the pattern matching I don't find it very interestings. Your terms seems > reasonable, however I find that the development-speed granted by the > easiness of use and features of interpreted languages may counter those > (only a thought that does not mean I really aprove them), obviously that > only makes sense for the higher-level code. Anyway I think Nimrod combines > the good syntax with a static type system, and I'm pretty sure it allows > enough expressiveness, if you find a moment it may be worthwile to see it > superficially. > > 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. As for Nimrod, frankly, I find its syntax quite ugly. I can see the appeal of its features though. > This is actually a sneaky suggestion that in order to have any chance of >> succeeding, HelenOS needs to build a strong, consistent, stable, >> well-documented, and pleasant to use, foundation for further development. > > > I think it will help to have clear our directions before building anything. > > >> In order to actually accomplish any advancement here, the project would >> need a formal governing/planning structure in place, a set of long-term >> goals on multiple levels of design, and a coordinated push in that >> direction. > > > So, indeed my question seems to have raised the need of structure and > goals (or just made it more apparent). Those seems points to be discussed > as soon as possible (i.e: after the release). > > Yes, I think such discussion would be quite helpful and interesting. > [0] As a side note, I have described my ideal of the "perfect" replacement >> for C earlier this year, and even though I have not written about my effort >> since (lots of school stuff in the meantime), I am currently slowly working >> on the compiler and a static analysis framework. If you are interested in >> commenting, you can find the original post somewhere in February's archive. > > > I didn't comment on that mainly because I thought you mean a replacement > for the low-level, also I didnt had much to say but maybe if it's also > geared towards (more high-level) application development then I'll take a > look. > > 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 have recently started familiarizing myself with C++11. While I do not >> like the C++ as a whole, the horrible beast it is, I do think that adopting >> some C++ features would benefit HelenOS. Among other things, namespaces >> would allow greater separation of the core library from the standard >> interfaces, which we currently shamelessly clobber, resulting in >> difficulties in supporting software written to standard. > > > Namespaces would be helpful but I don't like the way are handled in C++, I > prefer how is handled in other languages (such as Nimrod) in which the > namespace is optional, and only required with name clashing, also I don't > know how are these going to be added to our C, and in the case we added > them, it would still being C? > 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. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
