I'm in this camp as well. I've always enjoyed JS because I feel like I can get stuff done so much quicker. With ES6/2015, now I feel like it's far more powerful, elegant and fun to use.
Picat. A new language that blends different paradigms including logic programming, constraint solving, pattern matching into a cohesive whole. Allows for very compact, elegant solutions to many problems.
Haskell, seeing I still have so much to learn. Elm, because there seems to be a sane web frontend language. Swift, because I can do daily work in a modern language with so many parts done right.
Rust: it provides extremely strong guarantees about your code at compile time so that usually it feels like a script language with C/C++-levels of performance. And the best part: no data races, and no runtime garbage collector overhead.
If they'd be interested in sharing more about their usage of Rust, we'd love to have them represented on our page of corporate users at https://www.rust-lang.org/friends.html .
Depending on much experience you have with ML-y type systems, Rust will either feel a little boring or like a revelation. The combination of pattern matching and algebraic data types is incredibly powerful and expressive and unlocks a style of coding where what in other languages would be potentially buggy logic that needs to be tested becomes mechanically checked typing information. Often, code can be trusted to just work if the type checker accepts it, which is especially handy if you make major changes to a large programme. Rust also favours immutable data structures, which also means some classes of bugs stop showing up in most cases. I've found these things to be a major productivity enhancement, maybe on par with going from manual memory management to garbage collection.
Which is another reason to be excited about Rust - it is to the best of my knowledge the only new language that allows you to write an entire programme or part of a programme that does no runtime memory allocation. While GC in most languages is not problematic in most cases, this makes it suited for embedded or hard-realtime work where C/C++ may have been the only option up until now. But it still has all these expressive, high-level features and safety mechanisms that makes it so suitable for programming well-structured, trustable software. There's a learning curve moving from GC to the ownership system, and maybe a plug-in garbage collector makes sense in some cases, but then the system does support that.
And then there's the tooling. Setting up a cross-compiler (again, embedded work), bringing in libraries from online repositories, packing up code modules for distribution and reuse, all that, is as easy as you'd expect coming from the web world because of the excellent Cargo system.
In short, while it might not be completely battle-tested yet, I think it has a better shot at being the "one language" that scales from tiny throw-away projects to large, complicated ones, and from watches to super computers than anything else I've seen.
As rvense explains below, there are a number of very desirable consequences to rusts strong static guarantees, and even performance improvements, all while getting less buggy code. It's even more secure in the sense of being less exploitable: the bugs being prevented by the type checkers are largely about resource allocation e.g. memory but also file handles. And those are often easily exploitable when not properly managed. That kind of compile-time bug prevention is something runtime garbage collection (that is, every VM platform out there) has yet to achieve and so is pretty amazing if you ask me.
Another consequence is the sheer range of applications for which this language can be practically used: systems and concurrent programming obviously, but also Web, realtime, embedded and even supercomputer programming.
The reason for that is that rust mostly feels like a light weight scripting language like python, but because of its performance characteristics can viably be used as a drop-in replacement for C.
None, because the existing languages were close to good enough for the problems that I try to solve. There's nothing that's opening up new frontiers in a mind-blowing kind of way, at least not from where I stand.
But some languages are kind of interesting:
C++11/14, because it opened up some new ways of writing efficient code safely.
C# triggered by:
- Open sourcing of .NET
- Open Sourcing of Xamarin
I want to live in a world where writing mobile apps for multiple platforms with a single codebase becomes the de-facto way of doing things. C#/Xamarin seems like the only viable way to achieve that.
Go. I may have to teach a mathematician with limited programming experience how to write parallel* algorithms, and Go seems far easier than alternatives (like C++) for a beginner.
F# is excellent and the only reason I'd stick with .NET. Unfortunately, Microsoft doesn't think so, and continues to dump massive amounts of resources into C# while only paying lip service to F#. (See, for instance, the full-featured C# Interactive in VS. It arrived like 10 years late, but it's a much slicker experience, apart from the language.)
F# with C#-level tooling would be unstoppable. Though it's pretty fantastic as-is.
Develop and compile on Windows with MS tools, deploy on Linux. VS+VsVim does a nice job with F# (I tried Emacs with evil but it's not as good for F#). Deployment is as easy as copying an exe.
D (dlang). It's the C++ I always wanted. It's safe, modern, fast, and familiar. It's got classes with reference semantics, structs with value semantics, safe concurrency by default, support for functional programming, concise syntax yet with the C/Java/C++/C# flavour, speed, a compile-time complete D interpreter (thus allowing metaprogramming in the same language as the runtime language, almost lisp-like), plus all the common syntactic niceties we've come to expect from modern languages.
My only complaint so far is that the reference implementation has a stupid license, but most other D users just ignore the terms of the license. I had also found a performance bug in an stdlib function, but it's since been addressed in dev.
That's written tongue in cheek, and it basically means something totally different to what you understood.
The license doesn't forbid anything. At all. It simply states that it doesn't guarantee any use at all either.
Therefore, you can use it to do whatever you want to do, but because there was no guarantee, you can't sue the software creator.
I will paste the text here, for others to read it:
"The Software is not generally available software. It has not undergone testing and may contain errors. The Software was not designed to operate after December 31, 1999. It may be incomplete and it may not function properly. No support or maintenance is provided with this Software. Do not install or distribute the Software if you are not accustomed to using or distributing experimental software. Do not use this software for life critical applications, or applications that could cause significant harm or property damage."
Now my explanation: Don't use DMD it in a peacemaker. Or use it, if you thing the technology is suitable. But if you do use it in a peacemaker, and it fails, it will be your fault and not the fault of the creator of the DMD compiler. It's pretty much a standard disclaimer and all licenses have one.
The equivalent disclaimer text of the GPL license (used by gdc and lots of other software) is this (the original text is in caps):
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Anyway, the best part of D is that I think the confusing text will be discussed in their forums by their great community and something will be done about it.
Elm. Because it is super clean and easy to read. The compile time errors are fantastic. I feel, if my app compiles then it is going to do what I want. Not so when developing with other JS frameworks. The whole paradigm feels like it is build for making web applications.
Racket - I love everything about it. It has Functional Programming that makes sense to me, I went through Haskell books 3 times over the years and took a few weeks to be flying with Racket.
As a scheme guy in general, I myself am very excited by typed/racket. I have always been torn between ML-like languages and lisp-style, with the latter winning most of the time. I have gotten so used to the syntax that I prefer it to most other languages.
But I miss the niceness of typing, which typed racket provides. There are some warts, like having to explicitly typecast when using two polymorphic functions, and that the curry procedure doesn't work as in racket, but other than that it is not far from what I would perceive as the perfect language.
I could of course wish for some other things, like making a curried and strictly typed scheme-like language, but i'm not going to push my luck :)
Crystal: Syntax inspired by Ruby, static types and compiled by LLVM. The standard library is mostly similar to Ruby (I'd say it's better. For example it rack-like functionality and websockets built-in). It's getting a lot of traction in the community.
Sidekiq was recently ported over to crystal and the speedups and memory usage improvements are amazing. There's also an officially supported heroku-buildpack so it can be deployed easily.
But there's a lot of breaking changes in the language (0.18 was released a few days ago with a few breaking changes). I would not use it for a long term project (yet). But for some personal project or prototypes, for example which you'd quickly set using Ruby/Sinatra, I'd choose Crystal/Kemal.
Clojure. Particularly with Paredit mode in Emacs. The experience of manipulating semantic units of code vs. editing text is a joy and I really, really miss it when I return to e.g. Python.
104 comments
[ 4.6 ms ] story [ 156 ms ] thread// 1. [a + b] // [a + b] is an array {[a + b]: c} // [a + b] is not an array
// 2. { x, y: x, y} // inconsistent object fields
and there are more examples. After you get to know the syntax, it can be used for good -- but some decisions are making the language more complex.
As written above, I enjoy its new features
var b = {3: 4}; b[3] // [3] is not an array
Jokes aside, ES2015 hits the sweet spot for new powerful languages with big-name backers (facebook is compiled in babel).
https://twitter.com/amasad/status/631251607422787584
https://github.com/tc39/proposals
Which is another reason to be excited about Rust - it is to the best of my knowledge the only new language that allows you to write an entire programme or part of a programme that does no runtime memory allocation. While GC in most languages is not problematic in most cases, this makes it suited for embedded or hard-realtime work where C/C++ may have been the only option up until now. But it still has all these expressive, high-level features and safety mechanisms that makes it so suitable for programming well-structured, trustable software. There's a learning curve moving from GC to the ownership system, and maybe a plug-in garbage collector makes sense in some cases, but then the system does support that.
And then there's the tooling. Setting up a cross-compiler (again, embedded work), bringing in libraries from online repositories, packing up code modules for distribution and reuse, all that, is as easy as you'd expect coming from the web world because of the excellent Cargo system.
In short, while it might not be completely battle-tested yet, I think it has a better shot at being the "one language" that scales from tiny throw-away projects to large, complicated ones, and from watches to super computers than anything else I've seen.
Another consequence is the sheer range of applications for which this language can be practically used: systems and concurrent programming obviously, but also Web, realtime, embedded and even supercomputer programming. The reason for that is that rust mostly feels like a light weight scripting language like python, but because of its performance characteristics can viably be used as a drop-in replacement for C.
But some languages are kind of interesting:
C++11/14, because it opened up some new ways of writing efficient code safely.
Haskell, because of HM types.
Lisp, because of homoiconicity and macros.
C# triggered by: - Open sourcing of .NET - Open Sourcing of Xamarin
I want to live in a world where writing mobile apps for multiple platforms with a single codebase becomes the de-facto way of doing things. C#/Xamarin seems like the only viable way to achieve that.
* (or concurrent)
F# with C#-level tooling would be unstoppable. Though it's pretty fantastic as-is.
My only complaint so far is that the reference implementation has a stupid license, but most other D users just ignore the terms of the license. I had also found a performance bug in an stdlib function, but it's since been addressed in dev.
Thankfully, there are other implementations with perfectly free licenses: gdc and lldc.
The license doesn't forbid anything. At all. It simply states that it doesn't guarantee any use at all either.
Therefore, you can use it to do whatever you want to do, but because there was no guarantee, you can't sue the software creator.
I will paste the text here, for others to read it:
Now my explanation: Don't use DMD it in a peacemaker. Or use it, if you thing the technology is suitable. But if you do use it in a peacemaker, and it fails, it will be your fault and not the fault of the creator of the DMD compiler. It's pretty much a standard disclaimer and all licenses have one.The equivalent disclaimer text of the GPL license (used by gdc and lots of other software) is this (the original text is in caps):
Anyway, the best part of D is that I think the confusing text will be discussed in their forums by their great community and something will be done about it.Lawyers don't have tongues or cheeks.
I have been told that Walter regularly tries to change the license but Symantec just doesn't seem to care.
Now that's sad :/
http://forum.dlang.org/thread/lodjbuvdhimrvrdngldy@forum.dla...
Elixir, to taste functional programming on the backend.
But I miss the niceness of typing, which typed racket provides. There are some warts, like having to explicitly typecast when using two polymorphic functions, and that the curry procedure doesn't work as in racket, but other than that it is not far from what I would perceive as the perfect language.
I could of course wish for some other things, like making a curried and strictly typed scheme-like language, but i'm not going to push my luck :)
But there's a lot of breaking changes in the language (0.18 was released a few days ago with a few breaking changes). I would not use it for a long term project (yet). But for some personal project or prototypes, for example which you'd quickly set using Ruby/Sinatra, I'd choose Crystal/Kemal.