It doesn't matter if they're using it or not. If you haven't _heard_ of C#, you are very unlikely to be a competent software engineer.

If someone only works in embedded systems that are meant to last 20+ years, should they also know about the latest Js/Bootstrap/Ember/whatever front end framework?

C# is a mostly Windows centric, managed language which frankly, will likely never enter a discussion about embedded, real-time systems. I'd expect them to know about Rust before they know about C#.

Also, how many 'competent' engineers know about the newest Fortran and Ada standards? Or have even written a single line of either?

There is so much more to software engineering than choice of language. I think it's entirely possible that defense contractors have more knowledge of the software development lifecycle than you are giving them credit for.

I believe parent's point is that one should know that C# is a choice, not that they have to use it. How can one make an informed choice if one doesn't know what the choices are? If all you have is a hammer, and all that.

One of the best programmers I ever worked with would probably not know of C# beyond that it exists, maybe that MS makes it.

But I'd hire him over nearly anyone else for embedded work. He did absolutely no programming or engineering work after hours. He played his guitar, went to music festivals, and ran a club (a couple different times in his life, don't know what he's doing these days or if he's still alive, he'd be past 70 now). C# doesn't enter into the discussion when developing embedded software, and his lack of knowledge of it indicates nothing about his character or ability.

With respect, I think you and the parent are assuming a level of autonomy among defense contractors that does not exist.

As I said in my post elsewhere, engineers rarely get to make that call.

for someone to have never even heard of C# and to be working full time in a senior level programming job, you have to be completely and utterly isolated from any kind of programming community.

just because I don't use node js, ruby, or perl in my work doesnt mean i have an excuse to not know that they even exist. how can you choose the best tool for a job if you only know C++ and Ada?

> for someone to have never even heard of C# and to be working full time in a senior level programming job, you have to be completely and utterly isolated from any kind of programming community.

The majority of defense contractors I know don't spend time in the "programming community" in their off hours, both because it's contractually too cumbersome to do so, and because they're doing other things in their spare time. They may spend time in the "defense community". It's very different culturally from SV.

> just because I don't use node js, ruby, or perl in my work doesnt mean i have an excuse to not know that they even exist. how can you choose the best tool for a job if you only know C++ and Ada?

node.js, ruby, and perl are not acceptable for use on real-time systems nor safety-critical systems.

> how can you choose the best tool for a job if you only know C++ and Ada?

Having worked in that world for almost 10 years, I can tell you that this choice is not up to you. You are told what tools you will be using, typically driven by government customer "experts" and inter-company politics.

The general aerospace defense industry trends don't include C#.

Languages that have no use in my office outside a handful of projects (not intended for end users) include everything that's not: Ada, C, C++, Fortran, Jovial (being replaced), assembler (various forms), Delphi (one project, too costly to rewrite, too lucrative to drop). C#, Java, Python, Ruby, JS, Smalltalk, Rebol, Perl, Bash, C--, Lisp, Forth, Factor, Go, Rust, SML, OCaml, Haskell, Erlang, Racket, Scheme, F#, Visual Basic, BASIC (in other forms), etc. offer no value to the majority of our projects. If they're used, perl and a couple other scripting languages in particular, it's for tools for data analysis (scanning logs, turning hex dumps into useful printouts, etc.). In which case almost any language will suffice.

But on our target hardware platforms, and given our target performance constraints, the initial listed languages are pretty much the only options. This is the industry trend.

You've done a very good job at illustrating the way I'm interpreting the parent and grandparent comment. Of the list of languages you just wrote out, I've never heard of "C--". I've written code in 22/31 of those languages. Depending on how you want to measure the duration of my career, I've got somewhere between 10 and 20 years of experience.

If leaders in an organization haven't at least heard of a language that's in the top 5 of TIOBE (http://www.tiobe.com/tiobe_index), I'd have some serious concerns when considering whether or not to work with them. These days I'm mostly hanging out in embedded land, but I at a minimum spend enough keeping in touch with what's happening in other industries, just so that I can at least understand what other people are talking about and what they're up to.