I'd go with a Raspberry Pi or other linux supported board. Particularly for prototyping.
If you're looking at building an interface, are you considering web-based?
I'm going to plug my own little project here, I'm also new to embedded development, but hate how everything is hard-coded to the platform you build on.
I built a hardware agnostic library to make it easy to run your business logic on different hardware. It's in javascript (I've asked anonymous_ian why he doesn't like dynamic languages in embedded). http://getfavor.net
Generally for embedded work, you want to avoid any and all complexity as much as humanly possible. In most critical embedded programming its all statically allocated and has shallow call stacks (eg: a call depth of more than 8 is forbidden).
For devices that connect to the internet, I prefer a two processor approach where a very simple processor does the critical work (eg: being a thermostat), and a more general purpose processor (raspberry pi, etc) handles the human interaction (GUI or webpage) and uses your more standard programming approaches. This way if the main CPU suffers a fault, it doesn't make the device worse than useless as the simple processor is doing things like making sure the commanded temperature is not too hot/cold, the temperature actually is changing when the heat is on, etc.
With dynamic languages or even using dynamic memory you can run into unpredictable pauses that can literally cause things to catch on fire (see 3d printer extruder fires).
I think it depends on the application, I agree it isn't for everything.
What I find a bit funny about some embedded stuff is that I don't think performance is always as important as in other systems.
Consider something like Nest. If it takes 50ms or 500ms for the thermastat to respond, what is the implications. Compare that to a webpage, and all of a sudden, performance isn't a prime factor. Another example is a decibel meter I'm currently building. I need it to send data to a server when sounds reach above a certain level. How important is performance in that scenario. As well as things like Amazon's nifty little ordering button, I'm quite sure performance doesn't really matter on that.
So, in devices where performance is a primary concern, at the moment, javascript probably isn't the way to go. Though, with progress in things like asm.js, that may change in the near future too.
I'm not suggesting this is the tool for everything, but as I look at it, IoT probably has fewer use-cases where performance is a primary concern than other environments.
Of course, probably all safety systems, self-driving cars, drones, etc. etc. are not recommended to be done in JS... yet.. :)
For the thermostat it could well depend on the context to how much the latency matters.
If your recording average ambient temperature it probably doesn't matter much. If instead it is part of a physics experiment it could matter a lot. If it is part of some industrial control system [1] it could be critical.
For the ordering button the time taken doesn't matter, but the less time it takes (especially with the wifi hardware), is going to be a factor in how much power it consumes, and therefore battery life.
Comments
I'd go with a Raspberry Pi or other linux supported board. Particularly for prototyping.
If you're looking at building an interface, are you considering web-based?
I'm going to plug my own little project here, I'm also new to embedded development, but hate how everything is hard-coded to the platform you build on. I built a hardware agnostic library to make it easy to run your business logic on different hardware. It's in javascript (I've asked anonymous_ian why he doesn't like dynamic languages in embedded). http://getfavor.net
Keen to hear your thoughts.
Generally for embedded work, you want to avoid any and all complexity as much as humanly possible. In most critical embedded programming its all statically allocated and has shallow call stacks (eg: a call depth of more than 8 is forbidden).
For devices that connect to the internet, I prefer a two processor approach where a very simple processor does the critical work (eg: being a thermostat), and a more general purpose processor (raspberry pi, etc) handles the human interaction (GUI or webpage) and uses your more standard programming approaches. This way if the main CPU suffers a fault, it doesn't make the device worse than useless as the simple processor is doing things like making sure the commanded temperature is not too hot/cold, the temperature actually is changing when the heat is on, etc.
With dynamic languages or even using dynamic memory you can run into unpredictable pauses that can literally cause things to catch on fire (see 3d printer extruder fires).
A good example of the lengths you go through for embedded programming is the JPL coding standard: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
edit: fixed grammar
It's a good idea but I'd be worried it isn't "snappy" enough on (somewhat slow) embedded devices.
I think it depends on the application, I agree it isn't for everything.
What I find a bit funny about some embedded stuff is that I don't think performance is always as important as in other systems.
Consider something like Nest. If it takes 50ms or 500ms for the thermastat to respond, what is the implications. Compare that to a webpage, and all of a sudden, performance isn't a prime factor. Another example is a decibel meter I'm currently building. I need it to send data to a server when sounds reach above a certain level. How important is performance in that scenario. As well as things like Amazon's nifty little ordering button, I'm quite sure performance doesn't really matter on that.
So, in devices where performance is a primary concern, at the moment, javascript probably isn't the way to go. Though, with progress in things like asm.js, that may change in the near future too.
I'm not suggesting this is the tool for everything, but as I look at it, IoT probably has fewer use-cases where performance is a primary concern than other environments.
Of course, probably all safety systems, self-driving cars, drones, etc. etc. are not recommended to be done in JS... yet.. :)
For the thermostat it could well depend on the context to how much the latency matters.
If your recording average ambient temperature it probably doesn't matter much. If instead it is part of a physics experiment it could matter a lot. If it is part of some industrial control system [1] it could be critical.
For the ordering button the time taken doesn't matter, but the less time it takes (especially with the wifi hardware), is going to be a factor in how much power it consumes, and therefore battery life.
[1] https://en.wikipedia.org/wiki/Control_theory