More details on Microsoft's new M# language(zdnet.com)
zdnet.com
More details on Microsoft's new M# language
http://www.zdnet.com/microsofts-midori-the-m-connection-7000024664/
52 comments
Look at that first graph "Safety & Productivity" vs. "Performance".
I have no idea how you can merge safety and productivity. People may be very productive in JavaScript, but I think "safety" means a bit more than "remember to use === and always have a reference handy because there are weird quirks in function X and Y".
I have no idea how you can merge safety and productivity. People may be very productive in JavaScript, but I think "safety" means a bit more than "remember to use === and always have a reference handy because there are weird quirks in function X and Y".
C# is a good example of a language that combines safety and productivity quite nicely, compared to e.g. JavaScript or Python. It's just about as expressive as those languages, albeit slightly more verbose than Python, yet its types provide more safety.
And that's just a start. I'm told that you don't need that much practice to get really productive with Haskell, while enjoying just about all kinds of safety that a language could provide.
In the case of M#, I believe that they want to add contract based programming to the core language to provide extra safety. That would mean that you can choose to use those features at those places where you think safety is very important, and choose to let them fly where productivity matters more.
And that's just a start. I'm told that you don't need that much practice to get really productive with Haskell, while enjoying just about all kinds of safety that a language could provide.
In the case of M#, I believe that they want to add contract based programming to the core language to provide extra safety. That would mean that you can choose to use those features at those places where you think safety is very important, and choose to let them fly where productivity matters more.
I would not agree, that C# is nearly as productive as Python. Have you ever programmed in Python? I doubt that!
There's a blog post I've been meaning to write that challenges your belief about C#, but comparing C# to Ruby. The problem is that idiomatic C# looks like Java, even though the language and .NET library allows you to code like idiomatic Ruby and Python. It's just that most people don't naturally code C# that way, even though you can.
Could be. But there is the crux: A language should guide the programmers to good use of the possibilities of that language. If it does not, what worth are they?
You also must define "idiomatic Python" or "idiomatic C#" first. I would recommend, that you first write your post and than commence with the discussion.
You also must define "idiomatic Python" or "idiomatic C#" first. I would recommend, that you first write your post and than commence with the discussion.
> "safety" means a bit more than "remember to use ===
yes, it means "type safety", i.e. strong typing.
Including the compile-time safety net that c#, python, Java et all have over c - you never pass a value typed as "void * *"; and that they have over over JavaScript - your code never gets an untyped object that you just have to hope has the expected methods or properties.
yes, it means "type safety", i.e. strong typing.
Including the compile-time safety net that c#, python, Java et all have over c - you never pass a value typed as "void * *"; and that they have over over JavaScript - your code never gets an untyped object that you just have to hope has the expected methods or properties.
I don't think you mean "python" in this list. Anyway, you're right most of the time, though you can end up in the same situation with "optimistic downcasting" (eg, get an Object as parameter, and downcast it to whatever it is you hope the concrete object is an instance of).
You may be right about python, I don't know it as well as the others.
> though you can end up in the same situation with "optimistic downcasting" (eg, get an Object as parameter
You can, though it doesn't happen much in practice. The complexity of the type systems (generics, interfaces, etc) are aimed in part at always allowing there to be a strong type.
> though you can end up in the same situation with "optimistic downcasting" (eg, get an Object as parameter
You can, though it doesn't happen much in practice. The complexity of the type systems (generics, interfaces, etc) are aimed in part at always allowing there to be a strong type.
Using void* in C/C++ is to explicitly disable type checking for something like byte buffer i/o. Another circumstance is in a broad interface such as a callback method that will pass along an argument. In the latter case a top-level interface like 'object' is essentially the same thing and in both languages you can create APIs that don't have these catch-alls. What's the wisdom behind wanting to be protected from this construct?
> have to hope
If you need hope, you're doing dynamic languages wrong.
If you need hope, you're doing dynamic languages wrong.
If anything, I'd think that C#/Java would be "safer" than JavaScript simply because they provide compile time guarantees that JavaScript does not.
Yeah exactly. I can't count the number of times I ended up with a broken web page and unhelpful error messages when the cause turned out to be some type error.
[deleted]
It's not a completely horrible post. It puts in one place some speculation that I have only seen in various outlets so far. I get the feeling that her citing "several different sources of mine" is just random posts by people on HN and Reddit.
I thought the M# name was completely made up during speculation, but it does indeed appear in the job posting [0] (you have to click the Job ID target 837005 to see the text) cited in this [1] reddit comment. (Edit: it's not entirely clear if M# and the language being discussed are the exact same language. I would assume they share some ideas, at least. Microsoft can't be _that_ fragmented, I would hope.)
The discussion thread on LtU hasn't pick up much steam, probably due to mid-holiday lull. I'm still a but confused about Charles Torre's comments re: HN/Reddit speculation. D and Rust were brought up in the the main source blog post [2], not by random speculators. He's right that we don't have "many of the details required to make intelligent comparisons", which is a shame. Charles also states in the comment
> "Joe mentioned his desire for openness for the technology (as in open source AND open communication/transparency). That we can have this conversation in the open means Microsoft is turning a corner vis a vis transparency. I hope this trend continues."
Let's see it then. Until then, there isn't much more to say.
[0] https://careers.microsoft.com/resumepreview.aspx?aid=111551
[1] http://www.reddit.com/r/programming/comments/1tvic1/the_micr...
[2] http://joeduffyblog.com/2013/12/27/csharp-for-systems-progra...
Edit: Tracing the various sources for parts of the speculation is interesting on its own. The various projects being cited show that Microsoft has spent a long time in this research space. I remember hearing about the Singularity OS [3] project at Microsoft, and wondering what we would see come out of it.
[3] https://research.microsoft.com/en-us/projects/singularity/
I thought the M# name was completely made up during speculation, but it does indeed appear in the job posting [0] (you have to click the Job ID target 837005 to see the text) cited in this [1] reddit comment. (Edit: it's not entirely clear if M# and the language being discussed are the exact same language. I would assume they share some ideas, at least. Microsoft can't be _that_ fragmented, I would hope.)
The discussion thread on LtU hasn't pick up much steam, probably due to mid-holiday lull. I'm still a but confused about Charles Torre's comments re: HN/Reddit speculation. D and Rust were brought up in the the main source blog post [2], not by random speculators. He's right that we don't have "many of the details required to make intelligent comparisons", which is a shame. Charles also states in the comment
> "Joe mentioned his desire for openness for the technology (as in open source AND open communication/transparency). That we can have this conversation in the open means Microsoft is turning a corner vis a vis transparency. I hope this trend continues."
Let's see it then. Until then, there isn't much more to say.
[0] https://careers.microsoft.com/resumepreview.aspx?aid=111551
[1] http://www.reddit.com/r/programming/comments/1tvic1/the_micr...
[2] http://joeduffyblog.com/2013/12/27/csharp-for-systems-progra...
Edit: Tracing the various sources for parts of the speculation is interesting on its own. The various projects being cited show that Microsoft has spent a long time in this research space. I remember hearing about the Singularity OS [3] project at Microsoft, and wondering what we would see come out of it.
[3] https://research.microsoft.com/en-us/projects/singularity/
Well, Mary Jo Foley is a well known blogger with sources deep inside MS, and has been right on so many rumoured things, I'd say her sources are a bit better than reading Reddit; the problem arises in trying not to burn those sources, so discussing public info and adding her extra knowledge to it is a good way of achieving that.
There is a post on G+ about the error model:
https://news.ycombinator.com/item?id=6983904
The author is participating in this reddit thread:
http://www.reddit.com/r/programming/comments/1tzk5j/the_m_er...
https://news.ycombinator.com/item?id=6983904
The author is participating in this reddit thread:
http://www.reddit.com/r/programming/comments/1tzk5j/the_m_er...
Thanks for the links. I saw that post on /r/programming earlier today, but hadn't investigated it yet. It'll be interesting to see some real ideas come out.
I believe in PG's "what languages fix" criterion, and I'm convinced that C will be displaced by a language which fixes multicore programming. You can do multithreaded code in C the way you can do structured programming in BASIC (or do OO in plain C): it's possible, because the language is Türing-complete and the required primitives are there, but the language is so unhelpful that it simply doesn't scale, and the only sane thing to do is to try and avoid doing it as far as possible.
(I don't mention C++, because it sucks as a high perf solution in the hands of the C++ programmers you can effectively hire: cf. e.g. http://harmful.cat-v.org/software/c++/linus)
Hence I'm more than puzzled that M# design doesn't seem centered on multi-core exploitation, including GPUs. Single-threaded Moore law is over, so robust concurrency is where performance gains are. They pay lip service to coroutines, because they know they have to, but that's hardly their main design constraint.
Go with its goroutines at least addresses the proper question, whether you agree with their proposed answer or not.
(I don't mention C++, because it sucks as a high perf solution in the hands of the C++ programmers you can effectively hire: cf. e.g. http://harmful.cat-v.org/software/c++/linus)
Hence I'm more than puzzled that M# design doesn't seem centered on multi-core exploitation, including GPUs. Single-threaded Moore law is over, so robust concurrency is where performance gains are. They pay lip service to coroutines, because they know they have to, but that's hardly their main design constraint.
Go with its goroutines at least addresses the proper question, whether you agree with their proposed answer or not.
"Türing-complete"
This must be the more metal version of the regular Turing completeness. \m/ :)
This must be the more metal version of the regular Turing completeness. \m/ :)
I just hope they'll make it available for non-windows platforms. Despite C# being a great language, being great only on windows is not attractive anymore.
If they are working on a language that makes distributed computing with all the arror handerling done for you as it reads, then I can see it has uses. At least that would obviscate one or two layers of framework you end up having to add.
Now the question not being asked and one area which would certainly open this up would be built in handerling and offloading onto GPU's. Certainly for what they appear to be designing then it would be something to factor in as the main drives for a distibuted system design would be for resiliance against loads or performance putting it crudely and on the performance front GPU's start factoring in earlier and earlier into designs. Though idealy you should be able to code away and have the compiler or some resource-profile file handle those aspects for you without adding another consideration/limit into your design.
Whilst many seem supprised that started with the C# base are maybe forgiting C# is Microsofts baby (they have more control over it) and whilst F# is also there remit the use of C# at the time and even now still points to a better user base more likely to embrace a upgrade so to speak. Also around the time they started this we were just embracing the ceailing of the monolyth CPU and GPU's were just around the corner. So a move towards making multi system and with that CPU's on a larger scale makes perfect sense and direction. Now given the length of time and the resources they have this was either a small pet project that matured or one that has gone thru many changes over its internal development. Maybe a bit of both, maybe that added in some GPU love, maybe not. But still, it does sound like an interesting language and if it has a level of Message Queue robust design for distributed computing built in then that alone would make this a nice robust off the shelf base language. Not that you cant add a framework or third party libary and code to get the same effect, just be nice to have that thinking and worry obviscated away from you as it just works. Heck if you do full error handerling for every aspect of fail in your code and its enviroment the simplest of Hello World programs tend to become much bigger (did the display work, did the user see the message, what if the program aborts mid message, how to restart on failure from aborts or power cuts....). Murphy has many avenues of saying hello to your nice program, removing some at any level is always welcome so will be interesting to see what they come up with.
Now the question not being asked and one area which would certainly open this up would be built in handerling and offloading onto GPU's. Certainly for what they appear to be designing then it would be something to factor in as the main drives for a distibuted system design would be for resiliance against loads or performance putting it crudely and on the performance front GPU's start factoring in earlier and earlier into designs. Though idealy you should be able to code away and have the compiler or some resource-profile file handle those aspects for you without adding another consideration/limit into your design.
Whilst many seem supprised that started with the C# base are maybe forgiting C# is Microsofts baby (they have more control over it) and whilst F# is also there remit the use of C# at the time and even now still points to a better user base more likely to embrace a upgrade so to speak. Also around the time they started this we were just embracing the ceailing of the monolyth CPU and GPU's were just around the corner. So a move towards making multi system and with that CPU's on a larger scale makes perfect sense and direction. Now given the length of time and the resources they have this was either a small pet project that matured or one that has gone thru many changes over its internal development. Maybe a bit of both, maybe that added in some GPU love, maybe not. But still, it does sound like an interesting language and if it has a level of Message Queue robust design for distributed computing built in then that alone would make this a nice robust off the shelf base language. Not that you cant add a framework or third party libary and code to get the same effect, just be nice to have that thinking and worry obviscated away from you as it just works. Heck if you do full error handerling for every aspect of fail in your code and its enviroment the simplest of Hello World programs tend to become much bigger (did the display work, did the user see the message, what if the program aborts mid message, how to restart on failure from aborts or power cuts....). Murphy has many avenues of saying hello to your nice program, removing some at any level is always welcome so will be interesting to see what they come up with.
""The idea is that M# should be the lowest-level language that you'll ever need. It sits at the very bottom of the stack. But it's also safe and productive enough to be appropriate for writing higher-level systems, like Web services," Bromfield added."
The above statement sounds decidedly like a programming-language version of the Forer effect: "it's like X, but it's also like the opposite of X!"
The above statement sounds decidedly like a programming-language version of the Forer effect: "it's like X, but it's also like the opposite of X!"
It's a bit timid of them to start from C#, I would have really liked if they had tried to build a system language starting from F#. Sure, an ML with no or optional garbage collection would be rather uncharted territory, but a man can dream.
> It's a bit timid of them to start from C#
Agreed.
> Sure, an ML with no or optional garbage collection would be rather uncharted territory
There is MLkit [1] (one of the inspirations for Rust), so it's definitely not uncharted. I don't think it broke free from GC, but it was a step in that direction.
[1] http://www.itu.dk/research/mlkit/index.php/Main_Page
Agreed.
> Sure, an ML with no or optional garbage collection would be rather uncharted territory
There is MLkit [1] (one of the inspirations for Rust), so it's definitely not uncharted. I don't think it broke free from GC, but it was a step in that direction.
[1] http://www.itu.dk/research/mlkit/index.php/Main_Page
> It's a bit timid of them to start from C#
Microsoft is a timid company. Any company in their dominant position (they own the corporate desktop) will avoid making anything very disruptive unless they feel they are playing a losing game.
Also, corporate-level C# developers are cheap and abundant. Much like Java was designed to be C++ developer friendly (and C# itself was designed to be Java developer friendly), it makes sense to design a new language to be more amenable to a large number of developers, even if it implies sacrificing some power.
Microsoft is a timid company. Any company in their dominant position (they own the corporate desktop) will avoid making anything very disruptive unless they feel they are playing a losing game.
Also, corporate-level C# developers are cheap and abundant. Much like Java was designed to be C++ developer friendly (and C# itself was designed to be Java developer friendly), it makes sense to design a new language to be more amenable to a large number of developers, even if it implies sacrificing some power.
I think the chart in this post makes more sense if you ignore the word "safety" on the Y-axis.
Here's an interesting interview with Joe Duffy:
http://www.infoq.com/articles/Joe-Duffy-Safe-Parallelism
http://www.infoq.com/articles/Joe-Duffy-Safe-Parallelism
If it sits at the bottom of the stack, and can run existing C# code (most? all?), then it must include the CLR, or something very CLR-like. That's a pretty big bottom.
Looks like there is already an M# language:
http://www.msharp.co.uk/
I wonder what the actual name will be..
http://www.msharp.co.uk/
I wonder what the actual name will be..
Why are they linking to a Vietnamese Reddit page?
I stopped reading at the first graph.
Worst language name yet?
Yawn
I agree, programmers are drowning in a wash of languages with one coming out every week. We have so many to chose from it's ridiculous. One that isn't even released is even more of a bore.
The defining feature with any language is the libraries and frameworks. And, let's face it: code samples on Stack Overflow and open source projects to rip apart and destroy.
The odd thing about M# is how it highlights the ridiculous bureaucratic nature of Microsoft. C# is great language, and MS has done a wonderful job of sucking programmers into the Windows black hole ecosystem. Instead of expanding C# to accommodate for their needs an internal teem has gone off on a tangent.
The defining feature with any language is the libraries and frameworks. And, let's face it: code samples on Stack Overflow and open source projects to rip apart and destroy.
The odd thing about M# is how it highlights the ridiculous bureaucratic nature of Microsoft. C# is great language, and MS has done a wonderful job of sucking programmers into the Windows black hole ecosystem. Instead of expanding C# to accommodate for their needs an internal teem has gone off on a tangent.
It's from Microsoft Research. Research that doesn't go off on a tangent is bad. Focus is for when you know what you want.
Furthermore, it's a little bit odd that when Mozilla explores that space with a new language, it's the hottest thing since sliced bread on HN, but this here gets drowned in snark. At the same time, the discussions on reddit (of all places!) are way more focused, technical and objective.
I know nearly zero about why people choose Rust or Go. But my best guess:
1) historical reason. Rust, according to Wiki came about 2010 and golang came around 2009. So they are pretty old languages by now, even though Rust is still only at 0.8 release.
2) catchy words like concurrency and memory-safe caught attention. The first + thing I heard about Go is concurrency, how the language supports concurrency and channels out of the box. Being a total Go novice (though have written a few small programs), I imagine this means I no longer suffer Python's GIL and I don't need complex multiprocessing module to launch my jobs.
Rust is memory-safe, a replacement to C++. It also support concurrency. Looking at the language's influence, looks like Lisp and Erlang hackers love them. My guess is people who deal with programming languages are often functional programming language lovers.
3) names plus practical examples. Google was going to use Go to replace some of their existing C++ apps. Rust is now used to implement the next generation of Firefox's layout engine, Servo, which is totally awesome.
Now comes the real question: "why another language?" Basically a language comes down to the application domain the language is trying to solve. SQL is to solve business application where persistency and data analysis are required. Now people are wondering what is the purpose of M# when C# and Java are good enough... as a general programming language. Yeah, I am totally stealing this from Compiler class on Coursea (just started my first lecture last night myself :)))
1) historical reason. Rust, according to Wiki came about 2010 and golang came around 2009. So they are pretty old languages by now, even though Rust is still only at 0.8 release.
2) catchy words like concurrency and memory-safe caught attention. The first + thing I heard about Go is concurrency, how the language supports concurrency and channels out of the box. Being a total Go novice (though have written a few small programs), I imagine this means I no longer suffer Python's GIL and I don't need complex multiprocessing module to launch my jobs.
Rust is memory-safe, a replacement to C++. It also support concurrency. Looking at the language's influence, looks like Lisp and Erlang hackers love them. My guess is people who deal with programming languages are often functional programming language lovers.
3) names plus practical examples. Google was going to use Go to replace some of their existing C++ apps. Rust is now used to implement the next generation of Firefox's layout engine, Servo, which is totally awesome.
Now comes the real question: "why another language?" Basically a language comes down to the application domain the language is trying to solve. SQL is to solve business application where persistency and data analysis are required. Now people are wondering what is the purpose of M# when C# and Java are good enough... as a general programming language. Yeah, I am totally stealing this from Compiler class on Coursea (just started my first lecture last night myself :)))
> when Mozilla explores that space with a new language, it's the hottest thing since sliced bread
I'm all in for new languages that solve unsolved problems (or solve better problems other solved). When Rust came out, it was new and exciting. When Go came out, it was new and exciting. This one is new and plans to solve some problems Go and Rust already solved. It'll be exciting if it solves them better. Right now, we know nothing about it.
From the list in the blog post, the only problem M# (or whatever it's called in the end) solves other languages haven't already solved is what to do with all the C# developers we have out there. It's not a problem I am very excited about.
I'm all in for new languages that solve unsolved problems (or solve better problems other solved). When Rust came out, it was new and exciting. When Go came out, it was new and exciting. This one is new and plans to solve some problems Go and Rust already solved. It'll be exciting if it solves them better. Right now, we know nothing about it.
From the list in the blog post, the only problem M# (or whatever it's called in the end) solves other languages haven't already solved is what to do with all the C# developers we have out there. It's not a problem I am very excited about.
It is a tragedy based on corporate interests (Microsoft's interests to tightly couple C#/F#/.NET to its other software offerings and Apple wanting to promote its own proprietary solutions instead) and primitive, tribal bigotry (Linuxheads categorically boycotting anything tainted by Microsoft's touch).
I suggest that people who do OO/GCed/imperative programming but not (exclusively) on the MS stack stay away from C#, because it is so depressing to realize that this great language (the best in its category by far) is so poorly supported by everything not Microsoft.
I have the same problem with Objective-C. The idea of minimal, Smalltalk-ish OO extensions on top of C appealed to me but try using it on anything not Apple... so sad.
M# is already doomed. Don't waste your time with it unless you see yourself developing software exclusively targeting the MS stack. It will never get anywhere on other platforms, no matter how brilliant it turns out to be.