The Rust Programming Language: http://www.rust-lang.org/QuoteRust is a curly-brace, block-structured expression language. It visually resembles the C language family, but differs significantly in syntactic and semantic details. Its design is oriented toward concerns of "programming in the large", that is, of creating and maintaining boundaries - both abstract and operational - that preserve large-system integrity, availability and concurrency.It supports a mixture of imperative procedural, concurrent actor, object-oriented and pure functional styles. Rust also supports generic programming and metaprogramming, in both static and dynamic styles. http://en.wikipedia.org/wiki/Rust_(prog ... uage)While the work on it has started a few years ago already, it's currently at the preview release status (that being said, it already supports type classes, for instance -- i.e., what we call "concepts" in C++). It may be a good time for a general / placeholder topic :-)This makes it quite interesting:Removing Garbage Collection From the Rust LanguageAt the same time it has a strong focus on memory safety *and* data-race freedom (some of the ideas it draws upon, like substructural typing (linear typing in particular), may well turn out to be the modern replacements for / subsume memory-only GC):On the Connection Between Memory Management and Data-race FreedomQuoteThis observation has motivated a lot of the research into ownership types and linear types, research which Rust draws on. Of other recent non-research languages, the only other that I know which takes the approach of controlling aliasing is Parasail. Not coincidentally, I would argue, both Rust and Parasail guarantee data-race freedom, while most languages do not.The equivalents of C++11's smart pointers are integrated into the core language (no calls to raw "new" by mistake; in addition, opt-in GC-ed managed pointers[*] are also present -- although, and that's the difference from, say, D, the goal is to keep the standard library completely GC-free):An Overview of Memory Management in RustThe Rust Language Tutorial[PDF] Rust: A Friendly Introduction[*] another difference from certain managed languages that profess "memory safety" while in fact suffering from nullable pointers: Rust's (managed) @-pointers can't be null.

Rust is not in the IndexPython has 4.18% of the shares, I took a look to it and found not so interesting, good enough for begginers course in CS, but for "serious" programming it is far behind C/C ++ and FortranA lot of publicity for Matlab and R but still small presence in the marketScala ... pfffit seems that C/C++ will reign for a whileI do not see the ranked 5 to 10 as risk for the top 4maybe C# and JavaScript deserve a better positionI took the course High Performance Scientific Computing at COURSERA, unfortunately it is biased to Fortran and Python, kind of waste because Fortran is ranked 28 and has 04% of the shares, I would had wished a simmilar course C/C++ oriented

QuoteI took the course High Performance Scientific Computing at COURSERA, unfortunately it is biased to Fortran and Python, kind of waste then Fortran is ranked 28 and has 04% of the shares, I would had wished a simmilar course C/C++ oriented Fortran is probably best for HPC. C++'s not there yet by a long shot. IMO. It does not even have standardised native matrix classes.BTW Do you intend to write a review of your course?

QuoteOriginally posted by: CuchulainnQuoteI took the course High Performance Scientific Computing at COURSERA, unfortunately it is biased to Fortran and Python, kind of waste, Fortran is ranked 28 and has 04% of the shares, I would had wished a simmilar course C/C++ oriented Fortran is probably best for HPC. C++'s not there yet by a long shot. IMO. It does not even have standardised native matrix classes.BTW Do you intend to write a review of your course? I did my MS thesis using fortran time ago .. and have not used F for a while. I skipped several stages of the course since it focuses on a language I am not using at the moment, but the general content of it is quite interesting.Again, I would have LOVED the same course but oriented to C/C++.

ExSan: of course it's not listed in TIOBE, it's just a preview release at the moment With the language itself undergoing rapid changes and development, the authors themselves advise against using it in production at this stage. I don't think a backward-looking indicator is useful when looking at something that's only going to be released in the future? :-)As for Scala -- *if* you're on a JVM, I think it's the best language available (fixes a lot of Java's design flaws, while allowing to re-use the already existing Java libs -- akin to the C++ and C situation, IMHO).As for Cousera and HPC -- wasn't there a (C for) CUDA course a while ago? There's also one at Udacity, AFAIR.Cuch: national labs are switching to C++, see 2013 Keynote: Dan Quinlan: C++ Use in High Performance Computing Within DOE: Past and FutureThat being said, I wouldn't mind the matrix stuff in the standard, either.

From Coursera HPC staff:QuoteMost HPC is done in Fortran. One reason is that there are many library routines written in Fortran over the years, which are easier to use from Fortran.Fortran now has the C interoperability feature which makes it fairly easy and allows a standard way to call between C and Fortran. There are now wrapper routines for some libraries to allow calls using more ordinary calling conventions. (One problem is that Fortran has no feature like C's array of pointers to arrays, often used in place of 2D arrays.) Many Fortran compilers, especially taking advantage of the Fortran aliasing rules, do a little better optimizing than C compilers. (Though in many cases it is the same back end for both compilers. gcc and gfortran, for example, share much code.)

QuoteOriginally posted by: ExSanFrom Coursera HPC staff:QuoteMost HPC is done in Fortran. One reason is that there are many library routines written in Fortran over the years, which are easier to use from Fortran.Fortran now has the C interoperability feature which makes it fairly easy and allows a standard way to call between C and Fortran. There are now wrapper routines for some libraries to allow calls using more ordinary calling conventions. (One problem is that Fortran has no feature like C's array of pointers to arrays, often used in place of 2D arrays.) Many Fortran compilers, especially taking advantage of the Fortran aliasing rules, do a little better optimizing than C compilers. (Though in many cases it is the same back end for both compilers. gcc and gfortran, for example, share much code.)When dinosaurs roamed the earth. ==Using the same logic, you should use COBOL for business applications.

Yeah, most new libs for, say, GPGPU are C++-only -- C interoperability won't be of much use for these. Somehow, I'd also trust Dan Quinlan more than some random staff when he says that national labs are switching to C++ ;-)Incidentally, aliasing doesn't affect C++ as much as C (they *are* rather different languages with different type systems, after all): http://www.drdobbs.com/cpp/type-based-a ... /184404273 (and there are compiler options to deal with that, too).To be honest, nowadays I'd immediately dismiss anyone who still makes claims about Fortran's performance and mentions aliasing -- this signals not keeping up with progress in PLT and mainstream optimizing compilers development for several decades now (read: inexcusable ignorance and/or profound intellectual laziness).Anyway, this is all somewhat OT, isn't it?

QuoteOriginally posted by: PolterYeah, most new libs for, say, GPGPU are C++-only -- C interoperability won't be of much use for these. Somehow, I'd also trust Dan Quinlan more than some random staff when he says that national labs are switching to C++ ;-)Incidentally, aliasing doesn't affect C++ as much as C (they *are* rather different languages with different type systems, after all): http://www.drdobbs.com/cpp/type-based-a ... /184404273 (and there are compiler options to deal with that, too).To be honest, nowadays I'd immediately dismiss anyone who still makes claims about Fortran's performance and mentions aliasing -- this signals not keeping up with progress in PLT and mainstream optimizing compilers development for several decades now (read: inexcusable ignorance and/or profound intellectual laziness).Anyway, this is all somewhat OT, isn't it? Indeed. All this pining for the fjords is nonsense (as a proud FORTRAN IV programmer). Maybe time for "C++ for Fortran".

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: PolterYeah, most new libs for, say, GPGPU are C++-only -- C interoperability won't be of much use for these. Somehow, I'd also trust Dan Quinlan more than some random staff when he says that national labs are switching to C++ ;-)Incidentally, aliasing doesn't affect C++ as much as C (they *are* rather different languages with different type systems, after all): http://www.drdobbs.com/cpp/type-based-a ... /184404273 (and there are compiler options to deal with that, too).To be honest, nowadays I'd immediately dismiss anyone who still makes claims about Fortran's performance and mentions aliasing -- this signals not keeping up with progress in PLT and mainstream optimizing compilers development for several decades now (read: inexcusable ignorance and/or profound intellectual laziness).Anyway, this is all somewhat OT, isn't it? Indeed. All this pining for the fjords is nonsense (as a proud FORTRAN IV programmer). Maybe time for "C++ for Fortran".Real Programmers can write FORTRAN in any language.Königspudel

QuoteOriginally posted by: fulmerspotQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: PolterYeah, most new libs for, say, GPGPU are C++-only -- C interoperability won't be of much use for these. Somehow, I'd also trust Dan Quinlan more than some random staff when he says that national labs are switching to C++ ;-)Incidentally, aliasing doesn't affect C++ as much as C (they *are* rather different languages with different type systems, after all): http://www.drdobbs.com/cpp/type-based-a ... /184404273 (and there are compiler options to deal with that, too).To be honest, nowadays I'd immediately dismiss anyone who still makes claims about Fortran's performance and mentions aliasing -- this signals not keeping up with progress in PLT and mainstream optimizing compilers development for several decades now (read: inexcusable ignorance and/or profound intellectual laziness).Anyway, this is all somewhat OT, isn't it? Indeed. All this pining for the fjords is nonsense (as a proud FORTRAN IV programmer). Maybe time for "C++ for Fortran".Real Programmers can write FORTRAN in any language.Königspudel ???? I do not think so. It would be more precise: Real programmers can code any algorithm in any language... and still there are certain limitations. An algorithm can intentionally assume pointers and these are not available in some p. languages

ExSan:See http://hulubei.net/tudor/humor/programmers.htmlfor instance.

QuoteOriginally posted by: fulmerspotQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: PolterYeah, most new libs for, say, GPGPU are C++-only -- C interoperability won't be of much use for these. Somehow, I'd also trust Dan Quinlan more than some random staff when he says that national labs are switching to C++ ;-)Incidentally, aliasing doesn't affect C++ as much as C (they *are* rather different languages with different type systems, after all): http://www.drdobbs.com/cpp/type-based-a ... /184404273 (and there are compiler options to deal with that, too).To be honest, nowadays I'd immediately dismiss anyone who still makes claims about Fortran's performance and mentions aliasing -- this signals not keeping up with progress in PLT and mainstream optimizing compilers development for several decades now (read: inexcusable ignorance and/or profound intellectual laziness).Anyway, this is all somewhat OT, isn't it? Indeed. All this pining for the fjords is nonsense (as a proud FORTRAN IV programmer). Maybe time for "C++ for Fortran".Real Programmers can write FORTRAN in any language.KönigspudelReal Programmers aren't afraid to use GOTOs.Real Programmers like Arithmetic IF statements-- they make the code more interesting.Since Fortran doesn't have a structured IF, REPEAT ... UNTIL, or CASE statement, Real Programmers don't have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTOs.

QuoteOriginally posted by: EtukaExSan:See http://hulubei.net/tudor/humor/programmers.htmlfor instance.Indeed, take heed Signor ExsanQuoteWhat of the future? It is a matter of some concern to Real Programmers that the latest generation of computer programmers are not being brought up with the same outlook on life as their elders. Many of them have never seen a computer with a front panel. Hardly anyone graduating from school these days can do hex arithmetic without a calculator. College graduates these days are soft - protected from the realities of programming by source level debuggers, text editors that count parentheses, and "user friendly" operating systems. Worst of all, some of these alleged "computer scientists" manage to get degrees without ever learning FORTRAN! Are we destined to become an industry of Unix hackers and PASCAL programmers?

http://mail.mozilla.org/pipermail/rust- ... oteMozilla and the Rust community are pleased to announce version 0.7 ofthe Rust compiler and tools. Rust is a systems programming languagewith a focus on safety, performance and concurrency.This release had a markedly different focus from previous releases,with fewer language changes and many improvements to the standardlibrary. The highlights this time include a rewrite of the borrowchecker that makes working with borrowed pointers significantlyeasier and a comprehensive new iterator module (std::iterator) that willeventually replace the previous closure-based iterators.The brief release notes are included in this announcement, and there isfurther explanation in the detailed release [notes] on the wiki.Documentation and all the links in this email are available on the[website]. As usual, version 0.7 should be considered an alpha release,suitable for early adopters and language enthusiasts. Please file [bugs]and join the [fun].[website]: http://www.rust-lang.org[notes]: https://github.com/mozilla/rust/wiki/Do ... notes[bugs]: https://github.com/mozilla/rust/issues[fun]: https://github.com/mozilla/rust/wiki/No ... ntributors