> Ed Borasky recently commented here at ReadWriteHack: "We flat out don't need any more programming languages! What we need is efficient implementations of the ones we have now and IDEs / version control systems that enforce software engineering discipline."
There was no need for assembly -- writing straight machine code worked. There was no need for C -- writing straight assembly worked. Etc, etc.
There has never been a need for a new programming language, but new programming languages can make life easier, can save you time, can make new optimizations possible, etc. So he's right in that we flat out don't need any more programming languages, but that doesn't mean creating new programming languages is a bad idea, or something we shouldn't do.
I'd like to see a better programming language. All of the existing languages involve accepting certain trade-offs. Of course maybe no "perfect" language can exist but until someone proves that there's always hope.
For me the ideal language would :
- Support OO, imperative and functional paradigms
- Compile to fully optimized machine code with efficiency comparable to that of C
- Provide language support for numerical multidimensional arrays and linear algebra with a syntax comparable to Matlab
- Support list comprehensions
- Provide map,list and set types similar to those of Python
- Support dynamic typing
- Support optional static typing, and contracts
- Provide standard libraries with breadth of functionality comparable to those of Java but simpler API's (more like Python)
- Provide a mechanism for efficient compile-time parametrization of algorithms, like C++ templates
- Support free-form (ie. whitespace independent) syntax
- Provide a high quality cross-platform GUI toolkit with support for OpenGL
- Provide an interactive graphical environment for experimentation and data analysis
- Provide a dataset abstraction similar to R data frames
- Be supported by a high-quality IDE and debugger
Of course that's a lot to ask for, but it would be nice to be able to do everything with a single unified syntax and environment.
> Compile to fully optimized machine code with efficiency comparable to that of C
Not quite, but ocamlopt generates pretty damn fast code and, more importantly, has very predictable performance. Ocaml makes a pretty good systems language as demonstrated by the recent Mirage paper: http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf
> Provide language support for numerical multidimensional arrays and linear algebra with a syntax comparable to Matlab
No, but this would make a good Jane Street summer project. Ocaml has extensible syntax via camlp4 and bindings to R, GSL and Matlab (no octave bindings for some reason).
It might be too soon to ask, but what distinguishes Rust from Google's Go or the D programming language? It seems to me that we've got three programming languages competing for the same niche.
*Have you seen this Google language, Go? How does Rust compare?*
Yes.
Rust development was several years underway before Go
launched, no direct inspiration.
Though Pike’s previous languages in the Go family
(Newsqueak, Alef, Limbo) were influential.
Go adopted semantics (safety and memory model) that
are quite unsatisfactory.
- Shared mutable state.
- Global GC.
- Null pointers.
- No RAII or destructors.
- No type-parametric user code.
There are a number of other fine coroutine / actor
languages in development presently. It’s an area of
focus across the PL community.
I don't know that all of the Go bullet points are correct.
For one, Go doesn't have RAII or destructors specifically, but it has "defer" and runtime.SetFinalizer which provide similar capabilities.
Also, does Go necessarily have global GC? My understanding is that it currently does, but that's not part of the language spec... could it not in theory use reference counting or per-thread GC?
The other points seem pretty dead-on.. Rust seems to prioritize safety over simplicity, which is probably a good thing.
Thanks for that. It wasn't clear from the linked article that Rust was started before Go. The overall impression that I got from TFA was that Rust is another instance of the garbage-collected system language fad.
What are the other instances? Besides Go, I don't recall many languages that fit the bill. There's D, but it's not very new and certainly not a fad language.
I think the fact that Rust is older and yet Go has 1000s of active programmers is indicative of something. "Ship early, ship often" springs to mind. The Plan9 community has been working like that for years, almost every day an updated version is available (the distro cdrom is rebuilt every night) with bug fixes / improvements / new stuff.
Go is the product of people who's work automatically gets attention and is backed by Google. You still might be right, but Go is probably not a useful example.
* Rust has more predictable memory/cpu usage thanks to forgoing global GC for a novel memory management model based on stack allocation/RAII, immutability, isolated processes and reference counting.
* Rust has a very Erlang-like model of handling failures.
* Rust has typestate, which is an easy to use way of proving properties about your program statically, or check them dynamically via assertion.
* Rust has no shared mutable state.
Those are facts. My personal, more subjective, opinion is that Rust is a lot better thought out than either D or Go. If this niche is too crowded, I'd rather see them go and Rust win. :) But given that Rust lacks shared global GC, I guess you could say it's closer to C++
I think Rust is very interesting and quite exciting, but it's hard to evaluate in relation to other languages (for me, at least) because it is really really young. I've never seen a useful program written in Rust. All of the features sound really good in theory, but I've never used a similar language, so I don't have a sense for how these features work in practice.
Actually, anybody have a link to some non-trivial Rust code?
That hardly strikes me as a feature. Null pointers simplify a lot of error-checking. Don't know if what you got back was valid? As easy as checking to see if it's zero!
The last time I checked, it was bootstrapped in OCaml. When I met Graydon several years ago (brilliant dude, PS), he was quite intrigued by OCaml, and strongly recommended I check it out. If ML had any influence at all, it uses variant types instead. About time more languages use them!
Rather than, "oh crap! every single variable could potentially be null at any time!", the few functions that can be null make you check for None / Some 'a, and that's it, no tedious null checks ever again. "Null pointers simplify a lot of error-checking.", my ass.
Yes, it does have variant types and pattern matching, and an option type in the standard library, just like ML.
Contrary to ML, it doesn't require variables to be initialized when declared. The typestate system checks (statically) that they are not referenced before initialized.
>Contrary to ML, it doesn't require variables to be initialized when declared. The typestate system checks (statically) that they are not referenced before initialized.
Look deeper, there is a rich world of Programming Language history and research linked from Rust's FAQ. Don't cling to your Java or C/C++ null pointers.
Not entirely sure what distinguishes them, but I'd rather have some competition in the niche than avoid defaulting to the first language that addresses the niche.
Not a whole lot, conceptually, it seems. The syntax feels very Nemerle-like to me, though, which is nice. Definitely something to play around with, if nothing else.
Having seen early versions of Rust (I work at Mozilla) I can tell you that the syntax is the last thing they're even considering (though that may have changed over the past few months). Seems like Graydon wants to get the guts right first.
The boundary between a file format and a programming language is fairly fuzzy too.
I recently created a custom "little language" as a replacement for some rather fragile configuration routines. It won't need a lot of users to be a win.
(and no, it wouldn't have been faster/easier to use Lua/Ruby/Python etc).
New programming languages are never necessary, but they should scratch some itch. Something that was cumbersome in other languages should be easy in the new language. Or the new language should be the union of things that only existed disjointly in other languages. Rust seems to fall in that latter category.
There's a spectrum from machine code up to high level languages. Pretty much all the points on that spectrum already have languages on them.
We absolutely don't need any more languages. Languages aren't a problem that needs fixing.
But they're fun to create, which is why people keep creating them. Also it's very much a 'social' and fashion driven thing. Some people can't bear to be using 'last years' language.
Keeping Multicore machines busy is a problem that needs fixing and it's also an example of a problem amenable to a solution in the form of a new language.
In the limit (as you must know already), there is nothing you can do in code that could only be possible through the creation of a new programming language. New languages don't make the impossible possible; they make some possibles tractable, and which ones are more so varies by language.
Kudos to Mozilla. The chance of failure for this project is very high -- there's lots of new languages coming out all the time, and existing languages have huge infrastructure advantages. It's nice to see organizations take a flyer on something that has the potential to really make our lives a lot better.
Rust's design decisions make much more sense than Go. Rather than designing C+++, they've ditched shared mutable state, a global GC and null pointers, and the stupid parts of the C syntax.
It may be that we'll see more languages in the future rather than seeing more language consolidation.
As Moore's Law for processor speeds hits a wall, programmers are going to have an incentive to take advantage of the parallel/multi-core CPUs that are appearing in lieu of actually faster CPUs.
Parallel programming is inherently less general-purpose than single threaded programming - there are a narrower range of things that you can do really quickly. I'd suspect that even doing that narrower range well will be more dependent on the memory/communications/threading model you use.
If this is true, it seems logical that we'll see a wider variety of languages in the future rather than having things consolidate. One language might better for simulation, another for 3D manipulation, etc. I'd also imagine chip-makers would start to look at the languages which can target
The standard Von Neumann architecture has allowed the general purpose computer to be relatively dominant product (even purpose built-machines often just leverage general-purpose chips). Parallel architecture would tend to allow the reappearance of purpose-built machines so-designed from the ground-up with all the differentiation that this world previously had.
I tend to judge languages solely on their aesthetic utility unless they're designed to make something very difficult possible (e.g. Erlang). And this one isn't any more pleasant to read than Java or C, it just happens to be a little different. Given the long list of advantages to using Rust, why they can't use an existing syntax?
Also, I've always felt queasy about using -> or => as arrows. And the word 'let' instead of 'def' or 'var' gives me a strange flashback to middle school which I can't quite pin down.
I suspect this is an artifact from their stance on mutable state, and some inspiration from more functional languages. There certainly isn't much harm in being clear where you are initializing variables. I would say that using actual english words rather than brief non-words such as def or var makes the syntax more readable.
If the keyword really bothers you that much, couldn't you fork the project and perform a global find/replace? (yes I realize that _maintaining_ a fork like that could be nightmarish, but the point still stands)
int i = 0 not code because modern compilers don't need to know about int at first. The compiler wants to now that you creat a variable the type is not importend at that moment. Thats why most new languages like go or scala have the type after the inizalisation.
Is it an int? An int32? An int64? Is it unsigned? Maybe it's actually a float which just happens to be initialized to a valid integer value. In that case is it a float or a double?
Literals can map to multiple types, and there hasn't yet been discovered a satisfactory way--apart from guessing in cases of ambiguity--to support type inference for literals.
That depends on your definition of "satisfactory" - F# uses strong type inference on literals and there is no ambiguity. Of course this means that distinguishing between types requires metadata, for example 42uy is an unsigned byte, 42L is an int64, 42I is a bigint and 42N is a BigRational. I think this is satisfactory, although you might disagree.
Scheme/Lisp compilers already allocate variables on the stack when it's safe to do so. It isn't always safe to do so. The part about "lambda-blocks w/o heap allocation" describes a missing feature, not an innovation in concurrency or efficiency.
I cannot believe that in the age of multi-core and distributed computing on the cloud, programming languages are still being designed with for-loops and iteration as the basic construct?!? Good luck parallelizing that!
*Have you seen this Google language, Go? How does Rust compare?*
Yes.
Rust development was several years underway before Go
launched, no direct inspiration.
Though Pike’s previous languages in the Go family
(Newsqueak, Alef, Limbo) were influential.
Go adopted semantics (safety and memory model) that
are quite unsatisfactory.
- Shared mutable state.
- Global GC.
- Null pointers.
- No RAII or destructors.
- No type-parametric user code.
There are a number of other fine coroutine / actor
languages in development presently. It’s an area of
focus across the PL community.
tl;dr, Rust seems to not ignore the last 20 or 30 years of computer science.
Indeed. Go seems inspired by the last 20 or 30 years of computer engineering (it is built from concepts that have been proven to work (and often not work) in the past), and Rust seems to take into account the last 20 or 30 years of research. In my view, Rust has more potential, but Go is a safer bet, at least until Rust has been used for a fair bit of Real Code (tm).
Maybe because this guy is passionate about making a new systems language, instead of solving the problem you want solved?
I never understand people who complain that free project X exists, when those people could be working on Y which is obviously more important. As if production and enthusiasm were both zero-sum and fungible.
Also, as someone who works with systems languages every day, I can tell you that there's a need for this work. I'm not saying Rust is it, but the systems language space is pretty dead, which is scary in a world where processors are threatening to become parallel on scales we don't know how to deal with with traditional tools.
Lets be clear, the author of the blog post asked an explicit question. If the question was, "Can I do whatever I want, and screw what you think?", I'd answer, "Of course you can".
But if you ask me "Do you agree?", well do you want my answer, or do you want me to simply say, "If that's where your passion is".
My honest answer, no I don't agree. I don't think we need a systems language of this sort. And I think there's a bigger gap that I'd like to see Mozilla work on, although maybe this blog post author isn't the right person to work on it.
His argument against Bytecode is unconvincing, in particular version hell and optimization limits in bytecode. The part that is convincing is the fact that we can't get vendors to agree on a bytecode.
It's unfortunate that the most popular platform in the world will continue to look like it was cobbled together by CS 101 studwents who weren't particularly great students, and were drunk.
People thought Windows 2.0 was bad as a platform. It's like we have Windows 2.0 for the life of the web because there's too many vendors in conflict to actually make it decent.
My "argument" against bytecode on the basis of inevitable version hell and bytecode-lowering tending to overspecify against alternative implementation and optimization strategy is fundamentally an observation: both Java and .NET were designed for one particular language first, and the intermediate code design reflects this in many hardcoded and hard-to-change ways. Not only in what was put into the bytecode, but what was left out.
Both the JVM and the CLR fail to run other than their premier languages, or nearby languages, very well (fast enough or with all features in the "port"). Continuations? Hah. Invokedynamic has taken way too long and the JS VMs have run laps around the JVM.
Yes, browser vendors will also not agree, and for these good reasons among other more "selfish" ones. Get over it.
F#, IronRuby, IronPython, COBOL.NET, Fortran.NET? Arbitrary standards compliant C++ even compiles down to MSIL (the resulting bytecode is ugly, but works). But in any case, I wasn't suggesting we use the JVM or the CLR. I'd be fine with a bytecode that wasn't supported by either.
This would be a long lead item, but one worth doing. I know the Mozilla folks got a kick out of the recent IE9 DCE issue, but I think most people who don't really care about your rivalry, agreed with your assessment, but thought that it continued to show how broken that JS is as an IL.
The point of doing this is to really get a bytecode that will allow language designers to build performant languages that still are first class citizens in browsers.
Unfortunately, the end result, as you say, is that we as developers need to simply get over the fact that we should expect more of our vendors.
It's ironic that people speak of everyone will build webapps with HTML5, yet when Apple and Palm pushed web-centric apps, no one showed up. When they moved to a "desktop"-model, the apps came. Its apparent why. The web doesn't care about devs -- and unsurprisingly the shallowness of most web apps is the result.
Microsoft with all its resources, and without having to standardize and version-lock IL bytecode across the web, managed over 10 years to build other languages, but the only credible one in my book besides C# is F#. The Iron languages are lagging versions of their progenitors. I'm not the guy to evaluate COBOL.NET and Fortran.NET. For some reason you left out the failed VB7 (aka Visual Fred), which is grist for my mill.
That IE9 Dead Code Elimination JS optimization that seemed strangely overtuned for one SunSpider test has nothing to do with JS source vs. bytecode. It does show how poor the industry-standard benchmarketing tests are (Apple is fixing to use the result of the loop, btw).
If you assume DCE happens upstream of transformation to bytecode, you assume more tooling than most web developers I've spoken to prefer to run. And anyway, web developers generally don't write useless yet computationally expensive loops!
But let me agree that it's possible a bytecode for JS could catch on, if only it could be standardized and implemented in all the top browsers.
Then we would have the versioning and future hostility problems I've mentioned, along with some other languages than JS being developed, which might or might not catch on.
So why don't we standardize some (or any, to read your comments) bytecode? I listed reasons including NIH and patents. Those are the "bad" ones but they're real. I don't think they afflict Mozilla, so kindly spare me your inflamed sense of grievance against "vendors".
We can treat minified Javascript as an IL and ignore it, if only we had some data format for source pointers and a few bits of additional debugger support. Someone could implement this in Chromium and Firefox and it might become a defacto standard.
mozilla does not have the power to create a new lingua franca. JS is the language of the web they are in the mittle of the standartisation why would the complicate stuff even more?
The key people behind Rust are also on Mozilla's JavaScript team (one of them is Brendan Eich, the creator of JavaScript), and they are active in the ECMA process that's defining ES5 and ES Harmony, which are "fixed up" versions of JavaScript. Firefox 4 contains one of the first implementations of many of the improvements in ES5.
But high-performance JavaScript VMs and rendering engines are not written in JavaScript; today they are mostly written in C++. Rust is designed by and targeted at the people implementing the VMs. It's the language they hope to use to implement future JavaScript compilers.
There was no need for assembly -- writing straight machine code worked. There was no need for C -- writing straight assembly worked. Etc, etc.
There has never been a need for a new programming language, but new programming languages can make life easier, can save you time, can make new optimizations possible, etc. So he's right in that we flat out don't need any more programming languages, but that doesn't mean creating new programming languages is a bad idea, or something we shouldn't do.