I can't wait to try this. If it can just get to the level of the first F# plugin, I'll be so happy.
If MS picked up interest in Rust that'd be even more amazing. And it'd actually solve their security problems, unlike the more and more convoluted codegen they're doing for C++.
Edit: to be clear, I mean the security problems that their C++ codegen is trying to solve, like stack cookies, ASLR, or the new stuff they were boasting about at build in the ObjC VS2015 codegen video. (Some special function call thing that stores a map of legitimate function call targets and checks before calling.) All that stuff is eliminated by having a sound design in the first place.
Yes, but currently I don't see any OS vendor picking up Rust, for what really matters, systems programming, e.g. drivers, kernel space modules, embedded development.
For anything else, Rust will have to deal with existing languages that are also able to deliver results.
Regarding GC, not all GC were made alike and being able to use value types also helps.
Rust needs to find a sweet spot to pick up speed. Being yet another application language won't help.
You're making the mistake of thinking that only "OS vendors" are interested in languages like C++ or Rust, or that such languages are only interesting for the kernel space or embedded stuff. That couldn't be further from the truth.
Languages without a GC are a requirement for anything real-time and desirable even for soft real-time. A lot of applications fall into this space, including audio/video processing, real-time bidding systems or game engines. There's a really good reason for why a lot of software being built for the finance industry is being built in C++.
> not all GC were made alike and being able to use value types also helps
Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do.
And there are only 2 GC-enabled platforms suitable for many soft real time use-cases (but not all) and those would be Java and Erlang ... Erlang because it was built for such scenarios with its lightweight processes and the per-process GC and Java because it has fancy incremental and non-blocking GCs available, like the one from Azul.
> You're making the mistake of thinking that only "OS vendors" are interested in languages like C++ or Rust, or that such languages are only interesting for the kernel space or embedded stuff. That couldn't be further from the truth.
Well, I have been coding since 1986 and the only systems programming languages that survived were the ones adapted by OS vendors.
If a systems programming language isn't adopted by an OS vendor, it becomes yet another application programming language and has to compete in already full arena.
> There's a really good reason for why a lot of software being built for the finance industry is being built in C++.
I do like C++, a lot, given its capabilities. But also dislike the unsafety it inherited from C.
However, I think one of the reasons C and C++ got so widespread is that 20 years ago, Java and .NET kind of killed all the other alternatives capable of produced standalone executables with optimizing compilers. At least from what mainstream developers are comfortable with.
So when a average developer goes looking for a programming language able to deliver binaries without dependencies his/her only options are C and C++, which feeds the circle.
I bet if Java, C# and VB.NET had gone the way of producing binaries like Delphi, Oberon and so on, the domain of C and C++ wouldn't be as it is nowadays.
For example, if Ada compilers were cheaper or if Borland had improved Delphi's toolchain across multiple OS instead of going astray in multiple directions, any of those languages could be in C++'s place.
Actually finance is one of the reasons why both Java and .NET are getting pure AOT compilation support nowadays.
> Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do.
Yet Mesa/Cedar, Oberon and Modula-3 were used successfully to build OSes that, in Oberon and Cedar's case, were used for quite a while as ETHZ and Xerox PARC workstations.
I believe that the need of producing binaries without dependencies (I assume you mean a VM) isn't so widespread, quite the contrary, most developers want a VM underneath because then deployment becomes easier. The loud minority that has historically complained about the widespread usage of the VM have been just that, a minority. And it is funny, because things are progressing in that direction with C++ as well (speaking of LLVM or Emscripten). That is not and has never been the real difference between C++ and Java/.NET, but rather in having versus not having a GC. The main reason for why C++ still wins by a good amount in any benchmark is because for performance sensitive code memory access becomes by far the biggest bottleneck and in C++ there's simply more opportunity for optimizing memory access patterns.
Delphi too lacked a GC. Java and .NET haven't killed Delphi, it is Borland that killed Delphi. This isn't a winner takes all kind of war (well, maybe it is in Windows land). We live in an industry in which multiple programming languages can coexist. For evidence of this you need to look no further than Linux, the Tower of Babel of our age.
And I disagree with you - besides the open-source operating systems that are developed by multiple parties, all "OS vendors" are interested in the lock-in of developers. You're mixing cause and effect I think ... when an "OS vendor" adopts a programming language that isn't created by themselves, that's only because the programming language in question is already popular and here to stay.
Yeah, maybe I have been burned a few times by the usual BOFH IT processes where one can only use the tools that are offered by the OS vendors, and only in special cases is allowed to use third party tooling.
In any case, as language geek, I always wish all programming languages find their place, specially those trying to make programming safer.
Offering manual memory management would be a huge win. Even if it's just hints. For instance, if a function was pure, then we know the arguments to it can't escape. So suddenly we can safely allocate many things right on the stack. This can be a huge win in high perf scenarios.
I'd also love an arena system, so I could provide a context and allocate objects in it and enforce they never leak. (Say, per request in an HTTP app.) Then the GC could just free that chunk in one go, no matter how much garbage I've loaded in it. I know that generational GC is supposed to handle this in general, but it isn't free, plus fails when some requests take a long time (and thus all their stuff gets promoted).
What's .Net Native gotta do with it? Can that really provide the performance? Is MS gonna start using C# for perf work? You've still got the GC and no easy way to eliminate such things. And what's stopping the JIT from doing similar things?
It is the same backend as Visual C++, including SIMD and auto-vectorization.
I bet currently it already does better than Rust actual code generation.
Sure it still does have a GC, but so what. There are plenty of research OS with a systems language having one. What we need is a company with the guts to force one down developers throats.
In any case, there is still C++ for the unsafe parts available.
Given that only as of Windows 8, C++ was accepted into the kernel, it will take a while until another language gets to join it.
EDIT: Forgot to mention that .NET 4.6 adds more control over GC behavior.
However, the point I was actually trying to make is that for MS, the C# + C++ combo is the way forward and their tools offer great integration experience, so I don't see them adopting something like Rust any time soon. Specially given their relation with the C++ standards process.
There are LLILC project. LLILC is an LLVM based MSIL Compiler. https://github.com/dotnet/llilc . May be it helps in the future be .Net community and Rust(llvm) community collaborate close.
No, but Rust solves the exact security problems that MS's codegen is trying to solve. Look at the Obj-C VS2015 video that was posted here a bit ago. They're constantly coming up with these crazy hacks to reduce the impact of lack of memory safety. It just seems so inelegant, such a waste of effort and intelligence. (I know, it's actually very useful, since MS is mostly C++, so mitigation is a real value.)
And look at this month's security bulletin from Microsoft. Once again, memory safety appears to be the leading offender. This is the same as it's always been. MS's critical CVE would drop by over 90% (I think more, but it's been a while since I tallied them all up) just by having memory safety.
MS and anyone else that jumped on the C ship long time ago.
These issues have been preached by us with experience in strong memory systems programming languages, e.g. Modula-2, Modula-3, Oberon, Ada, Pascal dialects...
But the industry needs to be exploited every day, spend huge pile of money in memory integer validation tools, the workarounds you mention (other compiler vendors do it as well) and still keep on fixing memory corruption exploits. To eventually start caring about this issues.
A visible side effect is the increase in Ada presence at FOSDEM in the last years, as well as, the industry acceptance of SPARK.
Back in the day I went to C++ from Turbo Pascal, because at least the language provided the tools to write safe code, if (big if) I cared to use them. So there was a path to achieve Algol type of safety.
The big issue is that due to its almost copy-paste compatibility with C, the added safety is not worth nothing if developers just keep on coding C with a C++ compiler.
Rust might eventually also suffer from this, given the amount of unsafe being used, I keep on seeing in code examples.
That is true, but I like to believe that if a group can solve a whole class of problems with a new language, that means they can spend more time and effort on other types of security problems.
I think a Visual Studio plugin is a very good start, since the IDE already supports C/C++ and I guess these users are a very important target audience for Rust.
There is also a Rust extension for the IntelliJ platform [0]. It supports some basic IDE features, but the last commit was in February. The Rust extension could fit really good to Jetbrains' new C/C++ IDE CLion.
Racer, the autocomplete engine, does. I'm not sure if there's more plugin usage since I haven't looked at the source yet.
Rust has great support for hooking in to the compiler and/or creating drop-in replacements. I'm hoping this pans out well and leads to some excellent tooling! :D
The Emacs-crowd is usually pretty crazy about supporting anything under the sun. But if this[1] is the best Rust-support the Emacs crowd can conjure up, this Visual thingie here actually looks like a better package for people looking into rust for the first time.
Perhaps they shouldn't have given it virtually the same name then. I can understand that he had an expectation given the naming choice. It also means that this support is Windows only.
If MS picked up interest in Rust that'd be even more amazing. And it'd actually solve their security problems, unlike the more and more convoluted codegen they're doing for C++.
Edit: to be clear, I mean the security problems that their C++ codegen is trying to solve, like stack cookies, ASLR, or the new stuff they were boasting about at build in the ObjC VS2015 codegen video. (Some special function call thing that stores a map of legitimate function call targets and checks before calling.) All that stuff is eliminated by having a sound design in the first place.