Printable View
Phoronix: Nuanti C++ Compiler For More .NET On Linux
While Mono is widely known for bringing Microsoft's .NET to Linux, there also exists a separate compiler that's about supporting the Microsoft C++/CLI ECMA-372 language specification under Linux...
http://www.phoronix.com/vr.php?view=MTA4Njk
It's nice to hear that we can (finally) use managed C++ with linux.
However this is just coming from a conference talk. No download button - no certainty that it will actually ever be open sourced. I wonder how production stable that thing will be.
Furthermore the only link on their blog post is a recruting advertisement.
Hope the opensource community will see the compiler soon.
A quick inspection of linux-related media chatter makes it appear that .NET-on-linux is on it's way out. I'd rather read articles about progressive and emergent technology.
Here ya "go": http://blog.golang.org/2012/03/go-ve...-released.html
I'd rather read articles on technologies that are already deployed, and are yet still seeing improvement...which is actually what this article is. I've been wanting to read about C++/CLI on Linux for a long, long time now. Thank you.
And where is the evidence for Mono being phased out? I assume this chatter isn't from the likes of insignificance.
While there are some things I love about Go, it's hardly the next great thing. Like just about every other "C++ is too gross let's make something new" language project around, it still utterly sucks at half the things I actually need a low-level C-like language to do. And if you don't need low-level coding and C-compatibility, there is absolutely no reason to use anything less than a true high-level language.Quote:
Originally Posted by russofris
Literally, Go is utterly useless to me as a game developer. There is not one thing is does that C++ does not which I need (I'd like structure based typing, but templates remove a hard need for it at the grammar level) and there are many things C++ does that Go does not and probably never will.
This is a similar story to D, although D at least adds useful things that C++ lacks and is only missing a precious few key C++ features (unfortunately, it intentionally misses those by design, so it too is stuck in a "will never quite be good enough" limbo).
But let's just compare C# to Go:
- Only C#, not Go, has an extensive array of developer tools that literally and unarguably beat the snot out of the dev tools for every other major language.
- Only C#, not Go, allows user-defined types that can behave as native types.
- Only C#, not Go, has highly useful language features like LINQ, nullable types, delegates, generics, etc.
- Only C#, not Go, has a massive standard library allowing devs to immediately start writing useful code rather than needing to reinvent wheels or hunt down third party modules of unknown quality.
- Only C#, not Go, has CodeDOM to facilitate new and amazing code transformations and building new dev tools, DSLs, and prototype features rapidly.
- Only C#, not Go, is supported by multiple commercial vendors.
- Only Go, not C#, structured typing, which is the only "progressive" feature Go has at all (although Go is hardly the first language to have it).
- Both Go and C# support easy and efficient threading and inter-thread communication, although only Go built all of that into the grammar instead of bits in library code where it makes sense to do so.
Go is a pretty academic-style language. C# (and C++, as C++/CLI) are real-world languages built to solve technical problems that cannot be solved without them. Go breaks compatibility with existing code and libraries and in exchange gives you a new type system that's kind neat but not vital and a new threading model that you can build as a library for any other language.
Soooo... where's the code?
Great to hear about this, I might actually be able to put this to use as a porting tool. Maybe. C++/CLI code in, portable .NET assembly out... sounds nice for porting to Linux when the source doesn't build cleanly with gcc. Not sure how well it'll support my specific use cases though, as I'm sure it doesn't emulate the Win32 API or anything like that. I'd probably be better off using winelib.
I don't think this has anything to do with Win32.