codingbinary, you are hell-banned (your comments are invisible to the vast majority of users).
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.
Yes it does, but IMO only superficially. Rust has a completely different type system model and also Rust is not aimed at high performance applications, while this seems to be. Many(most?) new languages fade away because nobody is interested in implementing compilers/libraries writing documentation/teaching material/etc etc. I'll be impressed if they can ship something next year.
> Rust has a completely different type system model
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.
> For one, the heap is reference counted - and if you use std::gc its... mark/sweep(not sure?).
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++.
So are you confirming or denying that Rust is about zero-cost abstraction? Because it sounds like you're saying if you don't use any abstractions, its zero cost :)
Anyway, I don't have anything against Rust. I cheer for their success.
You'll have to take the word of the people aiming rust, really.
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.
Nuts to that, I expect that Rust could regularly exceed C++ in performance. Ownership as a core concept means that you get pointer aliasing information for free, which has always been Fortran's biggest advantage over C. And correct me if I'm wrong, but C++'s unique_ptr isn't guaranteed to have zero overhead at runtime, as Rust's unique pointers are.
unique_ptr should have similar performance to Rust as designed right now, but the upcoming changes to eliminate zeroing out of moved values should give Rust's unique pointers an edge over those of C++ in 1.0.
That's not how languages in the .net ecosystem have worked in the past. C# is an open, ecma standard, as is the specification of the common language infrastructure (the VM/byte-code design for running .net programs). And MS publishes the language specifications for VB and F#. That's why it's possible to run .net code on linux without ever paying MS. There's even an open source F# compiler.
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
Mhm.
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)
Why does this need to be explained to C# people every time we have this conversation? Seriously, every time!
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.
I'm really appalled by the hostility that's being displayed here. This is Microsoft research in Cambridge, not the Xbox one marketing department. You know, the guys who work on Haskell, ported OCAML to .net and generally do a lot of awesome stuff.
What have you created that justifies this kind of an attitude?
FYI, this isn't really an MSR project. It (the OS project that spawned the language) was run under the "Startup Business Group" until recently, and developed in Redmond.
> You know, the guys who work on Haskell, ported OCAML to .net and generally do a lot of awesome stuff.
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.
well, if we only look at the language and the "recent" past then C# is both an Ecma and ISO standard.
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.
Yes their technical specifications for protocols and formats are wonderful since they released the open specification promise!
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.
Some are, some are not. Some are so bad it's unfunny. Literally someone has read the COM IDL and made up some padding. The core protocols like MSRPC are poorly documented i.e. the interoperability specs. They definitely have more than one person (did I suggest otherwise?) but I suspect the documentation was outsourced for a lot of stuff to people who have no idea how it works
Anecdotal, but sometimes things seem so dysfunctional within MS that I can't believe they get anything done at all: I once met a professor at a conference who said his grad students were reverse-engineering some of Microsoft's distributed system protocols (not MSRPC). I asked him why he didn't directly contact the team owning that project at Microsoft for help instead, and if I should introduce him to them -- I had met them before and they were pretty friendly and eager to get people to use their stuff. He said he was doing the reverse engineering for Microsoft. When I was like "WTF, why?!", he wouldn't give any details but said in an offhand way that MS needed somebody to document the system.
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.
