Elixir. While Rust and Go get way more exposure lately, they're mostly designed for systems programming. Many more of us do web development, and it's really amazing how fast Elixir has become a very cool and mature environment for developing great web apps.

Elixir is a really cool language, and also a great way to learn functional programming. But more than that, it gets all the non-languagy stuff right. The build system is amazing, your code hot-reloads out of the box, dependency management is very well done (source-only, git-friendly, project-local, etc), the community is very friendly and going fast.

And code scales by default. I might exaggerate here, but sometimes it feels like need to really try to write code that's hard to spread across servers. If you consider it's non-trivial to even use all your CPU cores on Node.js, the Erlang VM will blow your mind.

I'm a web developer currently learning Haskell. Would you recommend learning Elixir instead?

No. You waste time if you half-learn something and then hop to the next hot thing again. Haskell is awesome too.

Do know that conceptually, Elixir and Haskell are pretty far apart. They're both functional, but that's about it. Elixir is dynamically typed, Haskell very much not so. It's a whole different approach to programming; where in Haskell, you'd "let the types guide you", in Elixir you simply can't do that. Elixir is much closer to Lisps in that regard.

I'm somewhat in the same position and I'm learning both. Haskell is great for learning new programming concepts like monads, applicative, and every other crazy thing Haskell programmers love. It also helps you think and get used to the concept of pure and unpure functions which definitely expands into other languages in a positive way.

Elixir on the other hand gives you a great development environment by default with ExUnit for testing, the Mix build tool, hex.pm packages, a tempting library, and more. All of the tools feel mature as well. Immutability with rebinding is great, concurrency is made simple compared to some other languages, and it also has the entire Erlang ecosystem of libraries to work with.

It's definitely easier to write Elixir, but I wouldn't say better. They're both great languages, just different.

For me, learning Haskell was a supremely educational experience. There is no better way to learn functional programming techniques and you will not regret learning it. That said I can count the number of times I've used Haskell in a non trivial application on one hand.

Elixir lets me use a lot of the stuff I learned with Haskell, and I've already used it building a real time component for an app I'm working on.

Take from that what you will.

As someone that hasn't heard of Eilxir before but has done a bit of Haskell. Haskell is mind expanding on it's own right.

I'm using snap in a freelance project right now. Haskell is also great for web development, keep at it!

I guess a lot of the benefits listed are a result of erlang vm.

I know what you're saying with respect to Elixir's distributed programming features (it seriously is great) but it's not that hard to use CPUs in Node: http://nodejs.org/api/cluster.html#cluster_cluster

http://elm-lang.org is a functional and reactive client-side (js target) language that is still young and getting great very fast. http://pragmaticstudio.com/blog/2014/12/19/getting-started-w... The idea of combining Elm with Elixir or Yesod (Haskell) on the server side seems exciting.

Another interesting project is Snabb Switch. If you want to learn networking at the lowest level and highest speed possible in software, Snabb a great platform for experimentation.

Finally, I'll throw in http://terralang.org. It's not networking related. But, I think it's terribly interesting and not getting any attention.

And even Elm with Clojure/CLJS https://github.com/jamesmacaulay/zelkova

The hype for Go/Rust is really just on HN.

If you are involved in data analytics then you could always immerse yourself in the Hadoop stack e.g. Cascading, Spark, Mahout etc. It's a platform that is increasingly become a fixture in enterprise companies and plenty of new technologies. For me the future will be "container driven development" where everything will be deployed as a container and dynamically wired together. Loads of new technologies e.g. Docker, Consul and plenty of challenges still around.

None of what I wrote is around languages/frameworks though mainly because I think that the majority of them won't be really used in 5-10 years.

I would have to disagree.

If you think it's just hype, try and calculate the enormous waste of both time and money from memory leaks caused by code written in C and C++. Rust solves this, and it's only going to get better once we're on the other side of Rust 1.0, and the library ecosystem grows.

I think by hype he meant enthusiasm : it doesn't mean Rust or Go is useless but that enthusiasm for this languages is far more present on HN than anywhere else.

> Try and calculate the enormous waste of both time and money from memory leaks caused by code written in C and C++. Rust solves this...

This seems like an unusual language feature to highlight --- don't most modern programming languages solve this problem with various implementations of GC or memory management? N.B. I am not at all familiar with Rust and so maybe I'm missing some important context...

Yes, but all managed languages will necessarily be less performant and less efficient than C/C++/D/Rust (barring a hypothetical future interpreted language with an amazing JIT and GC; LuaJIT has the JIT part down but definitely not the GC). Rust is specifically for systems programming. If you don't need to do systems programming, then sure, use C# or Scala or whatever you like.

Not just memory leaks... all the recent hacks/exploits are showing us that even the best people in our field can't write secure code in C/C++. You can reduce your attack surface substantially by using a language like Rust.

Imho, it's a scalability issue.

Was OpenSSL secure when it was originally written in X lines of code? Very likely.

Is it feasible to expect it to be secure now that it's X^Y lines of code, when a large class of bugs can exist in any line of code? No.

That's what 15 years of an evolving codebase has taught us. Which is reasonable, given that a lot of open source projects came into existence in the mid-90s. Inculcate lesson, design language for next 15 years. Not that radical.

Does it really matter whether it's a scalability issue though? The bottom line is that the code has bugs, whether it's due to the fact that the codebase is large is somewhat irrelevant.

By scalability, I meant more along the lines of, "Is it possible/efficient/reasonable to write large, secure codebases in language X using process Y?"

Answer A is "Yes, bugs come from bad development practices or unskilled programmers."

Answer B is "No, there are fundamental issues with the language that make it unreasonable to expect a secure product."

In other words, are the primary sources of bugs programmers or the ways the language forces them to interface with it?

The more I've been hearing about Rust, the more I'd like to try it. What's the equivalent of "_why the Lucky Stiff's Poignant Guide to Ruby" for Rust?

The official guide[0] is worked on by Steve Klabnik and serves as a good introduction to the programming language. Where you go from there is the hard part a lot of people interested in Rust struggle with. I recommend building a clone of some command line tool you like or if you're a Ruby/Python/JavaScript programmer try and build an extension for those languages but written in Rust instead of C. Good luck!

0 - http://doc.rust-lang.org/0.12.0/guide.html

You know what language Docker is written in, don't you?

Yes, lots of other cloud software is written in Golang as well.

If learning is going to be a hobby, then learn something different (because that gives you perspective), but also something that has some connections to what you already know (because if you learn something part-time, then it's good if you don't need to re-learn all tools, environment, etc.).

I would not care of the 'hot' stuff too much - frameworks come and go.

I'd try some Clojure (you're familiar with the JVM and IDEs, but one should learn a bit of Lisp once in life). Or Scala.

You're totally right the frameworks come and go, but on the other hand they come for a reason. And when I am learning a new framework there's usually something more I gain than just something to put in my CV. For example when I started with Spring I learned a whole lot of IoC and AOP. It was quite long time ago, but the principles that stand behind a framework might be very influential in the long term.

I like the Scala suggestion, because the last time I was involved with functional programming, I was using Haskell which I found quite difficult to grasp to a level that's useful for real-world projects.

Elixir!

On one hand it has a simple ruby-ish syntax and a solid MVC framework (Phoenix).

On the other hand it has immutability, concurrency through processes and message passing (which is awesome!) and a bunch of other functional goodies.

I'm not sure how widely applicable it is now, as it's still in its infancy, but it's the first "hipster" language I've used in a while that felt like it had legs.

Kernel is hands down the most interesting language I've used.

The Kernel language is small and simple, yet offers a huge contrast to how you would think about programming in most other languages - namely because other languages have reduced their model of computation to reduction.

Kernel is influenced by the Lisp family, but offers somewhat of a duality to it. In lisp, everything is passed implicitly reduced unless explicitly quoted, then they are passed verbatim. In Kernel, everything is passed verbatim unless explicitly evaluated - the callee then, has complete control over how something is evaulated, rather than the caller. (And consequently, it's trivial to simulate lisp's computational model in it)

Reduction then, is just a special case of a much more general computational model - passing arguments around. Other languages have coupled the idea of argument passing with reduction, such that they need to invent compiler hacks like macros or code generation when it turns out that reduction is not what they want. Or in some cases, we've created languages specifically for template-based programming, where we want to splice bits of code into an otherwise static block of text. Such templates are trivial to do in Kernel.

Another nice feature of Kernel is that of encapsulation types. One can define a new type which consists of a constructor function, eliminator function and a predicate to test for the type - and combined with the powerful information hiding that can be achieved through Kernel's environment model, one can implement sophisticated type systems using very few primitives, and without special compiler support.

Webpage: http://web.cs.wpi.edu/~jshutt/kernel.html

An implementation: http://klisp.org/

Others: http://axisofeval.blogspot.fr/2011/09/kernel-underground.htm...

Whoa! Noone mentions elm (elm-lang.org)?!

There is much brewing in language land. Rust brings a set of ideas that other languages will borrow (pun intended). But..

Elm restarts programming, treating events as lists, and this is how programming will change over the next 5-10 years in a most fundamental way.

Taken together programming is climbing out of the miserable non-composable mess that having been stupid bread-and-butter bit-fuckers have put us in. Elm just leads the pack.

You may not understand its ways, that is exactly because you think being a bread-and-butter bit-fucker is a feature, while it most definitely is not. It is a bug and it infests the code you write, up to the point where unlearning is an unsurmountable effort.

When elm's wave is through, the computer will replace you, and with it children will design much better programs than you do. Please stop making sense now.

How does this differ from FRP in Haskell?

It's ease of use. Elm first and foremost teaches programming. That happens to be in an exclusively FRP style, yet it ignores the usual evangelism. It is a practical language with automatic type inference and a simplified syntax.

But elm is a step on the road to a future where I believe that, when the dust settles, it will acknowledge that iteration, map, filter and reduce are as elementary as if-then-else.

So these operations (and if-then-else) will gain an iconic representation in the syntax, like punctuation. There is no need for words to be reminded of their function, the mere appearance of the program should suggest the flow and transformations they implement instead.

In other words, current languages are not FRP languages yet, but elm comes closest.

If you don't know python and you're interested in analytics you should solve that.

IMHO you'll become a far better developer if you devote the majority of your time to learning advanced algorithms, ml, and ai as opposed to the new hot framework.

I've already started, there is a bigger challenge though. That is, how do you sell this? I can think of plenty of scenarios for the oil and gas industry, which is the biggest industry where I live.

For example drilling for oil in sea is quite expensive, could easily cost over 100 million USD. With machine learning we can predict the seismic ground pattern by predicting the amount of clay, lime etc in different locations and between wells. This can help us to decide if there is a good chance there could be oil/gas underground.

The problem when I present this, is that it quickly sounds like science fiction.

Oil and gas already does a hell of a lot of computing, and invests heavily in supercomputing facilities. [0] I'm not too familiar with the domain, but looking at abstracts of conferences like the Oil & Gas HPC Workshop [1] might give you some idea of the work already being done in those fields.

It's entirely possible that machine learning techniques could be used as well as modeling and simulation for these problems. (They may be already! But my limited expose suggests they're mostly doing traditional HPC.) But you'd probably need to be a petroleum expert already, not just someone with machine learning expertise living in an O&G hub.[2]

[0] Just an example: http://www.aiche.org/chenected/2012/12/bp-building-new-houst...

[1] http://rice2014.og-hpc.org/

[2] Apologies, btw, if you are a petroleum expert who's just frustrated by a lack of machine learning in the industry. :)

No one asks for those in job specs though

Algorithms are definitely asked for in interviews at every company except small startups.

Not in my experience. And after 12 years in the industry, I never have to code any sort of sorting algorithm. Just chose the library where it has been done for you already.

It's good to hear that a lot of people are experimenting with functional languages like Haskell and Erlang, but I think we should step back a little and take a look at C++ and its development over the years.

As you probably know C++11 is already around and majority of compilers already support it. What most people don't know is that C++14 is ready to kick some ass too! It introduces for the first time in C++'s history functions as first class objects and allows you to pass them around as function parameters! I think this is really exciting and I also encourage as many people to take a look at this new and very promising developments of C++ language.

On the other hand, Apple's Swift looks promising too - functional elements, type inference, speed, good compiler and so on. Not to mention it's being used with tons of great frameworks Apple provides for iOS and OS X development. It sure doesn't hurt to take a look into it too.

All in all, it really is an exciting time for us developers. There are really tons of cool tools and languages that allow us to get things done at the speed never imagined before.

Now, we should also look back at the fundamentals and ask ourselves could we design, not only program? That's not the skill you can pickup in couple of days reading bunch of tutorials and forums about your next cool language. I think, learning how to think about particular problem and how to approach it is more important than barely know how to code the first solution that comes to your mind in the new ultra fancy language. Think about it...

Git is not the final word in DVCSes... Take a look at Mercurial, in particular, the Mercurial Evolve feature. It's an innovative way to collaboratively polish commits. Imagine pull requests that could be rewritten with the history of the rewrites being easily accessible as you see them, well, evolve. Evolve is basically a way to record and use distributed meta-history of the editions of your commits. It's like a beefed-up git reflog.

The problem is that in the open source world, most projects use Git and most active old projects using SVN or CVS are slowly moving to Git. Many people out there who greatly prefer Mercurial to Git admit to using Git much more than Mercurial due to the ecosystem.

See: https://fuzz.me.uk/git-vs-hg/

From Eric Raymond:

>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days. I have made my peace with git's victory and switched. I urge the Emacs project to do likewise.

That's fine. Take Evolve as an an example of how git itself could improve. I'm fine with Mercurial being an experimental display of features that could go into git.

Also, this whole popularity argument, if it were to be believed, could have killed Linux in favour of Windows or FreeBSD in favour of Linux. Just because something is popular doesn't mean that alternatives need to cease development or are not worthy of attention.

This thread started with a request for exciting new features. A certain degree of experimentality and non-popularity is in order.

I think the distinction is that Linux is very different from Windows in a lot of important ways, while Git and Mercurial are relatively similar in what they do and how they work. If someone invented a VCS that completely revolutionized the process (I really don't know how it could, but just hypothetically), then it could serve as true competition to Git.

This is one reason why D has failed to really take off. Both D and Rust are looking to essentially take C++'s place. D is C++ improved, while Rust changes the whole model of managing memory and also introduces some new paradigms (more type inference, pattern matching, etc.). D is clearly better than C++, but the two are just similar enough to make C++ a more preferable choice due to its immense popularity compared to D. Rust changes just enough to give it a chance at being a serious contender: the value may be higher than the cost of leaving C++ for many people.

The same applies to Git (C++) and Mercurial (D). Perhaps even more so, because while Git isn't perfect it generally "just works" for almost all use cases; Mercurial is just some simplicity and elegance on top of some workflows (which are sometimes emulated with wrappers over Git, like Legit). C++ on the other hand has a lot of warts.

Reading these replies just makes me sad. There's plenty of value in and plenty to learn from older technologies like Lisp, Scheme, Smalltalk, and Forth.

Sure, there's a lot of hype around newer technologies. There's never a shortage of hype. But the glow around virtually all of them will fade, probably sooner rather than later.

Ruby and Python are no longer considered hot and new, but not so long ago they were. Java and Perl had their share of hype back in the day, but the luster has certainly wore off by now.

Too many people involved in the tech field are endlessly chasing the next shiny thing.

It's definitely possible to learn things from those languages. But languages that are trendy today (at least from my experience in the London job market) - Clojure and Scala - are really amazing, too, and have a lot of interesting ideas about concurrency, immutable data structures, and functional programming. Scheme, when compared to Clojure, seems a bit outdated now IMHO, although its extremely simple, small core makes it great for teaching.

If Scheme looks outdated to you compared to Clojure, I'd wager you are speaking from an unfamiliarity with modern Schemes like Chicken, Racket, and Guile.

This is an unfortunate, but all too common a perspective, since most people who are exposed to Scheme are exposed to in in an academic environment where they only get to play with ancient, primitive Schemes such as MIT Scheme of SICP fame, and come away with an impression that Scheme is a quaint toy language that may be useful for pedagogy but probably nothing else.

Nothing could be further from the truth, if you consider the capabilities of the modern Schemes.

Racket is so different it's basically a different language, so I'm not really talking about that.

I do know Chicken and Guile have more advanced library support than the Scheme I worked with on SICP, but neither has as advanced concurrency features or advanced immutable collections, which is why Clojure seems to me a big advance on Scheme. Plus that you can leverage existing libraries on the JVM, plus its excellent compile-to-JavaScript support, etc., etc.

I view lack of dependency on the JVM as an advantage of Schemes over Clojure. The last thing I want to do when developing in Scheme is learn or have to deal with Java or the JVM.

Chicken compiles down to C, so gets C's speed, size, and portability advantages. Chicken can also access C, Python, and Perl libraries, which aren't exactly lacking compred to those of Java. Not to mention that Chicken comes with a respectable set of libraries on its own, and that R7RS compatibility will bring a much larger "batteries included" core.

Guile is looking like its going to become the core of Emacs, and is an extension language for various other tools (like GIMP), so there are wins for learning it if you are interested in any of these ecosystems.

How can you access Python and Perl libraries?

However you feel about the JVM, it has led to adoption of Clojure, meaning if you're in a big city you have a chance of finding a job doing it. Not many jobs exist where you can use Scheme as your primary language.

But the main reason I wouldn't go back to Scheme is that it doesn't have a rich array of immutable data structures built in. Too quickly the implementations I've seen capitulate to mutation, which makes code harder to reason about, harder to parallelise, and just less fun to write IMO.

I'm looking forward to Emacs implementing Guile, as Elisp is yucky. But realistically that's not going to happen very soon.

Here's Chicken's interface to Python: [1]

It also has bindings for R, C/C++, Lua, Matlab, Objective C, and even Java.[2]

I could have sworn it had a Perl interface too, but maybe that was just my fevered imagination, or an older version of Chicken.

You can actually build Guile-Emacs right now: [3]

  "As of the end of GoogleSummerOfCode 2014, the Elisp engine of Emacs
  is fully replaced with that of Guile, and most things Just Work™."

Though it's true that it'll probably take some time for Guile to be fully integrated in to mainstream Emacs, and for all the wrinkles to be ironed out. But the future is here.

I do have to give credit to Clojure for exposing more people to a Lispy language, even if the language does not measure up to my ideal of what a Lisp/Scheme should be. And I do grant that there are many more Clojure jobs than Scheme jobs. So if work with a Lispy language is your goal, Clojure is probably your best bet.

However, many people work on open source and personal projects using languages that they are interested in and actually like rather than those they are forced to use at work. There's also much value to learning classic languages very different to what you're used to, which I elaborated on in another post in this thread. For all of those reasons and the ones mentioned above, I'd still much rather use a Scheme than Clojure.

[1] - http://wiki.call-cc.org/eggref/4/pyffi

[2] - http://wiki.call-cc.org/chicken-projects/egg-index-4.html#ca...

[3] - http://www.emacswiki.org/emacs/GuileEmacs

Too pessimistic. The new learns from the lessons of the old. I'd advise a new student to start with tools that reflected advancements in thought and practice. It might be cool to use the old tools because they are part of history; but its not helpful to the new student.

If only they were advances rather than regressions. Far too much overhyped technology actually sets back progress by decades rather than advances it.

Unfortunately, "the new student", never having learned the lessons of the past doesn't know any better and is condemned to repeat mistakes and reinvent and rediscover poor imitations of older technologies while calling them new.

Ok, learning to code and learning to design languages are different tasks. Those writing 'new' languages would be well-served to study the history and progression of languages.

Those learning to code have enough on their plate, learning a mental model of computation and how to construct software for given tasks. History lessons are a case of 'too much information'

Developers can benefit from learning classic languages.

By learning the classics, especially those that are radically different from what you already know, you expand your mind and your sense of what is possible. It helps you get a different perspective on any given problem you may run in to, having seen radically different approaches to similar problems in the past. It puts another tool in your toolset and lets you select the best tool for the job.

Not that the above is not possible to get with exposure to hot new technologies, but whatever's hot in the market tends to be much more of a monoculture and popular due to being not too different from what most developers already know (Clojure and Scala being perfect examples).

Some classics are relevant today, like C. Others not so much, and won't help "expand" anyone's mind. COBOL for example.

Just as a side comment, the reason languages/tools are fun to learn is because it's usually quite easy to do so. You say you know R, but the depth of packages available for R is insane, and most of it requires a level of math that few possess.

I'd punt on learning a new language and instead master a new skill - up your stats knowledge, force yourself to learn how some algorithm works, whatever,.. these things are all infinitely reapplicable skills, whereas a pretty compiles-to-JS language or prettier-C-derivative generally aren't so much.

If your self-admitted problem is that you "have a hard time learning new frameworks that are beyond my work scope", it probably means your experience is deep but narrow.

If that's the case, you don't need to learn a hot/new technology, you need to cast a wide net and get a better grasp on today's software ecosystem in general, until picking up new things is no longer hard.

You could nonetheless kill two birds with one stone if you hacked on something current but wide. Docker and its ecosystems come to mind.

C is a pretty nice language, have a look ;)

I found this video series (https://www.youtube.com/watch?v=F3ntGDm6hOs) very interesting. It is someone (Casey Muratori) building a game from scratch using C.

The intro videos really opened my eyes to how powerful C is. Being able to directly access memory seems crazy for someone who is just used to dealing with languages that really remove you from the hardware.

+1. Learning C is not about learning a language. It's more about how to think like a computer.

When you program even a little bit, you already think like a computer. C is more about thinking a lot closer to the hardware, to the very low-level components of the computer. That's really an amazing universe.

Go learn assembly language if you really want to "think" like a computer ;)

This was my first thought as well- it's tough to go wrong by learning C. For me learning C was a brutal struggle (driven by necessity), but no other language taught me more about what is going on under the hood in software. C has withstood the test of time and will ground your programming skills better than any fad language or framework.

I second this. After using PHP, Java, Ruby, Python, JavaScript and various frameworks within each, "The C Programming Language" was very refreshing. It's fundamental, and made me think differently when using standard libraries in other languages, such as how they may work, etc.

Having done quite a lot of C myself I believe it's good for a person just starting off with software development, but I can't see myself doing it for fun, besides if I have a specific problem in mind.

Give Lua some love. Learn the language, learn the VM. Learn to integrate it with a set of libraries and so on. Lots of bleeding edge stuff runs on Lua and its a fantastic stack of technology to learn ..

>Give Lua some love.

Pun intended? LÖVE (https://love2d.org/) happens to be a great way to learn Lua.

So are MOAI, openresty, luvit .. Kademlua, elua, busted .. Penlight .. lapis, luarocks .. luamongo .. and last but not least, snabbswitch.

All projects from which I have learned a great deal of Lua. ;)

Is Luvit fit for production use? Which Lua web stack would you say is the most mature in general?

OpenRESTY is pretty darn good, I use it in production. Right now I've got a luvit project in the lab/on the bench that I'll pull the switch on and deploy, replacing a Node.js rig.. for no reason other than we want Lua everywhere and no more javascript .. so I'd say its ready, but my ready may not be your ready.

This is the first time I've read this sentiment, Lua is purported to have one of the leanest, fastest interpreters around (not talking about luajit of course). Can you talk about your experience?

The Grit Engine [1] and Love2D [2] are fun, useful engines that make making games easier, in Lua. Except they're slow as all get out; the only cap on the framerate is literally Lua. If you don't use spritesheeting to its maximum degree, you can't even squeeze out 60fps for a moderate size game.

[1]: http://www.gritengine.com/

[2]: https://love2d.org/

Sounds like a design fault in gritengine and love2d, not lua.

Try MOAI then. Its much, much better ..

Lua is quite fast. The algorithms you can implement in Lua are all slow unless you want to make an optimized structure for every kind of lookup you want to do. Lua reminds me of a hobbled javascript.

Right, that is of course the truth: LuaJIT is fast.

Nobody's mentioned Julia?! I love this language. I do scientific research and high performance computing and have been exploring this language extensively over the past year. Combined with something like iJulia (iPython), it's a very versatile tool for analyzing and processing data.

It's got a few quirks, but the language designers are improving it rapidly and the number of libraries available for it is increasing drastically.

To name a few features I really like about the language: multiple dispatch, flexible type system (use it if you need performance; ignore it if you want pretty code), powerful macro system, extensive debugging system (instantly view AST, LLVM, and native assembly output to optimize), easy parallelizability/vectorization, and just an overall beautiful language design (unlike C++ or Matlab for instance).

Things I dislike about Julia, but that should be changed soon: unintuitive automatic memory allocations (everything seems to allocate new memory by default which is a pain for tight loops because you have to write layers of functions that all take tons of "output variable" parameters), incredibly slow start-up times, and documentation that leaves a lot to be desired in terms of details (I normally have to call methods() in a REPL to figure out exactly what I need to pass into functions). Also, the module system seems a little more confusing than it needs to be.

I'd recommend learning how to learn. Making learning and curiosity a part of your every day existence will have more of an impact that the latest hot language or framework.

True, but I suspect that most people already agree with this, and it doesn't address his question.

I am compelled to agree with you, inasmuch as the irony of "what is the newest thing to learn" wouldn't be much of a hipster position if it weren't borne on the fact that must learn new things, always. Always. Since the beginning of social computing - when we've all had access to the same degree of technology - our languages, tools, and frameworks have always been changing. It is one reason for the existence of an ivory tower - sometimes you need to wizard-out, just to get peace from the noise. Trouble is, you inevitably end up casting new spells. There is no such thing as 'a brand new thing' to learn, alas the truly hipster edge can't be learned yet. ;)

"There is no wind that blows right for the sailor who doesn't know where the harbor is."

Decide and have clear what is the question, then look for the answer.

---

For the fun of learn, pick anything you can do and put some time of it. If you are like me, you will read some info about X and and if it pick you interest go ahead.

But without a direction, you will waste time. You will dismiss things that are good and double-focus in things that not..

----

"I am facing a lot of challenging (which ones?) data analytics and software development problems during the day (which ones?)"

"Data analytics (and his not-famous cousin reports)" is far more about re-shape and clean data than do cool algorithms. The last mille is the easy and the 909% (yep, 909%, not a typo!) is the hard, in opposite to normal development.

Having a clean, well defined schema/database/warehouse/etc is the thing here. Run your super-fancy mathy-thingy on it? Others have solved that!

Most likely, non-normal-dev will have a bigger impact on this kind of jobs, so not just focus in tech.. (and I don't drink the fallacy that your selection of tools not matter. But is also a mistake think that are the only thing that matter).

Get yourself a Raspberry Pi, Arduino, and/or a Beaglebone.

You wouldn't believe how much playing around with these units will help to influence your design and development decisions in other areas.

I respectfully disagree. I made lights blink for about a week and then lost interest. The lag time of "wait for something to arrive in the mail" is usually enough to discourage me, and without a coherent, large-ish project to learn on, I just never got that far.

I don't know that it's particularly new or hot, but I've been learning F# and I really like it. With Microsoft open-sourcing .NET Core and Mono getting a lot of improvements from it, I'd love to see this become a viable platform for doing web development on Linux with F# in the future.

Don't know how well you know Java, but look into Reflection and Annotations, it could simplify your development a great deal.

Also: http://blog.paralleluniverse.co/2014/05/01/modern-java/

This is a great blog post. While annotations and reflection aren't something new, I will definitely spend some time experimenting with the Java 8 new features.

Rust is awesome if you want to follow along and see how the bread is made. One of the best things about being involved in Rust since it was announced is being able to recount all the different paths it's taken and the reasoning behind them. It has taught me a lot about good language design, validated and sometimes destroyed some of my ideas about programming concepts and overall provided a great environment for questioning how things work.

I come from a C background however which is a little closer to Rust than Java/Javascript/R but I don't think you would hvae that much trouble if you put your mind to it. Java is a similarly large language if a bit removed from the metal.

It's not a hot technology ( read as overhyped ), but if you're in the analytics space and not using Python/PyData tooling then definitely check that out. It's certainly as mature, if not more so than R.

The thing that I am studying in my spare time are Agda and Haskell.

Haskell gave rise to bunch of strongly typed DSLs both for front-end and backend development.

Agda is sort of derivative of Haskell, and gives you powers to reason MUCH MUCH clearer about your code and what you want it to do.

I have wet dreams of using those languages on my everyday development. Esp Haskell.

http://learnyouahaskell.com/ http://learnyouanagda.liamoc.net/

When I catch some time I will fiddle with Elixir also mentioned here in comments.

If you're into analytics and data processing and want to learn something new, I would recommend Clojure[0]+Incanter[1].

Also, check out Cascalog[2]. Data processing on hadoop clusters has never been this simple and fun. Much better than Pig/Cascading/etc.

[0] http://clojure.org/ [1] http://incanter.org/ [2] http://cascalog.org/

OpenStack seems to be trending, if you are into the whole cloud thingy.

I've only been in contact with TaskFlow, the state and workflow management library that OpenStack uses, and I'm very impressed how well-engineered it is.

On a related note, OpenStack uses RabbitMQ, and that seems to be trending too. Not a huge hype, but a steady adoption by both open source community and enterprises. And if not RabbitMQ, then being familiar with some kind of asynchronous messaging framework certainly wouldn't hurt.

ClojureScript, along with Reagent (or some other React.js wrapper like Om or Quiescent - I currently prefer Reagent, which has been gaining lots of traction recently), Figwheel and a browser REPL, has really had a lot of impact on how I view GUI development.

I do Winforms development in my day job and I hate it. The feedback loop I have from changing something in the code to viewing it in the application can be a matter of 1-2 minutes (need to compile, start up, login, setup everything to the correct state, etc). Going from that to being able to grow the application in real-time, without ever having to restart/refresh, is amazing, and makes me feel infinitely more productive. Combining it with Cordova to make mobile web apps, where I can deploy once to my phone and then have changes be applied over wifi as I type them into my text editor, is super sweet.

Getting everything set up can be a bit tricky, but https://github.com/plexus/chestnut makes it a whole lot easier.

I'm learning Haskell right now and it's great. I don't know how widely used it is in production, but it's introducing me to tons of ideas that are applicable in lots of other languages (e.g., how to do functional programming effectively, how to effectively use a strong type system, how to separate out functions with side effects).

I think that functionnal programming is a good candidate. You can learn about it in different situations/languages. It opens the mind about the code and its design by exploring other patterns.

- http://scott.sauyet.com/Javascript/Talk/FunctionalProgrammin... explain how procedure ahem function composition leads to better/more readable code

- datalog is a DSL for querying (recursive/linked data) http://www.learndatalogtoday.org/

- The introduction to Reactive Programming you've been missing https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

Another nice DSL query language is Gremlin, for querying a bunch of graph databases. https://github.com/tinkerpop/gremlin/wiki

Gremlin is nice, powerful and easier to grasp. Datalog programs are more compact. I need more experience to know if datalog is as powerful. On the subset of queries, I used datalog, I prefer datalog.

> that's widely applicable

Other than Laravel (PHP), Python and Erlang (then Elixir), there's not much to try that's applicable. You'll be pleasantly surprised to see that your Erlang implementations are orderS of magnitude smaller (codewise) than your Java implementations, with different performance hurdles. Try new dbs like Redis or new messaging primitives like ZeroMQ. Find a basic analytics package like Munin or RDDTool.

I'm disappointed by the suggestions on this list, which is an ear full of bad advice. elm, kernel, julia? At least Lua is something that you will run into as an option, from time to time. That being said, you don't need to practice it. It's easy to treat it like a dumber version of javascript and you're fine.

I'd pick a type of project then pick a language/framework to learn. I'm not a big believer in learning something something just to learn it. You only get so far. I've got my own library of Haskell, Scala, and Lisp books but until I have something interesting to build, it's hard to maintain momentum. My two current projects are a Go web app hosted on Digital Ocean: http://thespanishsite.com

And I'm learning Swift to incorporate into my iOS apps. I've accumulated over 300 urls for anyone who wants to learn Swift: http://www.h4labs.com/dev/ios/swift.html

Thanks, it's very helpful. (And yes your website works well)

Your site seems to be down temporarily.

Seem fine. Both are running Go. Should be able to handle the load.

I've always taken the approach to decide on a new concentration to study, and then learn the languages appropriate for that. First time I did this, the concentration was databases, so I set about learning SQL and data design and relational algebra. I wanted to learn more about front end development, so I focused on JavaScript, DOM, and single page applications. Other examples abound. But having a distinct idea of an application I want to build before learning a particular language has always worked out better for me than trying to find an application after reading a language's documentation.

check: Technology Radar ; JANUARY 2015 ( by the ThoughtWorks Technology Advisory Board )

http://www.thoughtworks.com/radar/languages-and-frameworks

http://www.thoughtworks.com/radar/tools

http://www.thoughtworks.com/radar/techniques

http://www.thoughtworks.com/radar/platforms

For someone that just started learning how to program about 6 months ago, I decided on Python and R and can write all the basic stuff, but can't write a complete application yet. I've also decided on learning Angular too, but I've not made any serious attempt. And that was after evaluating all the other JS frameworks out there - Ember, Meteor, etc.

Now from reading these comments, it looks like Elm and Elixir are good to learn too.

So the problem facing someone that's just starting out, is what to learn? Where do you start? The options are many and can be confusing.

I think learning Python is a great decision if you're new to programming. It'll expose you to fundamental programming concepts like: statements, loops, conditions, functions and even go deeper into object oriented concepts like abstraction, encapsulation and inheritance.

I always recommend people who are new in programming to start with Python because it's really flexible, has rich set of libraries and it's easy to get started.

I recommend Nim http://nim-lang.org/ (the website docs don't look too good at the moment, but this has been fixed for the next version that will be out in a few days).

Nim is an incredibly good language that compiles to C, is fast, and has very easy bindings creation to any C library you want. For me, it's the best of both worlds between a Python look (indented, clean) and a fast typed compiled language that helps you instead of hindering you.

You might be interested in checking it out.

Oh, I'm so glad they've changed the former name (was Nimrod).

Consider Scala or Clojure. You'll be able to leverage the same libraries you've been using in Java (pretty trivially), while having access to a completely new way of thinking (functional).

I personally prefer Scala as I like strongly, statically typed languages, but I've played about with Clojure and it's very nice, too. A vast number of benefits come from having a rich immutable collections library.

Not a specific language, but you should try learning about functional programming (eg. Java 8, Clojure, Scala, Haskell).

Also, if you want a brief overview of different paradigms you should check "Seven Languages in Seven Weeks" (https://pragprog.com/book/btlang/seven-languages-in-seven-we...)

On the engineering side, I think you should learn concepts such as asynchronous programming, actor based programming and functional programming, and pick a new language (Swift, Scala, Go, Rust, etc.) and learn it.

On the more practical side, I think data science is a very useful tool, so learn everything there is to do with data today, from machine learning and data mining in small scale to big data processing.

Jeez, you Pivotal guys (sorry, "pivots") sure suck down that kool aid.

I guess I have.

Funnily enough, the best critiques I see of how we work comes up in our internal forums. I sometimes refer to Pivotal Labs as a debating club which produces code as a byproduct.

Hack something other than related to computer science and data. John Carmack once taught himself aerospace engineering...

What's recommended for an experienced "back-end" developer who wants to dabble in front end and web development, but never spent much time in it? It seems like there are a million options for web stack components, and a lot of tutorial resources are geared towards total non-developers.

JQuery. I have been trying to do the same (when I get a chance) for the last few years. Angular, Backbone, etc are a lot to learn, while JQuery lets you get basic stuff done.

well since you're using Java/JavaScript/R on a daily basis I would recommend Dartlang. It has futures, awaits/async, enum, SIMD. Works in client and server side. Its also really fast. www.dartlang.org

As a sub-question, I would be interested if the answer was restricted to frontend frameworks (eg. Backbone/Ember/etc.) for 2015. Thanks in advance.

If you're into SASS, I'd check out:

Susy: http://susy.oddbird.net/

Otherwise, if you're into the latest Javascript frameworks, I'd check out:

Aura: http://aurajs.com/

Kraken: http://cferdinandi.github.io/kraken/

SkelJS: https://github.com/n33/skel

If you're looking for something more "bootstrapish" but without all the "bootstrap" bloat, I'd look at some more modular frameworks like:

Semantic UI: http://semantic-ui.com/

Pure: http://purecss.io/

UIKit: http://getuikit.com/

Hope this helps. . .

Semantic UI author here. I just wrote a draft guide to explaining SUI definitions and the spirit of the library for those who are interested in learning a little bit more: http://learnsemantic.com/definitions/overview.html

Thanks for the extra documentation. Been looking into your boilerplate and I really like it. This will help me to really use the depth of this.

Thanks again for the heads up.

React.js http://facebook.github.io/react/

If we assume Ember, Backbone + friends, and Angular are already 'big', then React is definitely the one on the come up.

For all intents and purposes those 4 are really the only ones being talked about IMO. Polymer is thrown about too but from what I understand it's not exactly production ready (could be mistaken)

Backbone may not be the most popular, but you will learn a lot of transferable skills by using it.

Haskell

https://github.com/bitemyapp/learnhaskell

I haven't been as excited about anything in awhile as I am about Mesos. Program against the data center. Distributed by default. Fault tolerant everything. Lower your AWS bill.

Ah, now I see why you were pejorative about my being a Pivotal Labs employee.

I actually think Mesos is the best of the current generation orchestrators, for the same reason that Diego (Cloud Foundry's new execution system) is going to be the best foundation for PaaSes.

They both push intelligence out to the edges. Mesos pushes it to the requestor, Diego pushes it to the executor, but both represent a huge step forward over need a godlike central controller for a cloud system.

> Ah, now I see why you were pejorative about my being a Pivotal Labs employee.

Not sure I see the connection? I probably should have been nicer, you came off very shill-like though. Pivotal does kind of cultivate that attitude though, of "whatever we're working on is a disruptive, game-changing twitter-killer", but I guess it works for them since they managed to get a bunch of smart people working for early-stage companies without any stake in them and then training other people to take over their jobs.

I will have to look into this Diego, at least. Is there like, a white paper for it?

Seems interesting and that it occupies the same space as Marathon. Are you familiar with that and if so how do they compare?

I'm not familiar with Marathon, but I will read up on it. Thanks.

I find it interesting how everyone is sprinting toward PaaSes from their own positions. For example, Docker is racing up the stack, Hashicorp and Mesosphere are growing sideways, Cloud Foundry is growing in about 5 directions at once. Red Hat is trying to reboot OpenShift with Docker and Kubernetes, but I am not sure how well that will turn out for them.

There's also a thriving cottage industry of people reinventing central controllers that won't scale in the face of the network fallacies, something that Mesos and Diego have accepted and moved on from.

You said Javascript but didn't mention Node.js. I would recommend learning Node.js if you haven't done that already, just because it's so darn useful.