Other features that I would put in that category:
- string interpolation
- a repl-like environment (fast startup, interactive, not requiring one to define a function or class to get some output)
- convenient syntax for initializing arrays and hashes
- generics as a most-of-the-time substitute for weak typing
A REPL environment is more of a tool chain issue than a language design issue.
Moreof, maybe, but it is language design, too. If you had a Java REPL, you still would have to type quite a bit of stuff (a class and a function) before you would have your "Hello, world".
Yes, you could add an implicit class named GLOBAL that magically gets a property named 'P' the moment you type
P = "Hello, world";
Most java code is valid Groovy code and it has some nice dynamic features, syntax sugar and has closures. I am currently using it to hack together a small DSL to easily configure a transformation from XML -> CSV
Here's an example of a Groovy session (From my instance of IntelliJ IDEA through Tools -> Groovy Console)
> P = "Hello world!"
Hello world!
> sub = P.substring(5)
world!
> sub ==~ / wo.+/ ? println("World") : {}()
WorldUp to Java 7 you could say "most" but why not "all"? Was it too difficult to test full compatibility? Why is the == slightly different between Java and Groovy, and the rest of the little differences which only confuse? And as for your example it doesn't look in the slightest like Java...
P = "Hello world!"
sub = P.substring(5)
sub ==~ / wo.+/ ? println("World") : {}()
Facebook uses PHP for much of their server-side stuff. They did a PHP compiler to make that tolerably fast.
Mozilla's Rust has potential, but I'm not convinced they have the "owning" logic right. Supposedly 10% of the code in Servo, their browser renderer, is "unsafe". That's far too high. They've had their first good big idea, but I think they're one or two key concepts short of definitively solving the problem of memory safety without garbage collection.
Swift I don't know about.
Interestingly, these are all hard-compiled languages. Most of the "flexibility" of scripting languages has been removed. It seems that the one scripting language feature programmers really wanted type inference for local variables. That's a feature of Go, Swift, Rust, and PHP. Even C++ has that now, with "auto". (Writing iterator type declarations in C++ FOR statements was a huge pain.) It's almost better if function parameters have hard types; you can look at the function definition and see what it wants. Python and JavaScript leave you wondering "what type is parameter 3 supposed to be, anyway?"
There's some syntactic convergence, too. Go, Rust, and Swift all use C-type brackets. Python indentation style control structure didn't catch on. We're also converging on "name: type", instead of C's "type name" form. That was a design mistake in C; the language became context-sensitive when "typedef" was added and the compiler had to known which words were type names. Where to put semicolons, though, is not converging.