Hello everyone. There has been one issue in Go that has never gotten out of my head, so it went on and on. The problem is modules.
In the beginning there was Oberon. Let's just face it. Oberon was a brilliant designed piece of engineering. Oberon did have some marvelous features that just don't exist today, such as GC for everything, including closing files (anyone ever seen that), and their memory system was also GC, including modules entirely. So they made a counter for each module that was being used. You add one, the counter increase. You lose one, the counter went down and when that counter went zero that module got erased from memory. Pretty clever. Oberon also got very small compiled modules. They were compiled and the API was being check-summed. And they didn't got generics ;-) There was no need for that since the basic types were so simple, a lot simpler than in Go. Why were they using this compiled API file? That was only used for identification. Everything that has public code goes into the compiled header file. There is AFAIK no no linking. The only thing that is being used are the compiled modules and compiled header files. Now I have explained everything that I know that I know about modules. What are the areas of interest? The only answer that I can find out is OS design. But for that the benefits are huge, but only if you have the guts to really gutter the whole thing down. What compiles: That is pretty easy. Everything that is public will be part of a header file, the rest stays inside the module itself. The benefits: 1. This maps a lot better for OS development. 2. No linking involved. 3. updates could have been "on the fly", with just a couple of LOC you can download and compile an entire module, as long as the API hasn't changed. 4. Fit well with systems such as apt-get, GNU GUIX, but also go get. The downsides: 1. This could confuse people who tend to use it. How can you use it? That is why I think that this could probably only work for OS design. You just don't want to download a half baked module. 2. It could have been used proprietary. Personally I have a lot against proprietary code. Questions: Links: 1. http://members.home.nl/jmr272/Oberon/ModToOberon.pdf 2. https://en.wikipedia.org/wiki/Oberon_(programming_language) 3. http://www.ethoberon.ethz.ch/WirthPubl/ProgInOberon.pdf -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
