A glimpse into a new programming language under development at Microsoft
lambda-the-ultimate.org
lambda-the-ultimate.org
But there's a huge downside: C# only works on Windows. This vastly reduces the number of things you can do with it (yeah, I know about Mono). There's nothing here that suggests that this would have anything other than the same restrictions. So, assuming the language develops into everything that's promised, you're left with something on which you can't do mobile, can't do big data, probably won't work very well for scientific computing. In fact, basically you're still stuck with the same LoB apps and ETL tools that C#'s already great at. And probably the same second rate (not awful, not great) web experience.
So the best you can hope for, basically, is a better C#. But not good enough to take on Java.
Don't get me wrong, it sounds exciting, but equally I worry that it'll be used as a way to generate patents to prevent the ideas being used elsewhere in environments where, tbh, they'd find more use.
I completely agree and I only hope that this new thing will be just as good as C# but fully cross-platform. It would be great.
>mobile
Xamarin is pretty solid, although it costs a lot.
I had it building on FreeBSD back then!
They did the right thing for them but not the community. Isolation and ecosystem ate tightly controlled at Microsoft and always have been. It's how devdiv remain scarily profitable.
And that's despite my assumed bias, because I work at JetBrains.
What I mean by that is, when will it go 1.0? When will we see a major project from Jetbrains implemented in it?
Kotlin has been around for a couple of years now and Jetbrains still won't answer these questions as far as I can see[1].
* If you read the link, there is no guarantee of backwards compatibility to the current point within future releases. This is why they're still in milestones.
* Jetbrains has yet to show us that they are, themselves, committed to Kotlin by implementing something major in it.
* They won't provide a timeline for 1.0.
I love thinking about and toying with new languages, but when it comes to sitting down and doing stuff, I need to know the environment has enough commitment such that I don't have immediate code rot.
* no regex literals
* a little verbose(instead of [] for arrays, it's "Arrays")
* hashes IMO should be JSON
* why doesn't null evaluate to false? God I hate writing if (a != null). I'm much happier in javascript/ruby/groovy land where if can type "if (!a)" or "unless a" or even cooler "raise Exception("a should not be null") unless a"
* why did the world standardize on camelCase instead of snake_case ? the world was wrong about this!
basically a little more javascript and ruby influence would have been good. make the language more "fun" and expressive. There is no equiv of the ||= operator or | for joining arrays, etc
But the big things it's missing are more ecosystem features: * REPL
* an alternative build system (please don't make anyone use maven!) should be an interpreted scripting language. I'd look at Rake or Gradle for inspiration
* rails like web framework
It is a statically typed language designed to try to drag java programmers kicking and screaming into the 1970s. Virtually everything you listed would be a bad change. Just use a language that is actually similar to what you want.
btw being a jerk doesn't help your case.
lesson in civil discourse by example: "I don't think that a ||= operator is a good idea because XXX"
What's wrong with Mono? I worked with C# only briefly and I really liked it (as opposed to Java.. but maybe I just had better tools). If I'd need something a bit faster than python, C# would probably be my choice. That's assuming it's portable to other platforms...
Once you go down the pain of getting Mono to run on Linux...you may as well have just written your program in Java (or something else).
While I loved working with C#, once we moved down the path of moving off Windows platform, it's just easier to learn a new language and change your tooling.
What's painful about 'apt-get install mono-runtime mono-mcs'? (or your distro's equivalent)
Its main target platform is/was Linux.
But once you started needed ASP.NET MVC, specific database drivers and setup, it become non trivial quickly, especially since stuff isn't as well documented as most other mainstream open source techs...
Edit: Also, to try and help our transition to running on Linux easier, we even integrated ServiceStack for a lot of the database drivers into the app. (Note: ServiceStack is one seriously great library if you are working in .NET-land)
Edit: Adding, that if I'm going to go through all this trouble to have a sub-set, and not-up-to-date version of the .NET framework and it's ecosystem to run as open source, I'd rather just use Java, and it's full ecosystem and be done with it.
Also, using MonoDevelop on my Mac was very uninspiring.
I am sure C# is the "Next Main Desktop App Dev. Language". I really wish MS would OPEN-SOURCE it one day. You can read article in my blog about that here (really short): http://anthonyakentiev.github.io/blog/2013/12/08/what-if-see...
I wish C# will be used freely everywhere - on Apple, on Android, on Linux... Really - Mono/Xamarin does not have a full .NET/CLR/C#/frameworks support.
First C++11 which added lots of interesting stuff. (Lambdas, move constructors, threads as part of the language spec, better smart pointers, and more.) Most of this was added in a very clever "C++ way" - for example lambdas that can be inlined as functors and can take advantage of copy constructors and RAII kind of blows my mind. Major compilers picked it up pretty quickly. Already people are talking about C++14.
I will agree that its history makes it a sort of Byzantine language (I really prefer the simplicity of C for a lot of things), but there is a lot to be optimisitic about for C++ in the last few years. With the latest standards and best practices the language it ought to have been for a long time is finally getting out.
"Finally, you might wonder, “Why not base it on C++?” As we’ve progressed, I do have to admit that I often wonder whether we should have started with C++, and worked backwards to carve out a “safe subset” of the language."
...
"I do expect to take our learnings and explore this avenue at some point, largely for two reasons: (1) it will ease portability for a larger number of developers (there’s a lot more C++ on Earth than C#), and (2) I dream of standardizing the ideas, so that the OSS community also does not need to make the difficult “safe/productive vs. performant” decision."
"But for the initial project goals, I am happy to have begun with C#, not the least reason for which is the rich .NET frameworks that we could use as a blueprint (noting that they needed to change pretty heavily to satisfy our goals)."
[1]: http://webcache.googleusercontent.com/search?q=cache%3Ajoedu...
Speaking of Mono, does anyone know of a good resource for C#/.NET devs to learn how to port their Windows apps to Linux/Mac relatively easily?
I did a writeup a month ago about my first impressions of Mono: https://news.ycombinator.com/item?id=6744622
In short, there don't seem to be very many "Here's how to write cross-platform C# code that runs on all three platforms without much effort" type resources. It seems like most Mono newcomers will find it difficult to get up and running, especially if you've been developing your app with Visual Studio 2010 or later. So it seems like there aren't very many good tutorials written specifically to teach Windows C# devs how to quickly get up to speed with Mono.
After spending some time researching the idea of writing GUI apps using C# and Mono, I gave up because it just didn't seem straightforward. Maybe I was going about it the wrong way, but it seemed like Python + Qt bindings would be a more effective approach, even though you lose out Visual Studio's awesome GUI designer. But I haven't actually tried python+qt yet on all three platforms, so maybe it isn't as easy as it seems. And my Qt knowledge is somewhat dated, so maybe there's a better solution nowadays.
Does anyone have any recommendations for the easiest way to write cross-platform GUI apps that can run without an internet connection? I was thinking maybe making it a webapp, but the offline requirement seems to rule that out. (Has localstorage progressed to the point where people can start up a browser "app" without an internet connection? I haven't looked into it for awhile.)
Plus I'm not sure how easy it is to write custom webapp GUI objects compared to the fantastic ease of writing custom .NET GUI objects via the VS GUI designer. Although anything that lets you quickly and easily write powerful GUI apps that run on all three platforms would be pretty fantastic. What toolset would you use to get the job done?
EDIT: Hmm, just thought of another idea... Would Clojure work well for writing native GUI apps? It's based on the JVM, so it seems like it could leverage existing GUI libraries. (All the Java GUI libs used to suck, but maybe the situation's improved now that Clojure is popular.)
Might be worth trying out. You can still run your application on Microsoft's .NET stack on Windows, GtkSharp supports it just fine, and because it uses GTK it will look native on all of the supported platforms.
Disclaimer: I haven't actually tried any of the above.
At first, I ran with the Mono reimplementation of Winforms on Linux. That didn't work very well. There are a lot of little incompatibilities, like differences in how keystrokes are translated, and very buggy text boxes.
So I reimplemented the UI in Gtk-Sharp. That was mostly a matter of translating existing Gtk documentation to the OO API presented by the C# wrapper. I could write this in Visual Studio and run using Gtk on Windows to test; Mono itself wasn't actually needed here.
I then ran the app using Mono on Windows. Once all the DLLs were in the right places, it mostly just worked. Running it on Linux - specifically, Ubuntu 12.04 LTS - was a little trickier, as Ubuntu has split out many of the different assemblies into separate packages, and you have to grovel around a bit to get what you want, if you don't want everything. But again, it mostly just worked.
Compiling using Mono took a little bit of figuring out - mainly, finding out I had to use dmcs rather than mcs or gmcs to enable the right language features. But again, once the right assemblies were referenced on the command line, it mostly just worked.
Writing a cross-platform app in Mono? I wouldn't really try that. Having a separate UI layer for each platform gets you a much better experience. Gtk programming itself is extremely clunky compared to Winforms, which itself is quite clunky - albeit in different dimensions - compared either with Delphi's VCL or WPF. But it was the only way I could see to go to get a reasonable experience on Linux.
Granted, for many people, it's about as hip as Rails is to a newly converted node.js fan, but Tcl and Tk are still a pretty good way of writing smaller apps that run cross platform. Like someone else says, if you want a native GUI, you really need to write that separately for each platform. But that's a big investment, and for some systems, it might not be worthwhile.
Look at an actively maintained solution like Xamarin or Unity; Xamarin lets you write your UI specific code for each platform; Unity lets you share UI across platforms but you won't get a 'native' look and feel on any.
For both of these you won't be able to use the majority of existing .Net infrastructure (nlog, nject, nhibernate, etc) because they are locked into the windows CLR, but there are a few ports and you can often get away with compiling the source from codeplex yourself (the prebuilt DLLs just wont work).
(Unfortunately, porting your existing application is absolutely out of the question in most cases, for the reason above. Perhaps if you've carefully isolated concerns it might be possible...)
I have just started working on GUI apps with Clojure and the story is much better so far! Seesaw[0] definitely slims up the Swing code, and I've been using Core.Async[1] to remove a lot of the callback handlers. So far, so good. :-) It's definitely worth looking into.
Seesaw is the only reason why I'm still bothering with Swing too, it actually makes the thing fun to use!
Swing is used by two kinds of people: developers, because the tools that use it are just too good to go elsewhere (IntelliJ etc) and enterprise users that have it forced upon them.
I don't think anybody is using Swing willingly -- or enjoying it. Besides the "uncanny valley" effect to native widgets, it suffered from the start from the main negative of Java's culture: it was overengineered. On top, it underdelivers in many areas.
The only cross-platform GUI toolkit that I loved working with and that does a much better job than Swing is Qt. Unfortunately Qt is C++ and it's not even standard C++. So language bindings are hard to build and (compared with Gtk) working with C++/Qt is not so painful. The bindings for Mono are dead. Trolltech released at some point Qt Jambi, the Java bindings, which were awesome, unfortunately the Java community hasn't been interested in it, so Qt Jambi also died after Nokia acquired Trolltech - for the moment at least (the wonderful thing about open-source stuff is that it can be revived with enough interest). The only well maintained language bindings for Qt is PyQt.
And yes, building the UI using the platforms native stuff yields better results, but it's also more expensive to do so. We're all moving in that direction anyway, given the emerging mobile platforms. Sometimes I'm thinking that for desktop apps it's just better to embed a web browser and build the UI with HTML/CSS and JS.
Both statements I agree with!
I think it's a sad state of affairs, that the tens of billion s IT industry, and the whole OSS community, cann't produce, and maintain, a decent, cross platform UI, based on C with hooks for various languages.
GTK has dropped the ball even on Linux (Mac/Windows support is crap, and the library is essentially what it was 10 years ago content wise).
wXWidgets is at the same level more or less.
QT is nice, but is C++, so you either by into the whole thing or you face the not so good support and bindings to other languages (Python has the best support, but even that is mediocre).
Mozilla's XUL was never wrapped and maintained properly (as once promised), to be use to use for cross platform development.
SWT needs Java, and is too tailored to Eclipse's needs.
I, for one, don't need native look in all apps -- I could do with something like the cross platform widget library Adobe built for Lightroom -- that and a webkit view.
Just out of curiosity, what other gui tool kits have you used that you compare Swing too? I always wonder what gui toolkits those who decry Swing have experience with.
Myself, I've used Win 32 api, MFC, SWT, and gtk. Imo, Swing is by far the best of those; relatively consistent api, a wide variety of widgets, customizable, ... True it can be very complex (ie editor kits) and some things are/were missing for a long time (close buttons in tabbed panes). Also true that it doesn't look 'native' on all platform, but no gui tool kit can. I have not used Qt, but it seems to be equivalent to, or surpass Swing in all those areas.
I've used Cocoa, GTK on Linux, and Windows Forms (or whatever .NET v1 and v2 had called) in Windows. Have also used Swing.
Quality of results wise, Cocoa beats them all down, but single platform unfortunately. The .NET solution was also nice, but limited to a single platform too. (I know of, but don't care for small-time hacks to make Cocoa/.NET play on other platforms, only for officially supported projects).
Swing had been a pain in the ass to create UIs with, overengineered, with missing functionality (how long did we have to wait for a HTML control?) and ugly too boot.
Swing has one thing going for it: it does work on all platforms. I just wish it was better designed (API wise), more complete, and less uncanny valey-ish.
It's hardware accelerated, so I can write my own custom GLSL shaders for the UI, which is pretty cool. I bet I could even implement a Mario-style game using Kivy. The main application window is just a GL context, and all the UI widget rendering is done via GL.
Unfortunately the Kivy UI seems to be riddled with bugs, and the UI widgets themselves are very alien. For example, the Kivy file browser widget seems to be incomplete (it lacks basic features) and confusing (it behaves nothing like a native file selector). So Kivy is probably too jarring of an experience for users... if I use Kivy in its current form, all my users would balk at the unintuitive UI, since Kivy's widgets don't look or feel anything like native platform widgets. And since users would also be fighting Kivy's UI bugs, I predict every user would immediately ragequit my app. (E.g. drag-selecting text within multiline textboxes seems to be broken, etc.)
That said, Kivy is very close to being an effective way to effortlessly write crossplatform GUI apps. The main reason to use Kivy is because it's so easy to write useful apps with it. I wrote one in about 15 minutes from start to finish. The API is a pleasure to use, and the data binding design is especially brilliant.
Kivy seems pretty fantastic for writing internal tools. Data visualization via Python is now a cinch thanks to Kivy. For example, it'd be easy to write an app that shows the current status of all your server instances. And of course at that point it'd be easy to extend your app's functionality with features like "right click on a server instance to spawn an SSH session into it". Stuff like that is a breeze thanks to Kivy.
Time to try out everyone else's suggestions. Up next: Clojure + Seesaw. (This thread has been incredibly helpful... So many interesting ideas. Thanks, everyone!)
I ended up doing the multi-touch UI in JavaScript and HTML instead. It felt much clunkier to work with, but I wasn't comfortable with wrangling Kivy's instability for the rest of the project.
[0] http://cleichner.blogspot.com/2011/02/multitouch-project.htm...
That being said, even when compiling for PC it's worked very well for me when a client wants an internal tool and is willing to give up a native feel in exchange for fast (cheap!) development. I wrote this for UCLA a few months ago, and I think the whole thing only took me about 20 hours: https://github.com/sbrother/wassum-lab-lick-program/
You could also take a look at Juce, depending on what you need to do with it.
But, if you don't mind large binaries you could easily embed a chromium or awesomium layer as your frontend and do your frontend in html/css/javascript and use JavaScript to communicate with your backend.
As people as said, the best idea would be to write one backend and three or two frontends. That will give you the best experience on all three platforms, and the native GUI look, something that on Mac Qt still suffers with.
I'm a Java developer and I would write the software using Java if only Java isn't stigmatized by "bad software" in the desktop market. It's too bad because so far only Java that provide some of the solutions for me in a few areas to tackle in the cross-platform desktop market, namely: dealing with dependencies, rich 3rd-party libraries (and most of them are FOSS) and a packaging tool for Mac App-Store!.
I wouldn't mind writing 3 different UI code as long as I can share the back-end part and that shareable code works consistently across platform (i.e.: something that communicate with an embedded database like SQLite).
Can anyone share their experience using Mono for cross-platform desktop application that requires DB connection and potentially deal with Service API (i.e.: Twitter, Dropbox, etc)?
My requirements are as follow:
1. Installer/Packager
Something that can help me to generate installer for Windows 7, Mac AppStore, Ubuntu software center (or .deb). RPM would be nice but I can live with writing shell script.
2. Build+Dependency management (don't know if NuGet works flawlessly or not in Linux/Mac)
Maven spoiled me (people who dislike Maven please close your eyes...). I've read that Mono has xbuild but the documentation seems... lacking.
3. Unit-testing
Something where I can run unit-tests through the IDE so I can debug directly from my unit-tests when bugs are found.
4. Good enough 3rd-party libraries
I'm down writing missing libraries if needed but my first priority is the app itself.
We used Wix for the Windows installer and the included OSX tools to make the Mac installer (http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html was helpful).
A TeamCity build system using NuGet worked fine for building both flavors, though the Mac build was really just a shell script that TeamCity launched. We used the Xamarin compiler for Mac.
In hindsight I wish we had taken (found?) the time to go all the way and write separate OSX specific UI code and not used GtkSharp. And not require the install of the Mono framework for Mac users-- that really kills the experience. Supposedly you can bundle in Mono with the Xamarin .Mac product but we haven't found the time to get that far yet.
*EDIT: I failed to mention explicitly this was C#/Mono. Also for those interested I used http://www.signal11.us/oss/hidapi/ as a wrapper around the Mac HID USB APIs and it worked fine.
From the linked material - What are you basing this statement on?
Mono solves everything you complain about and that's the only mention it gets?
C# (especially when developed in VS) is a nice language and environment, but cross-platform is not one of it's strengths.
It's actually caused me to stop writing C#, because I can't stand managing Windows systems, but there isn't really a good alternative.
Not true. And, even if it were, how is that in any way a downside from Microsoft's point of view? As a Linux user myself, the main reason why I switched from Windows is that all the exciting advances in programming languages are happening in * nix-land, mainly Haskell and Rust. If there were some super-duper-awesome language for which Windows were the first-class platform, I would seriously consider switching back. I do not give a single damn about software freedom, technical excellence trumps all else.
> So, assuming the language develops into everything that's promised, you're left with something on which you can't do mobile, can't do big data, probably won't work very well for scientific computing.
Or Microsoft could be aspiring to make Windows a viable platform for all of those applications. Just because today Windows sucks for them, it does not mean it has to suck forever.
> So the best you can hope for, basically, is a better C#. But not good enough to take on Java.
Java's sole achievement is being consistently (as in "in the same way") crappy on all platforms. I would much rather be locked into a single platform for which there is an awesome language.
Kick-ass language with poor ecosystem is the common symptoms of academic language: for fun but lack of productivity and not battle tested.
So you would rather be locked into a single crappy platform with a crappy language that only works on that single crappy platform?
Please explain how you arrived at that conclusion.
[1] npm install -g typescript and it's installed and ready to go wherever you are using Node.js
This, together with pervasive mutability, means that communication using channels is merely a convention that can easily be circumvented.
It is a faster python with a very primitive type system tacked on. I don't know how they ended up there from their original idea of a systems language, but they did.
And concurrency primitives in the core language. (In a properly designed language, these could have been made part of the standard library, though.)
And worse error-handling facilities than the original Python.
I think a lot of folks here have a hard time thinking about a world without GC or that GC might ever be a bad thing.
However, Rust exists and is unlikely to be as encumbered as what Microsoft produces.
On Rust, and also this project (I believe the following point is mentioned elsewhere in this thread as well): There's one thing I don't get about the whole thing. People who want a low-level language with lots of control have C and C++. People who want a high-level language with GC etc. have lots of options today as well. So, why Rust, and why this MS project? C and C++ have faults but the people who care about them are well aware; if nothing else they are a known quantity. People who don't care about any of this will just pick the higher-level stuff.
I guess I'll have to try one of these languages out to form a better opinion.
I.e. you can rely on the compiler to verify most of your code, only the explicit `unsafe` blocks (which are normally very rare, especially with some considered abstractions that keep all the unsafety in one place) absolutely need auditing for things like buffer overflow and use-after-free (unlike C/C++ where any code in the whole codebase can have these problems).
C's widespread made systems open to buffer and pointer misuse exploits, patched by external tooling and multiple attempts at OS levels. All of them still far away from the desired outcome.
I've never tried running .net on a non-windows platform, so I can't comment in that space. I'll leave that to someone else.
As someone who's built bespoke big data applications, scientific computing (if we're both talking about large scale computation for analytics), desktop applications, server applications/services, and web sites (one of which is within the US top 150 on alexa) in c#; I'll have to disagree that anyone working in the language is stuck with LoB applications and ETL tools.
And none of this looks likely to change. Windows has been a second rate development platform for some time now, and Microsoft don't mind.
Says who?
Those of us that use GUI environments not stuck in 70's terminals workflow think otherwise.
Nuget is a late attempt to follow Maven and yet still behind.
EntityFramework came in late and I heard ppl moaned.
No Docker...
Chocolatey came in late.
So yeah... Says the parent thread and me.
Only ORM I use is the wonderful Dapper.NET.
I only do it when I am left without any other choice, maybe growing up with Amiga/Smalltalk/Oberon GUIs has spoiled me.
I can't speak for all .net shops, but in my experience you roll your own. You sit down, discover your problem, and write a solution for whatever you need from scratch specifically tailored to your need and performance requirements. Afterward, you understand the code (and the intent behind it) very very well.
I don't lament the lack of third party frameworks. I take them as an inspiration when I find interesting ones, and I know my toolset well enough to re-work their solutions and make them my own in pretty good time.
For me, as long as whatever it is is meant to run on windows (and doesn't require native performance), C#'s sweet spot is whatever I decide it needs to be.
Having a C#-like language in which I can write code with performance comparable to native will put some icing on my cake.
So in those instances you have a choice. You can use those libraries/products as they stand, or you can roll your own.
SciPy type stuff is best handled using F#, which also works on Mono, and has some features that I haven't seen in any other languages (e.g. Type Providers).
There are multiple .NET web frameworks, including Microsoft's own ASP.NET MVC and Web API, but also OSS efforts like FubuMVC, Nancy, ServiceStack, Simple.Web and more, most of which work as well on Mono as on MS .NET.
As you say, the Node story on Windows has improved lately, and most current languages work as well on Windows as on any other platform.
C# itself is probably second only to JavaScript in terms of cross-platform development: Xamarin for Mac and mobile; Mono for Linux (yes, it's incomplete, but Linux people should be used to that); Unity for game development across consoles, mobile devices, web and traditional PCs. By "cross-platform" I don't necessarily mean write-once-run-everywhere, which results in lowest common denominator dreck anyway, but the ability to reuse your skills and some code in many different environments and domains.
That's not true.
> yeah, I know about Mono
And you know it :-). I agree if you want to express that C# on Linux is a niche. But there're big projects using it in production. Have a look at the Mono project page. Also, have a look at Xamarin.
> can't do mobile, can't do big data, probably won't work very well for scientific computing
There's no language that does all these things well. Java is for Android and big data suited, but not for scientific computing. Fortran, C and C++ are great at scientific computing, but certainly not for mobile (except Qt on niche plattforms). Objective C is not appropriate for big data and scientific computing. Rust and Go aren't the can-do-it-all languages / ecosystems either.
C# and the .NET ecosystem are actually second to Java in terms of reach and versality. Taking Xamarin into account C# has the top spot for mobile.
> equally I worry that it'll be used as a way to generate patents to prevent the ideas being used elsewhere
FUD
Anyway, he says explicitly that he cannot reveal any details at this point; i.e. Microsoft has filed patents related to this "new langage" and can't talk about it until they are approved. He also claims to have been working on his "new language" for 5 years already; I wonder what those 33 patents he says he got pending are? Or maybe he patented 33 things related to something he hasn't been working on for the last 5 years? Not likely. Microsoft will get more and more desperate as they continue to be marginalized in terms of market cap, market share and developer mindshare. They have a long track record of simply being dicks (i.e. just look at how they charge royalty for every android phone, and how they created the Rock Star patent troll company etc).
It would be better for everyone if Microsoft stayed out of the "perf + productivity" language niche.
No, you've been living in an echo chamber :-)
Open source enthusiasts may well want to share their work for free (or statistically more likely, use others' work for free), but that's their prerogative. Most companies will not give away their competitive advantage and will seek to protect it anyway they can, and similarly, they are well within their rights to do so.
However, open source seems to be the dominant religion around here. And also you have a lot of Google employees here, and Google is a bit handicapped when it comes to patents at the moment. This is why you hear a disproportionate amount of anti-patent rhetoric. Outside these circles, most engineers are either ignorant about patents or quite proud of their patents.
Do you actually belive this?
> most engineers are either ignorant about patents or quite proud of their patents.
Cooperate America seems to be the only echo chamber that belives software patents are a pretty neat idea.
I haven't seen a single Google employee (that I know of) here or on other forums who's had a nice thing to say about patents. I'm sure there are some pro-patent Google employees, they just don't seem to post on here :-)
But I don't understand what you mean by "corporate America"... Aren't companies that are complaining loudly about software patents also part of "corporate America"? How is that an echo chamber?
>> Bragging about patents doesn't exactly make me like the guy.
Genuinely asking, do you see putting information on patents as bragging or more generally as a negative? I have also been putting the same on my profile, so would like to understand your viewpoint better to see if I should remove it.
My side of the story:
I have nearly always worked for big technology companies and for various reasons they are always very protective of their IP. This means that an employee can barely talk about his/her projects at the company without making the description too generic. People are barely allowed to publish papers on their work, make contributions to open-source (unless with consent of the employer, which is rare), and cannot have side projects [1].
Such generic descriptions of the projects and a mere mention of the skills do not leave many options for employees to demonstrate their expertise. Recommendations is one way (and I correspondingly have plenty of stellar ones on my LinkedIn profile), but is also gamed a lot: I know several cases where non-deserving people also have great recommendations.
Then comes the patent filings. I have been known as a well-respected and "a prolific inventor" in my last employment, the "most original thinker" at college, etc. Yet, it is hard to reflect this on the profile or CV since these terms by themselves are also often overused.
[1] While it may be a common practice to have side projects, the employment agreements most big technology companies have, that most people sign without even reading, place a lot of restrictions on the side projects. These issues have been discussed on HN several times before. In fact, since most employees do not even read these agreements, talk about negotiating on them, the equilibrium position for these agreements is heavily biased in the favor of employers than of employees.
> I’ve given a few glimpses into this work over the years. In the months to come, I will start sharing more details. My goal is to eventually open source this thing, but...
We'll have to wait and see, I guess. I also found this quote a bit odd
> There are other candidates early in their lives, too, most notably Rust and D. But hey, my team works at Microsoft, where there is ample C# talent and community just an arm’s length away.
D is hardly early in its life, but there is something about the whole "my team works at Microsoft, where there is ample C# talent" bit that is so very Microsoft, and I don't mean because it mentions Microsoft and C#, but in the sense of how they tend to work there. At least, this is my outside view, based mostly on what they promise vs. actually deliver in the C++ world, and where their interest constantly seem to fall short. Of course, you can't blame Microsoft for being interested in advancing Microsoft.
With that out of the way, and being up front that the rest of this comment is unnecessary, I wonder why this is on the front page of Lambda the Ultimate. It's become a favourite site of mine as I've recently become a lot more interested in language implementations. I'm certain the comments on the article will make it worthy, but as it stands, and with my comments above out of the way, I don't see what it offers. It's just hand waving about some ideal language that doesn't (fully) exist yet. The actual answer to my question of why it is on the front page is because Charles Torre can make front page posts, but just be aware that he works at Microsoft and hypes up their behaviour (that I'm admittedly not so pleased with) often. I know he is, like me, actually interested in language implementations, and has made far more worthy contributions on LtU than I ever have, but the front page of LtU is usually a bit more grounded.
To be fair, I was being unjustly negative because of my worry about how Microsoft treats such projects. Admittedly, after sleeping on it, I don't see it to be as big as a deal as I did last night. It'll be interesting to see what Microsoft produces, and we'll still have the open and approachable Rust regardless.
I find Charles reply to your comment about the HN thread odd though. He says
> It's interesting, though not unexpected, that folks are already comparing this language to D, Rust, and Go which also aim for a nirvana (safe, productive, fast, open) without really having many of the details required to make intelligent comparisons (on reddit, somebody made a post asserting this language is MS's _answer_ to D and Rust... WTF?).
Why is this interesting or unexpected? Joe Duffy's blog post mentions D and Rust explicitly. That we don't have "many of the details required to make intelligent comparisons" was my issue with it being hand wavy. There are already conspiracy themed posts about this being because Microsoft wants to lock down patents on these parts of the language [2]. Post the details, and we'll likely see "intelligent comparisons" being made on HN and Reddit.
The post is spreading on Reddit as well, if you would like to see others feelings on the matter [3].
[0] http://lambda-the-ultimate.org/node/4816
[1] http://lambda-the-ultimate.org/node/4754
[2] http://www.reddit.com/r/rust/comments/1tve0m/a_glimpse_into_...
[3] http://www.reddit.com/r/programming/duplicates/1tvic1/the_mi...
I agree.
But I think it would be more appropriate to conduct LtU meta-discussions over on LtU...
> It’s commonly claimed that with type-safety comes an inherent loss of performance
If we've learned anything, it's that type safety buys you performance because it enables a lot of compiler optimizations that are not possible in dynamically typed languages.
Other than that, the language sounds very interesting but if it's going to be Windows only, it will suffer the same fate as C#: powerful but crippled by its platform boundaries in a way that will make it impossible to compete with Java.
By the way, it is possible and sometimes preferrable to do all type checks in runtime. Haskell provides this option: https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime
> By definition, type checks are done at compile time.
That does not match my definition of type checks.
Ignoring things like Typed Racket or clojure.core.typed for a moment. Consider a cast in Java: This is a type safe operation which incurs a runtime type check.
Now maybe you're thinking of global type checking for correctness. In which case, I'd still disagree, since there is no rule that you can't have a resident analyzer and run type checks after compilation. Go read about Typed Racket, for example.
No it doesn't, given that the context was specifically runtime checks like array bounds checking, and he replied with a non-sequitur about memory corruption.
>That does not match my definition of type checks.
That is because "your definition" is incorrect. I am using the actual definition. "Dynamic typing" is a deliberately incorrect name for untyped languages. Runtime checking of value compatibility is not type checking.
2) Even reconciling our disagreement on terminology, I still disagree A) that a strict phase separation is a prerequisite for types to exist at all and B) that it even makes sense to talk about "untyped" as if I couldn't just invent a type system (however complex) for proving properties of a particular language that previously had no known type system.
The simple fact of the matter is that definitions evolve over time as we learn more about our field. "Type safety" is historically valid phrase for what we now know as "memory safety". In context of the performance claims, it was quite clear what the author meant.
Surely the most common source of oranges is orange trees.
>Even reconciling our disagreement on terminology
You aren't reconciling it, you are just repeating "I don't like the real definition of type system in regards to computer science". That's great for you and all, but it has nothing to do with me. If you want to learn about it I can recommend some material, but if you just want to argue "I don't understand X therefore using the correct terminology for X is wrong" then there's no need to continue.
I think a lot of money in computer technology is made off of the cluelessness of application programmers. Then again, sometimes "cluelessness" = "schlepping" = opportunity. Azul systems Zing JVM is an example of this. Instead of arcane tuning, architecture, and optimization, you just put in a pauseless GC VM.
ARC with Objective-C shows that one can have automated deterministic memory management that's not only workable in practice, it works about as well as GC. That is, 90% of the time, with gotchas for application programmers not paying enough attention the other 10%. A functional language should enable a "just works" percentage even higher than 90%.
- C# syntactic sugar
- As fast as C++
- Does not require .NET
- Runs on Windows/Linux/Unix with no problems
edit: If it somehow didn't need it, I would start considering it as my next language to learn.
Yet you still need the JRE for Java.
No, we need better foundations.
> - As fast as C++
I think it is not so much about raw speed (although this is certainly important) as it is about reliability. Raw speed (and, in general, runtime efficiency) is usually a corollary of elegance in design.
Now that we have programming languages with linear types and static lifetime management (Rust), I think it is fair to say garbage-collected systems have "duck-typed lifetimes" and languages with raw pointers have "untyped lifetimes".
And here is the catch: The principle that duck typing adds overhead (unacceptable for systems programming) does not only apply to values (in the form of the "type tag" that every value must carry), it applies to lifetimes as well (in the form of garbage collection pauses)!
Furthermore, I strongly suspect the aforementioned principle applies to anything worthy of being expressed statically. Off of the top of my head: validity of indices for sequential containers and keys for associative containers, which requires dependent types to be expressed statically, and whose duck typing counterpart is throwing something like .NET's ArgumentOutOfRangeException or KeyNotFoundException.
I think we've had enough of those in the past decade. Each one has something new to offer, but at the same time it disperses attention of the programmer crowd and so less effort is put into each language's development.
I think we need to experiment more with single-purpose languages. I'm not saying DSLs because those are mostly embedded syntactic constructs in existing languages. By single-purpose I mean an independent language (not just new syntax, but semantics as well, and possibly new runtime) that does one thing and does it well.
I believe such a language will have much more luck in becoming the single good enough solution for a particular problem (any problem it chooses to address, but only that one). There is really no hope for any general-purpose language to be a good fit for the whole wide spectrum of problems modern computing needs to solve.
I think the trouble with single-purpose languages is that, realistically, their development needs to be motivated by a real problem not satisfactorily addressed by an existing language. And since the people with these problems are not often going to be language designers, most such opportunities will be missed. I'm frankly surprised by the existence of Julia.
That said, I think hidden in your last sentence is the fact that working with C# in an IDE with a statically typed language is such a pleasure.
For most mundane code (loops, linq, if/else), Resharper will literally autocomplete everything.
I really wish other languages offered such tooling at times.
I don't think any other language/IDE combo comes close (in my opinion).
A new gaming-compatible language that breaks free from the old legacy and purely embraces the new Microsoft platforms and their semi-open development model could be excellent. And with MS offering hardware platforms for gaming, mobile, desktop, and server, there's a lot of space for this language to really shine - a good systems language for XBox and WinPhone would be beautiful.
And while I'd cringe at another platform-specific language, Apple has proven that people will suffer through your exotic toolchain if it means getting to develop for a popular platform.
The biggest problem historically with C# isn't the windows-specific nature of the platform, it's the heavily Cathedral-oriented community. Developers are married to Microsoft libs, even when they suck, and it doesn't have the kind of open reusable tools that other platforms have. Microsoft has finally started achieving this, but only by creating open-source communities around their existing libs like EF and MVC.
It's completely not at all the same, but still familiar to rust programmers.
It's but built for the enterprise with advanced patented technology.
The yearly license fee will include responsive customer service.
yes, it's only one example among 1000s of opposite ones but things are changing even in Microsoft, very slowly, with lots of setbacks, but they are. They won't transform MS anytime soon and possibly ever but I see saner pockets emerging.
Oh no wait, for those of us who have actually used these specs (in my case MSRPC/DCE), it's a hopeless mess of blatantly incomplete documentation obviously written by the lowest bidder.
Microsoft haven't changed. They've succeeded in changing their perception only. The company is still predatory sales focused and always will be.
It's almost like they have more than one person who writes specs.
Now, I cannot imagine what unearthly sequence of events led to a snafu where MS had to ask an outside party to reverse engineer their own stuff in order to document it... But that may explain your experience.
Moreover, the .net compilers, library, framework, and run-time are, and have been, provided for free, as is a version of the IDE. All of which can be used to develop commercial applications. The only requirement being that they run on a Windows OS. Even so, you can run all of this from within WINE, again without ever paying MS any money whatsoever.
The idea that MS is out to envelope developers by enticing them into a language that requires massive cash outlays or ongoing licensing fees is not supported by reality.
The idea that MS is out to envelope developers by enticing
them into a language that requires massive cash outlays or
*ongoing licensing fees* is not supported by reality.
The only requirement being that they run on a Windows OS
Yes, I suppose you can run some C# on a non-windows machine, but it'll have bugs, break, some libraries won't be supported and there's no tooling support.
...but don't worry, you can happily tell everyone how free and open source it is. That's really important!
(by comparison, have a look at go which actually bothered to make a commitment to supporting various platforms; and don't even start with that whole 'xamarin is awesome' stuff; yes it is, but it in no ways acts as a caveat for microsoft's 'we'll make the spec public, that's good enough right?' behaviour)
C# runs great on 90% of desktop computers because Microsoft has had a 20 year desktop monopoly. It's is a walled garden until we can easily move code to other platforms and have it perform at the same level.
Mobile apps, web apps and games are where the money is these days; and writing those in C# requires license fees for tools and (in some cases) servers to run the software on.
Are you suggesting that if Microsoft releases this new language they might not require an expensive Visual Studio license so you can use the language plugin, or an expensive server license to run it on?
(To be fair, the python developer tools actually did this, with a forked free version of visual studio, and the typescript compiler is free and open (although the tooling plugin requires VS Pro)) ...so perhaps its not totally out of the question).
I'm not holding my breath, but if they surprise me, I'll happily eat my words.
Would open sourcing the C# compiler be enough? Open sourcing .NET? Providing .NET support and development for Linux?
I'm honestly just curious, not to put you on the spot.
It's not hard, heck Microsoft has even done it before, they just missed the ball with C#.
What have you created that justifies this kind of an attitude?
Not exactly. The guys who developed F# based the core language mostly on OCaml and borrowed some ideas from Haskell, but are not the same as the people who developed Haskell.
Yes, I'm aware that it's not the Haskell core team who is working on this new language. But they probably have their offices across the floor.
Your comments aren't all "great", but they seem to be in good faith. I feel that a friendly reminder to strive to post substantive and relevant comments [1] would be a far more appropriate remedy than killing your account after your second comment.
https://github.com/mozilla/rust/wiki/Doc-project-FAQ
This is what they state their goal is. (no mention of performance)
>To design and implement a safe, concurrent, practical, static systems language.
vs (linked article)
>high productivity (ease of use, intuitive, high level) AND guaranteed (type)safety AND high execution performance.
What are the differences? It sounds pretty similar to Rust—"rvalue references, move semantics, destruction, references / borrowing" are straight out of Rust's playbook.
Granted, if it's based on C#, it sounds like it'll be more object-oriented than Rust is, which is a difference. Rust has some object-oriented features, but they're much more minimalist than what C# offers; idiomatic Rust prefers composition over inheritance, etc.
> Rust is not aimed at high performance applications
This week has been bizarro week for weird things people are saying about Rust. :)
Rust is about zero-cost abstractions, period. It's right there on the Wikipedia page: "Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable (and sometimes faster) than C++ code that manually takes precautions comparable to what the Rust language mandates." http://en.wikipedia.org/wiki/Rust_%28programming_language%29
Mozilla is explicitly investing in Rust in order to build the fastest browser engine around and has been from day one…
As you mentioned, if they based it entirely on C# , it will be a unified type system. We'll only get more information when they release a standards specification.
>Rust is about zero-cost abstractions, period.
Um.. no? For one, the heap is reference counted - and if you use std::gc its... mark/sweep(not sure?). This obviously means that the programmer has little control over memory allocation other than what can be afforded by not compromising memory safety. Secondly from my initial use of Rust I dont think you cannot protect a chunk of data with a lock and share it (w/o copying) across threads/processes as you would with a systems language like C++.
--
Rust is not aimed at high performance applications - I dont see anything wrong with that statement.
Refcounted pointers are just one option in rust. ~Obviously~ you can use anything from C-style pointers and your own custom allocator that calls brk() directly to atomically refcounted and/or mutexed threadsafe smartpointers to manage your memory.
No, the heap primarily uses unique ownership, which is equivalent to malloc/free. Reference counting is an option (and mark/sweep in the future) but idiomatic Rust only uses reference counting where it is necessary.
> Secondly from my initial use of Rust I dont think you cannot protect a chunk of data with a lock and share it (w/o copying) across threads/processes as you would with a systems language like C++.
Yes, you can. http://static.rust-lang.org/doc/master/extra/arc/struct.Mute...
> Rust is not aimed at high performance applications - I dont see anything wrong with that statement.
Rust is aimed at high performance applications and has been since day one.
Anyway, I don't have anything against Rust. I cheer for their success.
Hmm... not sure if that's just C#, or if I should start profiling my Java apps a lot more closely.
That's a very good point with these rewrite stories - you could happen to rewrite some really poor code while porting and boom! Language Y is 50% more performant!
Microsoft has great development tools. It would be better for them to hold onto the developers and share them with other platforms rather than losing them completely. By making their development tools multi-platform they would be bringing many developers to Windows who today want little to do with that platform.
I predict Microsoft will push NodeJS / JavaScript / HTML5 for application development. I'm assuming this will be targeted towards the Go style community and applications. It has a lot of the same properties with Go starting to gain traction I can see why Microsoft would be exploring the space.
As for business logic by an average developer - I would say the same thing about every language.
I am pretty excited to see this. Any existing language out there actually does this?
[1] http://en.wikipedia.org/wiki/Eiffel_(programming_language)#E...
Very sophisticated contract system and exceptions and reified continuations.
It's dynamic, JITed language, and it's a Lisp, but I recommend studying it just for the sake of learning various techniques Racket uses. They are frequently very interesting from the language design perspective and their usage is easier to understand than in Haskell :)
So they're making MS Go. Just like C# is MS Java.
As someone that's spent a lot of time learning how to get c# to perform, this sounds fantastic to me. I can't wait to see it.
I read this as MS once again getting it completely wrong. Seriously C++ solving managed languages performance and memory problems?
Physician, HEAL THY SELF.
You sure seem to be an expert on these things.
As long as you're guessing, you can say anything you want.
>but mostly because of memory and cpu cycle determinism.
There is SOME memory determinism in C++. Much of the memory layout is left unspecified in the standard and left upto the implementations - e.g. virtual tables, exceptions, C++ standard library internals, primitive data type sizes, and a bunch of stuff that if listed one-per-line would take up dozens of pages.
Not really, a GC call in the middle of your render loop can drop your FPS rate significantly, and those cpu cycles are vital when you start adding physics simulation, not to mention the limitation of memory on consoles.
Sure, Java and C# would be enough for minecraft or some xbox live puzzle game, but I really doubt that you could manage to write an Uncharted game in Java or C# on a PS3 or an Xbox.
So ... you will have slightly lower FPS (55 instead of 60) but much worse experience.
The runtimes of the games are often code monstrosities wasting performance here and there.
Performance is way over-rated.
The only really bad technical decision that they have taken is the broken security model of user accounts.
I suspect I have just outed myself as a substandard hacker. :( But seriously! There's so many!
The "do we really need more languages?" argument predates most of my preferred languages(and that probably includes C and Pascal).
I like Haxe, Rust is looking like being really good also. I don't like Go but others do, and that is a really important point. You don't have to like, or use the new languages. As long as someone finds them useful they have a place.
I've played with many really nice languages, but never used them seriously because they had no libraries (let alone quality libraries), had poor tooling, poor documentation, buggy runtime, and almost nobody to compare notes with. In my experience, the largest jump in productivity is libraries, not some feature of a language.
On the one hand, languages are useful to explore a space. On the other, there's a lot of reinvented wheels going on here. If all languages stuck with the same ABI (e.g. C), it'd be one thing, because then you could use the same libraries and many tools between languages. Unfortunately, they often cannot, and thus you can't. There's some serious opportunity cost going on here.
I'm happy using node.js at the moment (ooh, shiny!), but the current situation with a plethora of languages isn't exactly great either.
I don't deny languages take time to mature. I feel like Haxe is about two-thirds of the way towards being properly Mature. It is approaching 10 years old, yet I feel like it is only just getting started, A lot of people still haven't even heard of it.
Note that this means we need a language which has certain fundamental differences to existing languages, so we don't need YAJAWiSS (yet another java with syntactic sugar), but something that takes a step forward. Their error model, first class immutability and RAII outside of C++ might be something like this, if done well.
We still haven't figured out the best tradeoffs between dynamism and type safety. And we definitely haven't sorted out the best set of features for memory management and error handling. And after that there are a lot of even bigger fish to fry.