I have a (self-written) runtime library which I have used in various programming projects over the years. It started life as a Pascal library in the early days of Turbo Pascal and has since progressed through incarnations in C, Perl and Lua. I am now contemplating to move this over to Go (not least because there are some interesting parallels between Go and Lua). A good part of Go's std library does more or less what my own libraries do (for instance, the flag package or the regex stuff) in which case I can either use them directly or get away with writing a small interface layer.
Problems start with those packages where my model is too different from Go's for a simple interface layer to hide the differences (a case in point are the directory-walking functions). I see two ways forward: re-implement my code as a Go package; or patch some of the existing Go runtime packages.
I am leaning towards the first option, not least because this will help me to get to grips with the language. Then again, I've often patched source code for my own requirements and I am comfortable with that approach. The changes would be localised and it shouldn't be too difficult to merge future version of Go's runtime library with my changes.
So is it feasible, advisable to do that or do I have to regard the Go sources as read only?
So is it feasible ... ?
No. Everything will break once you touch the Go stdlib as every package out there relies on the stdlib.
So is it ... advisable to do that ...?
No, not at all.
[D]o I have to regard the Go sources as read only?
Yes.
Note that what you call "runtime" is not the Go runtime but the Go's standard library.
Related
I am planning to write a cross-platform app that has most of its functionality shared across all platforms (Linux, OS X, Windows, iOS, Android).
These are mostly helper function (calculations, internal lists, networking etc.) so I figured it would be convenient to have those functions in a library I can compile for every platform while still being able to create custom UI for each platform individually.
Dominant languages across those platforms I mentioned are C, Objective-C, C# and Java. All these languages support calling C-API functions from a library either directly or via internal wrappers. Since I don't want to write 80% of my application's code in C/C++, I searched and found Go.
cgo seems to be the solution for my problem.
My current thought is to code the core library in Go and then compile it for each platform, however, invoking go build does not create anything at all.
I import "C".
I have declared a func and added the //export statement before.
I read about gccgo but people keep pointing out that it is outdated and should not be used.
Maybe anyone can point out a flaw in my thoughts or help me bring this library file together. Thanks in advance.
If your aim is to build a library that can be linked into arbitrary C, Objective-C or Java programs, you are out of luck with the currently released standard tool chain. There are plans to change this in the future, but at present the Go runtime is not embeddable in other applications.
While cgo will allow you to export functions to be called from C, this is only really useful for cases when the C code you call from Go needs to call back to Go.
I'm wondering if Go is developed enough to use it to make the core of an operating system? So basically replace what you would normally use C for with Go.
Of course you can develop an OS in almost any (Turing complete) language. Usually there's some small assembly layer required, though. And usually one must implement some parts of the OS using only a restricted subset of the language in question.
Examples:
JavaOS.
Singularity. (Applies with some limits only.)
What concerns Go, there used to be a usable (toy) Go kernel implementation, but it is now obsoleted already for a long time. From rsc's post:
In the repository history there is a toy kernel called "tiny".
If you run hg log -k tiny you'll find it. It doesn't build anymore
with the current version of Go but it illustrates what might
be done. It had the whole package runtime, including the
garbage collector, in the kernel.
Russ
I think I finally know what I want in a compiled programming language, a fast compiler. I get the feeling that this is a really superficial thing to care about but some time after switching from Java to Scala for a while I realized that being able to make a small change in code and immediately run the program is actually quite important to me. Besides Java and Go I don't know of any languages that really value compile speed.
Delphi/Object Pascal. Make a change, press F9 and it runs - you don't even notice the compile time. A full rebuild of a fairly substantial project that we run takes of the order of 10-20 seconds, even on a fairly wimpy machine
There's an open source variant available at www.freepascal.org. I've not messed with it but it reportedly is just as fast - it's the design of the Pascal language that allows this.
Java isn't fast for compiling. The feature you a looking for is probably a hot replacement/redeployment while coding. Eclipse recompiles just the files you changed.
You could try some interpreted languages. They usually don't require compiling at all.
I wouldn't choose a language based on compilation speed...
Java is not the fastest compiler out there.
Pascal (and its close relatives) is designed to be fast - it can be compiled in a single pass. Objective Caml is known for its compilation speed (and there is a REPL too).
On the other hand, what you really need is REPL, not a fast recompilation and re-linking of everything. So you may want to try a language which supports an incremental compilation. Clojure fits well (and it is built on top of the same JVM you're used to). Common Lisp is another option.
I'd like to add that there official compilers for languages and unofficial ones made by different people. Obviously because of this the performance changes per compiler.
If you were to talk just about the official compiler I'd say it's probably Fortran. It's very old but it's still used in most science and engineering projects because it is one of the fastest languages. C and C++ come probably tied in second because there also used in science and engineering.
In both Haskell and OCaml, it's possible to call into the language from C programs. How feasible would it be to create Native applications for either Windows, Mac, or Linux which made extensive use of this technique?
(I know that there are GUI libraries like wxHaskell, but suppose one wanted to just have a portion of your application logic in the foreign language.)
Or is this a terrible idea?
Well, the main risk is that while facilities exist, they're not well tested -- not a lot of apps do this. You shouldn't have much trouble calling Haskell from C, looks pretty easy:
http://www.haskell.org/haskellwiki/Calling_Haskell_from_C
I'd say if there is some compelling reason to use C for the front end (e.g. you have a legacy app) and you really need a Haskell library, or want to use Haskell for some other reason, then, yes, go for it. The main risk is just that not a lot of people do this, so less documentation and examples than for calling the other way.
You can embed OCaml in C as well (see the manual), although this is not as commonly done as extending OCaml with C.
I believe that the best approach, even if both GUI and logic are written in the same language, is to run two processes which communicates via a human-readable, text-based protocol (a DSL of some sort). This architecture applies to your case as well.
Advantages are obvious: GUI is detachable and replaceable, automated tests are easier, logging and debugging are much easier.
I make extensive use of this by compiling haskell shared libs that are called outside Haskell.
usually the tasks involved would be to
create the proper foreign export declarations
create Storable instances for any datatypes you need to marshal
create the C structures (or structures in the language you're using) to read this information
since I don't want to manually initialize the haskell RTS, i add initiallisation/termination code to the lib itself. (dllmain in windows __attribute__ ((constructor)) on unix)
since I no longer need any of them, I create a .def file to hide all the closure and rts functions from being in the export table (windows)
use GHC to compile everything together
These tasks are rather robotic and structured, to a point you could write something to automate them. Infact what I use myself to do this is a tool I created which does dependency tracing on functions you marked to be exported, and it'll wrap them up and compile the shared lib for you along with giving you the declarations in C/C++.
(unfortunately, this tool is not yet on hackage, because there is something I still need to fix and test alot more before I'm comfortable doing so)
Tool is available here http://hackage.haskell.org/package/Hs2lib-0.4.8
Or is this a terrible idea?
It's not a terrible idea at all. But as Don Stewart notes, it's probably a less-trodden path. You could certainly launch your program as Haskell or OCaml, then have it do a foreign-function call right out of the starting gate—and I recommend you structure your code that way—but it doesn't change the fact that many more people call from Haskell into C than from C into Haskell. Likewise for OCaml.
What is the current status of GUI programming with D Language? Are the language developers planning include GUI in the standard library?
The List (compiled from answers)
DWT (SWT binding)
GtkD (GTK binding)
wxD (wxWidgets binding)
QtD (Qt binding)
The most mature one is DWT, a port of SWT to D. There's also DFL and a whole host of bindings to GUI libraries written in other languages. Most of these aren't that mature yet, but DWT is. However, one thing to keep in mind is that D2 is on the horizon, so you might want to check whether the library is likely to be ported to D2 quickly.
I doubt that any of these will be included in the standard library anytime soon. The "official" standard library, Phobos, has a fairly minimalist attitude. The "unofficial" standard library, Tango, is not so minimalist, but still has a more systems programming bent to it. BTW, what's the difference if it's not in the standard library? I can see why this would be important for small, miscellaneous pieces of functionality where the effort to find, install, etc. a library for each one is significant compared to the amount of functionality the library adds, but not for big stuff like GUIs.
You might want to check out wxd, a wxWindows library for D.
It sounds like what you want.
From site dlang.org ( from FAQ dlang.org/faq.html ):
http://wiki.dlang.org/GUI_Libraries
I found to:
http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries
There are a list of GUI libraries and the status of them.
Finally, from http://www.dsource.org:
http://www.http://www.dsource.org/projects
There are a list of projects in groups.
One of group is named "Libraries-GUI".
I think there is a full list of GUI libraries for D language.
I think DWT looks like the most mature currently usable solution, especially if you need cross platform. As for a gui being included in the standard library, it is stated previously that it won't happen, neither for Phobos nor Tango.
Hybrid looks interesting (never tried that though). If you are a java dev then DWT is the natural migration from swt but otherwise I would recommend DFL. Have a look at the dsource list too and scroll down to GUI-Libraries.
I think it's a good thing that gui libraries are separate from standard library.
There is also on the works a binding for QT. Not useful at the moment, but it seems that is being done by QT engineers.
DWT now is not on dsource but on bitbucket: DWT2