Maybe I'm crazy but it seems like a lot of these recent new languages are missing the mark. If you're designing a language from the ground up why wouldn't you build unit testing as a first class citizen, for example? As well as profilling and instrumentation. How about a modular compiler that can round-trip back and forth between raw source and commented parse trees so you can do much smarter merging in source control?
So many languages seem to be aiming at targets that are pretty far away from the major pain points for the normal developer.
Unit testing is a first-class citizen in Rust. You can annotate functions with #[test] and they become unit tests. You can then run tests with the built-in test harness on a module-by-module basis.
Profiling and instrumentation are possible using the standard tools (xperf, Instruments/DTrace, perf/oprofile). Rust works just fine with those.
Not sure what you mean by "round-trip back and forth between compiled code and commented parse trees", but Rust contains a pretty-printer which preserves comments.
In my view that's still just bolted on unit-testing, though very thoroughly and seamlessly bolted on, I'll give you that.
What I want are tools that help manage the complexity of unit testing, built-in where it makes sense. For example, creating mock objects and ensuring they are reflective of what they are mocking is difficult. Imagine if you could take the built-in asserts and the unit-tests for a component and use them (or some tagged subset of them) as a spec. for automatically creating mocks. Imagine if determining unit-test coverage and which tests should be run based on code changes was automatic and trivial. Etc.
Certainly profiling can be performed on any binaries provided you have symbols for them, but is that really the best we can do? I have a hard time believing that adding support for instrumented binaries at the compiler level isn't a good idea.
What I mean by "round-trip between code and parse trees" is the ability to have easy access to parse tree structure either in code or to external tools. So that you can do things like easily build in refactoring support to IDEs, or to more intelligently merge code changes at a higher level than merely lines of text in a file.
Of course, none of these ideas are anywhere near fully baked, they would require research, experimentation, and a lot of hard work. But I'd rather see people pushing the boundaries of programming languages with novel research rather than just throwing yet another mashup of already existing features out into the wilds in hopes it'll survive.
Can you clarify a few things, these are bikeshed issues but they bother me none the less.
* Why was fn foo(bar: int) -> int chosen and not fn foo(bar:int): int?
* Why annotations within comments? Annotations aren't comments it smells of C bolt-on. Why not keyword annotations?
I've always believed that a language should have as little native as possible; the more you can off-load into a library, the better because it lets people extend the language in the language.
Why have first-class unit tests when they could be built on top of some other feature? If tests are part of the language, then using a different testing system (say something in the style of QuickCheck) would probably be at a disadvantage; if you have a language that can support expressive testing as a library, then it would be possible to add different styles of testing.
Heh, I actually thought about that talk (and Guy Steele) while I was writing my post. I wanted to include a quote from there, but didn't remember the title of the talk. Thanks for finding it :)
Edit: Actually, I was thinking of a different talk. Or maybe just a random quote I saw somewhere. This talk is still very interesting.
Tests are mostly built-in to make sure there's no excuse to not test, but it is intended to be minimal and that other test frameworks can build off it (though it's not clear exactly how yet).
So many languages seem to be aiming at targets that are pretty far away from the major pain points for the normal developer.