The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient to a doctor's gloves to the screen then to another doctor and another patient.

But I certainly defer to your expertise. These are the subtle issues that us non-medical guys overlook.

Like @Matthias247 said, QNX and GreenHill are easy to get up to speed from other RTOS, well documented, and arguably most importantly has name recognition so it'll be cheaper to get into hospitals, easier to get through the FDA certification process, and easier on your chequebook when you get your liability insurance. @viraptor offers good advice as to why RPi's are a dumb dumb dumb idea to base your product off of (who knows when they'll EOL their product?). Every component on your BOM should be from a reputable vendor who can tell you with the utmost confidence how long component X will be in production, the lead times typically seen, etc. @xzion did class B/C devices and mentioned EOL'ing so take his advice too. I'd even PM him and offer him a chunk of change to audit your unit before cert testing. (5k for someone to catch that EM your engineer didn't because his H-probe was oriented in the wrong direction is worth every cent). As a manager, I'd actually keep a resource on retainer who has taken an FDA embedded product to market as a consultant for my engineer to use as much as he wants, regardless of the cost (presuming my engineer hasn't done so himself, in which case, yay!). @analog31's definitely got good advice for his field but an FDA class C's requirements are entirely different from scientific equipment. Your $300k Keysight network analyser or $700k SEM might be okay to prototype against, but when my scope crashes a tech comes out and fixes it the next day- people don't die. When my Illumina sequencer fails, a post-doc might lose a week or two of work, bummer man, there goes his JAMA article, but no big folly. You can shop around a proof of concept for kit like that, (and likely have them take delivery of your rev 1 based on that same platform!) but I'd be very very concerned about EOL'ing anything on my BOM.

Make your BOM as jellybean friendly and as reliable as possible from the best vendors you could possibly afford. I strongly advocate ARM's for the following reasons. 1) IDE - Keil's MDK is basically the best IDE I've ever used (and I've used a lot). I can't even begin to delineate the functionality of it, just download the demo. It's better than having a bond-out chip and an in-circuit emulator with live debug. Really, it's crazy good and it's "free" (lacking some functionality) because ST subsidized it as a loss-leader (the first hit's always free...) 2) CMSIS-RTOS has a not-too-steep learning curve such that you could swap in any given engineer who's worked with on QNX4 and jump right in (for me, the learning curve was about as painless as Java 1.6 -> C#2 => ~2 weeks). Works on any M3 or higher (you aren't locked into any specific vendor), even licensed out with everything the IDE is reasonably priced as is the OS. So you don't run into the "Jane Street OCaml / Haskell shop hiring problem" of having a few pool of very very talented applicants, who are all in high demand as a result of their specific skillset. A good engineer won't have a problem. 3) Again, no specific vendor! If ST goes out of business (haha yeah right), NXP (a division of Philips) would definitely supply you with a same chip, with the same pin out, same package, same everything. Model everything on your BOM with a contingency in case lead times surge unexpectedly.

There are niche RTOS solutions out there (FreeRTOS works on ARM with a modicum of ST documentation. ST, Mentor, NXP, and all the other name-brands use it as the defacto standard if you're not going to go with a 'name-brand' RTOS.) eCos is probably the second pick with more of a hacker-community vibe to it, which, is probably good for getting that roto-copter's altitude up an extra few hundred feet but not really something you want your dialysis machine to be running on.

---

Here's an idea of what you're looking at (this is based on fed work from an engineering then from a bean-counter POV, but I've taken a Class B to market on the software side and it's got enough parallels that I feel this advice is pertinent).

Your cost breakdown is for first-product-to-market going to be 40% NRE for all the licensing, a board design engineer for your board layout (Cadence OrPCB / Altium 16 license), a software engineer with embedded experience (i.e., a good indicator is he's taken a lot of EE classes, or on the other end of the spectrum, has gone to the graduate level in theoretical computer science -- had great experiences with employees that fall into those categories) + Keil IDE or whatever, industrial engineer for your enclosures (Solidworks license) [you _might_ be able to bypass this step, but purchasing authorities ask "Can we change this font color" more often than "how efficient is it" - humans are significantly influenced by the aesthetics/how something interfaces with you. I'm guilty of this too, any industrial IP67 gear that feels chinsy, any relay that feels light, etc, I have a preformed biased against. (Aesthetics are a large part of Apple's value, along with exclusivity and status signalling; though, when I had my Macbook Air it felt like I could bend it in two, it's been on my desk for 3 years, and my daily driver is a Thinkpad I've neglected so much I'd have gone through 3 or 4 MBP's by now)

Legal and insurance will predictably be a fixed recurring (maybe 15%). Certification and re-spin costs can range from 5% to a lot more. Don't skimp on stupid things to save a few k here and there - pay a firm to do pre-EMI testing beforehand. Buy brand-name everything just as an insurance policy. $9 dollars extra for that precision thick-film resistor @ 10k vs $.13x10 might save you 8.70 a unit, but the engineering time it takes to find why your chip is clocking out spurious data but only once every 3 weeks at random times (oops, those resistors were 10% not 1%, which is normally fine except when you bring CE low for > x NS while doing Y, which heats up the bypass cap near Vcc increasing the ESR, and whoops, your cap's resistant factor is drawing an excess of current that shoulda went to Vcc! Again, Keil IDE helps so so much finding bugs like that.) Uh, yeah so, buy Nichicon and breathe easy. Use pre-certified industrial components that your competitors have already used if you can.

Office space can be finagled from other startups usually at pennies on the dollar. The commercial real estate market even in NYC is soft and I could get class-A space in midtown month-to-month at $3/sqft/mo (utils and furnished). I'd imagine SF is the only place where you'd have difficulty finding a reasonably priced space from someone who wants to let go of 800 or 1000 sqft. The rest is going to go to your marketing and/or sales team who will ultimately make or break you. Not for the faint of heart. If you don't have a mentor/family friend/guy on your board with existing contacts or know someone on the Cerner/EPIC/Meditech sales team with a big-fat Rolodex, you're going to be in for a tough, tough time. In government contracting (SBA, tiny contracts, fighting over the scraps really), we used to keep former decorated career military men on our board. They'd pocket 180k a year to literally fly down once every quarter and play golf while we got access to his Rolodex- medicine's the same.

See http://g02.a.alicdn.com/kf/HTB1fNYoHVXXXXbkXFXXq6xXFXXXt/Fre...

Edit: also when considering industry / medical devices, keep in mind that most touchscreen are not meant for the conditions these devices are in. You should be able to splash water / gel / oil / ... over it and just wipe it afterwards. They should also survive people who think they just need to press it harder if it responds slowly. Simple buttons (with extra protective cover) are more likely to survive this. Next time you're around in the hospital, check out how many of the button labels are completely worn down.

I'm not sure that C the best language for life critical high level applications... it's far too easy to shoot yourself in the foot.

Check this out: http://tobyho.com/2008/03/30/how-safe-is-your-programming/

There also used to be a website that ranked programming languages according to various parameters (which is faster, which is safer) by asking visitors pairwise comparisons (Which is faster - Matlab or C?). I was going to link it but can't find it unfortunately. Anyway I'm pretty sure C would come second-last in the safety ranking, right above assembly.

* Android, when the product offers a host of mainstream computing features. I think the rationale for going with Android is: "The user already knows how to use it."

* Linux, when the product is cheaper, and has a more bare bones or restricted function set. I don't know for sure, but I think that a Linux build can be more stripped down. Little boards like Raspberry Pi and BeagleBone abound, and if nothing else, you can create a nice proof-of-concept with one of those. I've actually done this, writing my code in Python, with the expectation that the "real" programmers would turn it into something else.

I'm not in the skill areas that actually develop this stuff, so I don't know any lower level details. My job tends to be supplying the theory of operation for the actual measurement.

Both systems use SOM's (system on a module) that are typically sold with the software tools to get you started, such as a working demo OS. It is rare to see real-time stuff done on the main computer. Since you're usually talking to some sort of device hardware anyway, it's usually more convenient to put the real-time stuff on a separate microcontroller, that's got little or no interrupt overhead to deal with.

Sure the choice of CPU architecture, OS, GUI Widgets etc will/should involve you but hardware choice is determined by user requirement, gui, reliability (watchdog timers, failure modes), power requirements, BOM Costs/long term availability, IP Ratings, enclosures, emi, electrical safety etc and is a totally different discipline which you need an EE and can seriously backfire and not get approval if not done correct.

Saying all that working as a programmer in a hardware business will teach you a lot of the above and give you a bigger influence in future projects.

You can potentially go with bare microprocessors and something like http://femtoos.org/ to just small ARM devices with windows. You can do everything on one chip, or split the device drivers onto separate chips and drive them over I2C where specific timing is crucial.

There are many options - I'd start with listing exactly what you need to support (display, io, inputs, timing, single/multi chip, what timing / other guarantees, hardware watchdogs, failsafe states, etc.) and then choose hardware/software based on that.

If you want to produce many devices, I'd stay away from consumer devices like RPi. Simply because you may get stuck with a supply shortage. You can pretty much always order 1k of popular chips, even if it's a shipment from Asia. You may not be able to do the same for a popular RPi model. Also some RPis will get phased out / discontinued at some point and for a medical device you may need to recertify the new model before release.

Class A basically means follow common sense, so as long as document your architecture/design, use source control and test critical parts of the code you should be right to use whichever Android development framework you want.

Currently, we're running Linux with Qt 4 on PowerPC.

We're moving to a newer CPU (i.MX6 quad core). Freescale announced that they would continue manufacturing and supporting it for 15 years and it comes in industrial grade and consumer grade packaging depending on your needs.

We're moving away from Qt for the GUI. HTML5 is the way of the future. ;)

For people who are starting out, I'd recommend using Yocto. It's a build/development environment for embedded Linux. Look it up.

Edit: By they way, if it's not real-time critical, there's nothing stopping you from using any programming language you like except how difficult they can be to cross-compile.

For hard real-time stuff you need a dedicated rt system and you'll have to use C, C++ or maybe Rust.

For soft real-time stuff you can get away with RT-patched Linux. Any language with GC is generally bad with the exception of Erlang, Go and Nim; where the GC is optimised for low latency rather than bulk through-put.

* It's easier to find people with JS skills than C++ skills

* It takes ages to build Qt and it's unreasonably hard to compile. Building the Linux kernel is far less painful.

* It takes ages to build a single Qt project and we have multiple architectures to deploy to (ppc, arm, x86).

* Remote connections are trivial. People only need a browser to connect remotely.

The people at the company who have been using it like it a lot. They just have to put together a few tags and boom there's your GUI.

The GUI has access to some system variables via WebSocket. We have a two-way binding abstraction so people don't have to think too much about events and such.

I wouldn't recommend HTML for a small company though. Better stick to Qt if you're a small group of competent C++ programmers.

I've been doing straight opengl-es on my devices and like not being locked into a gui platform. It makes even more sense to do it this way when you've got external buttons as inputs, because you're not even able to use slots and signals, which is the most useful part of qt.

Call up TI and Freescale, let them know what you're up to, and they'll come demo/loan a few products. Talk to their engineers about your product at a high level so they can immediately drill in on a few options, then talk about hard requirements and even personal preferences/interests and they'll be happy to make recommendations on hardware, OS, language. The naming schemes and jargon can get confusing and features seem to overlap, so make sure to ask lots of questions.

Oftentimes the CPU will determine your OS; some will be more stable and have more complete drivers on Windows, some on Linux, some on specialty OSes. Of course you could take the Linux Kernel and tune it yourself, but unless you really know what you're doing that's not going to be the easiest route. Oftentimes you'll come across sites/videos showing how to get unsupported OS A to work on CPU B and get excited. Ignore those, as what the video doesn't show is all the things that still don't work, and that rabbit hole goes deep.

In general for your first project try to avoid straying too far from the beaten path and the recommendations you get from your vendor.

Coding-wise you probably won't learn a whole lot. You'll be using old technology and likely limited from using any fancy techniques you want to cook up. Accept that in advance. Thrive in that actually; force yourself to take the safe road software-wise so you can take the time to read through FDA docs and understand all the lingo better. Also spend time with your EE and learn more about that side of the coin. Spend time with the customer-facing side and learn the market. Learn some actual medicine so you're seeing the device as a tool rather than as a platform. All this stuff is way more valuable in the medical field than knowing the latest five JS frameworks (or Haskell plugins, or ruby test platforms, or whatever software-y stuff floats your boat).

These are not so common anymore. Most devices use existing OS platforms depending on the task. - time/resource critical? real time OSes - GUI/multimedia/telephony? Android - a platform for you app? Linux

Dev tools are very dependent on the hardware platform. C is common, as is C++. This is also very vendor specific. Intellectual Property add-on's for different micro's, etc.

You really should consult an expert to get guidance - you can probably do the work yourself, but making the right initial hardware choices matching the requirements will help get everything else right afterwards. Once you have hardware chosen, the rest will fall into place.

I work at a research and design firm, our projects are making custom hardware for people who don't have the expertise or time. Our most frequent customers? "We got this started and now ..." Save yourself the headache of getting half way into the project and discovering a problem you can't solve, then need to hire a consultant to fix it, which will entail redoing and eliminating features because the initial decisions won't support the desired outcome. Make a consultation, and get set on the right path from the start.

Depending on your safety and realtime requirements you might be very restricted on component choice as well as coding style. E.g. for a deterministic system no heap allocations might be allowed. I guess that should be the case for most medial devices.

However your project sounds more like an embedded device in the sense of "user can't modify it", but it is still running some PC/Smartphone like applications. For that kind of stuff Android and Linux are often seen (in order from most-consumer like to most realtime capable). You get the benefit of being able to reuse standard drivers, frameworks and applications but being able to guarantee that it will always work is basically impossible.

Many devices therefore also use a multi-cpu architecture, where the criticial stuff is running on a microcontroller with RTOS and the fancy UI is running on a speedier SOC with a normal OS.

QNX and GreenHills Integrity are somewhere in the middle, by providing a realtime OS which still incorporates some consumer features and are often chosen if a realtime device should directly draw UI.

You should checkout the detailed requirements for your projects and what would be possible and accepted. I guess medical has some quite strong regulations for certifications. And I'm sure using normal consumer chips (no extended temperature range, no certificated manufacturing process, ...) will always be not possible.

Yes, that's what I suspected but I feel there _should_ be some advices/best practices.

A great deal of embedded software is still done in C/C++. (Embedded is not a good environment for dynamic languages.)

Being able to accurately profile how much memory will ever be in use is very valuable. Being able to prevent unexpected usage or stop-the-world collection issues means your device is that much safer.

Also, static languages are usually faster and more predictable, to a certain degree. This is advantageous in an industry that would rather spend years developing something than have a small chance of killing someone. Bugs are unacceptable.

If you're willing to pack an Intel Atom or something into your device, fine. But if you can get by with a tiny ARM chip, why shouldn't you?

Features, complexity, cost/availability of humans that can comprehend it, availability of existing software components, simplicity of software development process, etc.

And I kind of touched on the simplicity of software development. Yes, it's possible to quickly shove in a really tiny x86 computer and be done with it, but it ends up being cost prohibitive and energy hungry. Embedded environments are a place where you can get by with a tiny ARM chip; they're power efficient and cost effective. If you're in the embedded field, dev isn't as simple as a REPL, you have to put it directly on your device or otherwise emulate your device in some way. This forces you to come up with robust solutions.

Dev in this environment is already hard. It has to be robust anyway. Maybe we should pick the right tool for the job while we're at it.

And I am happy using a robust solution that I know won't fail me. If you're in a situation where failing to write bug-free code can kill, you would be too. Medical devices are one such field.

(But to each his own, of course! You can do awesome things with any tool.)

Hard limits to processing power, memory, energy availability, etc. do exist in some applications, but the OP doesn't seem to have these issues.

But when I think of embedded devices, I'm looking across my desk at a Cisco router with an eight year old firmware, and an HP LaserJet I recall updating at least 12 years ago. I shudder at the idea of writing Ruby and having it run in production for 12 years.

This doesn't criticise "dynamic" languages directly - but I can only possibly think of C, and similar languages, which wouldn't suffer this issue. Hopefully Rust can improve this situation.

That said, I'm on the fence about Erlang in this situation.

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.

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

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.. :)

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

My company uses VxWorks, MQX, Android, Windows CE and Linux. We're dropping VxWorks because it's costly and cumbersome. MQX is being replaced by whatever Freescale/NXP is pushing now, we put a lot of resources into the older version of MQX and aren't following them into their new incarnation. We use Android for special devices, but it seems to take a good amount of work to put it on custom hardware.

The OS that makes the most sense for embedded work nine times out of ten is Linux. It's widely used, documented enough, and has the most vendor support.

A good setup? You can get an AM335x EVM with an LCD, which is the same processor as a Rasberry Pi. I believe i.MX6 has an EVM with an LCD as well. Bottom line, you should talk to vendors, to see what they have to offer. Since it sounds like you have limited experience in this area, working with a vendor that will give you support is probably the most important thing.

Your developer tools are entirely dependent on your OS and chip. Ultimately, doing embedded work you're most likely going to use C/C++, but if you're on Linux or any modern operating system, then you have the ability to use a scripting language.

PCAP touchscreen worked well with double-gloved fingers and there are touch controllers that will reject a stray water droplet on the screen.

I'm not sure about the OS considerations for medical device use, but for linux you might consider the yocto project, which is designed for this kind of stripped down deployment. It will limit the number of moving parts you have to validate. If you're less devoted to the open source route, check out QT's boot-to-qt offering. QT ui's are common in this field and I believe there are supported boards at a range of price points.

You wouldn't want to hitch your design to Rasperry Pi or Beaglebone or such because of the short support lifetime of individual models and components. Part of what you pay for with the industrial vendors is a commitment to supply the system for 5-10 years.

If any of this is helpful, drop a note using the email in my profile.

Other stuff is separate.

That architecture worked for us - it may well not work for other needs, depending on communication latencies, costs, and so on.

http://www.lambdanative.org/

Do you need to integrate a lot of sensors or have a lot of IO?

So much depends on the stage of the development process you're in, what the goal is of this project (i.e., internal testing, research use only, human use), when you're going under design control, and what market/regulatory framework you're working under (FDA, CE, CFDA, etc.).

Your requirements documents are a good guide here. I personally separate them as Engineering Requirements Document (ERD), Software Requirements Document (SRD), and Market Requirements Document (MRD); your questions would touch all of these.

You've hinted that you are wanting a display and also wanting to do calculations; as others have suggested, good practice would be to separate this functionality. Your ERD/MRD should specify a minimum duration for projected parts availability. Dealing with part variations is a pain, but having to replace an end-of-life'd (EOL'd) part is worse. For your own personal sanity, you probably shouldn't be looking at consumer-level parts and instead look for more industrial-style parts (a weak example might be to use a BeagleCore instead of an RPi for an internal project). You'll need to be mindful of your environmental requirements too, if for example your design called for a sealed enclosure that could greatly impact the parts you could include in your design due to thermal management. Even when using consumer level stuff, say USB, you should look for the industrial/ruggedized versions (e.g., that will have retaining screws).

Touchscreens for medical devices are, in my experience, a mixed bag depending on the application. If you're using a good design, they can be easier to keep clean and disinfected vs. buttons. On the other hand, depending on the touch technology you use and the type of information you're displaying, the display may not look great (i.e., a 2D plot can look fine on a resistive touch panel, but video may look foggy). Depending on what your users are doing, you could have smudges of some sort of fluid (or boogers, or giblets) obscuring info on the display. Also, I think users expect a modern multitouch experience now and I personally haven't been thrilled with that style of interface on anything other than capacitive displays.

If you're using a contract manufacturer (CM), they are a great resource. You'll be dealing with them during design for manufacture (DFM), but it's a good idea to engage them early so that you can design for DFM (if that makes sense). I don't know what your expected volumes will be, but on things other than durable goods (like scalpels), "high volume" medical quantities are considered "low volume" for other areas and this will greatly influence your design. I also found it frustrating because you're limited to suppliers/distributors/CMs/whatever that will be satisfied with the lower volumes.

Handwavy answers are that your safety-critical stuff is going to be hard real-time and running an OS developed under an appropriate quality system (QMS) like vxWorks, Integrity, QNX, etc. I don't have experience with it, but there is also FreeRTOS with an SIL (safety integrity level) 3 SafeRTOS option that could be an interesting contender. The software you develop will also need to be developed under a QMS as a broader part of your software development lifecycle (SLDC) and greater product lifecycle management (PLM). There are guidelines to use software of unknown pedigree (SOUP) by bringing it under your QMS, but this can be undesirable depending on circumstances. Most commonly the software is developed under C or C++ with an appropriate coding, review, and testing standard; for a greenfield project I think that considering Ada/SPARK or Java (with the appropriate compiler/VM) could be smart.

For things outside of the safety-critical areas, you have greater options, and it might be largely sufficient to develop under a QMS. You're going to need to be very mindful of software licenses to make sure that they are aligned with your project's requirements. If you're set on Linux then Yocto would be worth exploring, but NetBSD would be my first consideration due to licensing. For your GUI, FLTK could be worth considering if it met your requirements. Even if your product is Class A, it's maybe helpful to keep the more stringent requirements for Class B/C products in mind, so that you can (when and if it makes sense) develop expertise and institutional knowledge for Class B/C products later on.

I'd recommend the Stanford Biodesign textbook as a one resource to help get up to speed: http://www.amazon.com/Biodesign-Process-Innovating-Medical-T...

Finally, considering your questions and I say this in the kindest intentions, you should be participating in the process but not be signing the decisions. If your company doesn't have the expertise in house, it would be worthwhile to either bring someone on board or engage a consultant.

Good luck!

I don't personally know of anyone in medical using it, but your comment about no OS does prod me to say that I have wondered if running Forth on bare metal for medical is viable and/or desirable on a greenfield project. I'm not saying I would do it, but I would happily cheer on someone else. (OP, don't do this, I'm delusional)

And OP, I really hope that my wall of text won't be discouraging in any way. Personally, I found that documentation is (a la Homer Simpson) the cause of, and solution to, all of life's problems in a regulated environment. If you master that, document honestly and eagerly, it's downhill from there and life will be good.

Rather than just a critique, I'm curious where and how you use it with what benefits it brings you? I could certainly see it in UI or untrusted parts. Maybe also during development in a way that auto-generates C or something that runs in production.

To be perfectly fair, on the decision matrix Tcl gets a helpful boost due to my own familiarity with it and playing nice with C; if a butterfly had flapped it's wings just a little bit differently or I was starting out today I would probably be using something else. Probably Java. Ada would be great, but the lack of ecosystem diversity makes me apprehensive.

So, there you have it: REBOL, RED, and Nim. Maybe Ivory language from Galois, too, but you need to know Haskell for that.

Don't have any experience with Nim, but I share your interest for the same reasons. Haskell and I don't get along, maybe I'm too old and set in my ways?

Did you catch the link to/discussion of Little shared on here a few days ago? It might be of interest. https://news.ycombinator.com/item?id=11530097

I'd say it's not a good language to go with today for same reasons I'd say Tcl isn't. It's an interesting improvement especially to get better syntax with legacy compatibility with field-proven, TCL modules. And TK is still the shit for portable, easy-to-build GUI's. A TCL shop should definitely experiment with it and maybe incrementally upgrade their code. I think I'd be fine with a more typed, efficient, and fixed version of Tcl for some apps. Especially a command shell replacement or prototyping system.

Just not production unless it's non-critical like what you use it for. I don't even use it to glue to critical things as the glue is part of the TCB to a degree. Gotta find close-to-metal, abstract, typed, efficient, and macro'd stuff to replace it. At least we have contenders.