back to article Microsoft reveals xlang: Cross-language, cross-compiler and coming to a platform near you

Language interoperability efforts are underway at Microsoft in the form of the open-source xlang, which builds on the approach taken with WinRT. The Windows Runtime (WinRT) is a noble attempt to replace the grungy C-based Win32 Application Programming Interface (API) with something delightfully object-orientated in C++. It …

  1. Destroy All Monsters Silver badge
    Paris Hilton

    Kerr Black Hole!

    So is this like Apache Thrift

    "Apache Thrift allows you to define data types and service interfaces in a simple definition file. Taking that file as input, the compiler generates code to be used to easily build RPC clients and servers that communicate seamlessly across programming languages. Instead of writing a load of boilerplate code to serialize and transport your objects and invoke remote methods, you can get right down to business."

    (RPC? I prefer messaging, but RPC is ok if it stays on the same machine and best in the same process and you can live with having really tight binding in the application.)

    1. Def Silver badge

      Re: Kerr Black Hole!

      There are plenty of interface definition languages/systems out there today, and they're all pretty much shit.

      I'm guessing (no, of course I haven't checked out the code to see for myself) this basically automates the whole thing by storing interfaces and call information in a side channel of data in whatever library/executable you're producing, and uses that data to transform calls from other languages at runtime (or maybe even at compile time if you have that option) so that they just work.

      Which sounds pretty cool if you ask me.

      And would be a hell of a lot better than either implementing a C-based public API if you're a library writer, or dictating the language users of your code must use, or dicking around with your least hated IDL/RPC/RollingYourOwnShit to get processes talking to each other.

      Presumably the big pay off here would be having OS APIs (or any library really) immediately available in any language that the system supports without all the tedious fucking around implementing support. You'll basically end up with language choice being pretty much irrelevant when it comes to writing and releasing code.

    2. Steve Channell

      SWIG

      This is much more like SWIG than Thrift because it s an interface generator, not an RPC mechanism.

      inferring that that std::vector<T> can be translated to Systems::Collections::Generic::List<T> is usefull, but only really an advantage if it avoid copying when passed into another function that expects a std::vector<T>

  2. Daniel von Asmuth Bronze badge
    Windows

    Only Microsoft can kill Windows (Win32)

    Once upon a time on the far shore of the ocean, there was PC-DOS and it was hand-crufted in glorious assembly language. Then came Win16, which supported C and Pascal, Followed by Win32 and Win64, which mostly supported C. Like Prince Charles, Windows .NET and C# are the designated successor in waiting (or was that Midori?), and now in the name of ESR, Redmond wants you to switch to C++ anda new OS API. (where is the documentation for the NT kernel?)

    1. AMBxx Silver badge
      Stop

      Re: Only Microsoft can kill Windows (Win32)

      Probably best to ignore this one too. There'll be something else arriving in a couple of years.

    2. bombastic bob Silver badge
      Coffee/keyboard

      Re: Only Microsoft can kill Windows (Win32)

      yeah, and from the article:

      "The Windows Runtime (WinRT) is a noble attempt to replace the grungy C-based Win32 Application Programming Interface (API) with something delightfully object-orientated in C++"

      El Reg: I hope you had your *snark* hat on when you wrote that. See icon.

      From what I saw, it is *WORSE* than ".Not" with it's bass-ackwards "oh look, we have OBJECTS now" approach.

      The worst programming assignment EVAR (for me) was cleaning up code written by a drunk [who was a partner in the company at the time he wrote it, and was subsequently bought out - did I mention he had once worked for SAIC doing 'bill by the line' stuff for them?], in Borland C++, for Windows 3.x, in which the author had "discovered" that C++ had *CLASSES* in it!!! So you can guess that EVERYTHING was a class, and interestingly enough, they were so bit-fiddly with one another's internals that you'd have to reboot that poor Windows 3.x box every time you ran the application, because the resources would be depleted. (I managed to get it working anyway, to an acceptable level, with only occasional resource leaks)

      And so, when I hear about Windows RT's "wonderful world of objects" or whatever, I spit up my coffee all over the keyboard. Replace Win32? With *THAT*???

      HA HA HA HA HA HA HA HA HA HA HA HA HA HA! Yeah, I hope you had your *snark* hat on!

  3. Sir Crispalot

    Stupid conflicting name

    Not a great choice of name considering it is barely distinguishable from an existing language used in BizTalk, XLANG/s.

    https://docs.microsoft.com/en-us/biztalk/core/xlang-s-language

    I can already see the confusion on StackOverflow...

    1. Tim99 Silver badge
      Windows

      Re: Stupid conflicting name

      It’s what Microsoft do: IMAP/MAPI, OpenOffice/Microsoft Open Office, Office Open XML/Microsoft Open XML...

      1. Deltics

        Re: Stupid conflicting name

        How did .net Core not make the list ?

        I mean, .net Core is at the core of .Net right ? Oh no wait, that would be .Net Standard, which is the thing which everyone has been running for the past nigh on 20 years right ? Oh no, wait that's .net Framework. Standard is the common pieces shared between .net Core and .net Framework.

        So we have .net Core which isn't at the heart of .net Framework and both of which are SUPER-sets of .net Standard which isn't the (previous) standard .net that everyone has been used to.

        :sigh:

    2. bombastic bob Silver badge
      Devil

      Re: Stupid conflicting name

      'xlang' - it's maybe supposed to be similar in appearance to 'clang'?

      that was my first guess, anyway. I also face-palmed at the *OBVIOUS* 'Embrace Extend Extinguish *EX-TER-MIN-ATE*" coming down the pike behind it.

      /me uses clang with FreeBSD. I find it a little refreshing compared to gcc, particularly in the way it deals with cross-compilation, and of course, no GPLv3-related licensing problems. It also has some more interesting warning generation that occasionally spots things that gcc misses.

  4. Anonymous Coward
    Anonymous Coward

    Urp!

    "... caring, sharing Microsoft ..."

    That was lunch.

  5. JohnFen Silver badge

    GCC?

    I've been using a cross-language, cross-compiler for many years. It's called GCC.

    1. karlkarl Bronze badge

      Re: GCC?

      Yeah I don't see the problem here. C / C++ is pretty much platform agnostic these days and then just ifdef the platform specific stuff. Ignore vendor lockin crap like Java/C# and cross platform code is within everyone's grasp.

      If you avoid crap like Python, you don't even need to frig about with bindings either.

      Life is good if you cut out the bullsh*t and just use C or C++ :)

      Edit: And if a locked down platform like Windows RT doesn't support standard C or C++... you jail break that broken crap until it does. :)

  6. SVV Silver badge

    Can't do cross lnguage, cross platform interoperability at function level

    Unless every language and every platform includes every feature and every concept found in every language and platform, you can't. You just can't. You can get somewhere down the road of doing it, but the cost of getting it to work completely is unknowable for any given combination.

    1. bombastic bob Silver badge
      Meh

      Re: Can't do cross lnguage, cross platform interoperability at function level

      I found a few reasonable ways to approach true cross-platform applications in C/C++:

      a) Use Qt

      b) Use GTK

      c) Use wxWidgets [and, with some creativity, you can take an existing MFC application and turn it into a wxWidgets application with a 'relatively small sized' effort.

      d) a C language toolkit I've been working on for a while, now

      and plenty of '#ifdef WIN32' and similar blocks around system-dependent stuff. But it's not all that hard, really.

      No need for UWP or its new replacement. No need for RT. No need for ".Not" or C-pound or that disease-sounding 'mono' thing. Or ".Not Whore" (aka '.Net Core').

      (now, where's my clue-bat?)

      1. Anonymous Coward
        Anonymous Coward

        Re: Can't do cross lnguage, cross platform interoperability at function level

        @Bombastic Bob

        *

        I've found Glade/Python3 to be pretty OS independent....(and going by other comments here, not to everyone's taste). Not perfect, and maybe not fast enough for some things....but pretty good all the same.

        1. Anonymous Coward
          Anonymous Coward

          Re: Can't do cross lnguage, cross platform interoperability at function level

          P.S. I don't need cross-language. I wonder who does.

        2. bombastic bob Silver badge
          Devil

          Re: Can't do cross lnguage, cross platform interoperability at function level

          yeah for a lot of things Python definitely has its uses. Underneath you'll probably find one of those toolkits I mentioned, though... (especially for GUI applications)

    2. Anonymous Coward
      Anonymous Coward

      Re: Can't do cross lnguage, cross platform interoperability at function level

      "...cross l[a]nguage, cross platform..."

      What we really need are calm languages & platforms.

  7. DrXym Silver badge

    Not a new thing

    Lots of languages can "bind" to others, usually by providing the means to link to static C libraries or call C functions dynamically. Usually this entails somebody or some tool producing a bindings file which allows the caller to understand the structs and functions used by the implementation.

    I suppose if it were possible to export a language neutral definition of an API as part of the build, then theoretically any other language could consume that definition without somebody having to write a bunch of bindings.

    I should note this wouldn't be the first time Microsoft have tried this. It used to be possible to import a type library (.tlb file) into C++ and call OLE objects whose interfaces were automatically produced by the compiler. It wasn't necessary to know what language implemented the objects because it was all COM/OLE.

    1. Deltics
      Coat

      Re: Not a new thing

      Yeah, but that stuff is about 25 years old now, so cannot possibly be any good.

      Besides, .NET "killed" COM so for the last 20 years COM hasn't been cool, meaning we have a new cohort of developers who can re-invent this wheel all-over again and think it's new. Sadly they will likely fail to learn from previous iterations because - again - it's old so is either forgotten or immediately discarded as irrelevant with nothing to teach us.

      I wonder why is this industry seemingly so uniquely susceptible to this tendency to reject the past instead of learning from it ?

      1. fajensen Silver badge

        Re: Not a new thing

        Besides, .NET "killed" COM so for the last 20 years COM hasn't been cool, meaning we have a new cohort of developers who can re-invent this wheel all-over again and think it's new.

        They didn't kill it off, they just wrapped it! Many years ago I was paid money to write a tool to automatically insert graphs of process data into a powerpoint slide deck.

        There are many easier "open-source"-ish ways to do this, but no, this tool *Had* to be 100% pure Microsoft+Windows. So, .NET is was, except, except: For some critical functionality, possibly the creation of the graph object, one had to burrow down and call COM "By Hand", using the ancient windows "handle"-syntax and all!

        I wonder why is this industry seemingly so uniquely susceptible to this tendency to reject the past instead of learning from it ?

        Most IT projects fails miserably. People don't want to remember stress, failure and pain so they eventually become Pavlovian-Conditioned to always "look forward"?

    2. LDS Silver badge

      "then theoretically any other language could consume that definition"

      That was what COM tried to achieve (and before it, DCE RPC, on which a lot of COM is based).

      The issue are not languages who have compatible data types - usually compiled languages that use the underlying CPU types, and their in-memory structures are quite "simple", and can be easily addressed using pointers - the issues are often in the interpreted ones (and some vm ones), where data type often have their own representation, and can't be easily passed around.

      You can see it easily with "string" types - even compiled languages where the "string" type is native can use different ways to implement it internally - so they are not compatible across calls into different ones (but maybe as read-only buffers).

      That's why COM had its own datatypes and all that marshaling stuff to convert them to and from, giving each side of the call something it can use.

      Another attempt is doing what XML and JSON do - turn everything into some character-based format, and still needing code to convert to and from (which is usually far less performant than using native types when possible).

      Of course, if you can force different languages to abide to a common standard, it's much easier.

  8. Anonymous Coward
    FAIL

    And in further news...

    2019 - Microsoft cancels xlang, advises developers to "do one".

  9. RLWatkins

    "Oh, sure, we've got one of those...."

    The above is the MMM: the Microsoft Marketing Mantra.

    Normally Ms do it an a (sometimes successful) attempt to claw bits of market share back from small startups: "Oh, sure, we've got one of those. It ships with Windows." Done with media hubs, graphics editors, object-based databases, the list goes on and on. And occasionally, after ten years or so, they manage to make the puff of smoke into a real product.

    More often they just blather along in that vein until something else captures people's attention.

    But in this case they aren't going up against some small startup, they're trying to jump on a bandwagon that left them behind decades ago. 'JohnFen' is right: We have GCC. We have multi-platform BC-based languages like Python and Java. Hell, we have Mono, which runs C# on nearly anything. (I clearly recall Ms' efforts to stuff that genie back into its lamp.)

    Had 'em for ages. Going to stick with 'em because Ms will likely lose interest before they have anything useful to sell us.

    Let's say it all together: IT'S BEEN DONE.

  10. macatari

    "early Alpha?"

    If you actually want to use a cross-platform language today rather for yet another Microsoft tech to never come to be, then check out Xojo. It makes apps for Windows, Mac, Linux, Raspberry Pi, iOS and web. With Android in development. It's been around for 20 years and is in continuous development and production-ready today, not in some unspecified future timeline.

    http://www.xojo.com

  11. devTrail

    First thing I thought when I read the title was that they wanted to copy project Graal, but when I read the article I realised that the scope is too narrow. So. How many people could really find any use for such project?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019