This sounds suspiciously similar to Rust.
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.
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.
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.
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.
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.
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.
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.
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.