.NET?

[_Gold_Fish]

Since I've started using Cobra, I've found that (to me, at least) there is one thing that I don't particularly like. And that is it's ties to the .NET framework. For a variety of reasons, I prefer languages that aren't tied down to frameworks, namely .NET.

So I'm wondering: are there any plans to, at some point in the future, move the Cobra language away from .NET?

[Charles]

The most recent back-end that I have worked on is Objective-C/gcc, but I cannot say when it will be done. There is also a JVM back-end, but it's stalled and I don't think it meets your requirements anyway.

I'm not interested in a "stand-alone" version at this point because that means we take responsibility for machine code generation, garbage collection, unicode string processing, threading, file i/o, profiler, debugger, etc. By leveraging Novell Mono and Microsoft .NET, those things are taken care of by others and in parallel to our efforts. We also get access to numerous third party libraries.

What other back-ends are you interested in?

[Charles]

On a related note, there are linkers you can get for .NET that will reduce your program to a native executable that can be distributed and run stand-alone. On the Mono side, they have similar tools out of the box.

I doubt this addresses your original concern, but it's a related bit of knowledge that other forum readers may find useful. An ISV of desktop software may use such a tool for example.

[_Gold_Fish]

What I am most interested in, personally, is a stand-alone version. However, the linkers you mentioned sound promising, I'll look into them.

[carlosqt]

To me, targeting an existing Runtime is definitively the way to go. It has tons of benefits (mentioned by Chuck) and also help you inter operate with other languages very easily.

Most of the new programming languages targeting the .NET CLR or the JVM are "implementations" or "variations" of an existing Native/Stand Alone programming language. For example: OCaml = F#, Lisp = Clojure and Python = Cobra, so I would say that if you like Cobra because of its syntax, then the way to go is Python (Native).

I would like to see Cobra for the JVM because I know Cobra generates C# code, I guess the JVM should generate Java code! Or if it is a separate version of the whole thing, then you can call it Jobra!

To be more explicit:
Python (Native)
IronPython (.NET)
Jython (JVM)

Cobra (should be Native)
IronCobra (.NET)
Jobra (JVM)

[Charles]

Just keep in mind that Python does ship with its own VM including garbage collector and interpreter. You're just trading a multi-language VM (.NET or Mono) for a single-language VM with a smaller community, as opposed to some strong notion of "going native".

[todd.a]

I like where Cobra sits right now running on top of the VM (leveraging is good). However, I would like to see a native backend (only a couple architectures is fine) because to me there still isn't a language that is beautiful, with consistent APIs, and gives full power (I don't think Go truly fits the bill). It might be too much to ask due to the mere fact that the syscalls vary across the systems. It is quite an undertaking, and even more so without a toolchain like LLVM, but there are scenarios where you want to get the VM out of the way (server side, embedded). Unsafe in C# addresses this to an extent.

If a full-fledged VM is to be used using a multi-language VM wins, hands down, for me. Native Cobra to me means spitting out an executable file format most likely with a small runtime embedded.

[torial]

One possible scenario (not sure how much effort this would require), would be to use CrossNet to convert .Net to Ansi C++.

http://crossnet.codeplex.com/

[agustech]

Another posibility is a Vala backend (somewhat "easy" as it has C# syntax). You will need to deal with some memory management though.

[Charles]

Yeah I looked at that. Although we would probably just do a gcc+gnome back-end the way that Vala does. And whether requiring gnome would satisfy _Gold_Fish's desire to remove the framework component is not known.

But I have not pursued a gcc+gnome back-end because no one seems to be doing one with full gc out of the box. I'd rather not go first as I'm awfully busy.