Java prevalence in industrial environments?

[Pack34]

I've been going back and forth with a new software engineering hire. He's wanting to move everything to Java claiming it's what everyone uses and is the most used in industrial environments. I've yet to meet a customer who wants it. It's 100% been C and C#.

I would find it really surprising for a piece of software for an industrial automation project to be written in Java. Is this really the case?

[hendorog]

I used to write all our automation stuff in Java after migrating from Delphi. Customers didn't ask for it, but that was because they didn't have to maintain it

The reason was we could run java on embedded linux boxes and it was so much easier to remotely maintain than a windows box.

Despite that, and that I'm out of date now, I expect you are probably right and the majority would be C/C# on windows.

Back in the day the only technical reason against java/linux was that OPC was windows only. That is probably not the case anymore.
IIRC I used a linux/unix native libraries instead of OPC to talk to the PLC's.

[John Coloccia]

I really hate Java as a language, and my experience is that "everyone" is hardly a fair representation of it's prevalence in industrial settings. That said, I'd have to weight the pros and cons of a specific application, environment, requirements, etc, and if it's the right fit, it's the right fit.

Personally, I'm not one to do something because everyone is doing it, and I'm also not one to avoid something because no one is doing it. Just match the technology to the application, and all is well.

[tggzzz]

Before Java became available, quite a few Tek and HP instruments used Smalltalk internally. While I can't comment on the Tek ones, I know Smalltalk helped to get flexible products to the market speedily.

If you plan on using C/C++, be very sure you know which C/C++, since the standards vary widely over the years. In addition, make sure your programmers can understand all the gotchas in the FQA, http://yosefk.com/c++fqa/

There are two other vitally important considerations other than the language: the available libraries and available programmers with sufficient in-depth skill.

[bd139]

tgzzz hits the nail on the head with the libraries and the skillset available.

On the subject of Java, I worked on a relatively large Java industrial automation product (ERP/manufacturing integration) in about 2002 and am currently maintaining the arse end of a dying one while we move it to something else. Regardless of skillset, it's not actually the worst platform simply because it's got lots of mature libraries and tools, particularly free debugging and profiling tools! Stuff tends to work and work well even if it is slightly horrible getting it there sometimes. It is certainly less volatile than C# which is going through MS's marketing crack pipe and fragmentation at the moment and safer than C/C++ and it is usually perfectly easy to write portable code with it.

If I was going to start again with a product now though, I'm not sure what I'd choose. Based on long working life, if I anticipated a complete rewrite interval of more than 20 years, I'd probably go with Java. Anything below that, I have literally no idea any more.

[Jeroen3]

Where java?
- Real time processing. (don't)
- Server side data crunching. (yes)
- HMI panels. (yes)
- Client app for remote access. (don't even think about it)

[Pack34]

Where java?
- Real time processing. (don't)
- Server side data crunching. (yes)
- HMI panels. (yes)
- Client app for remote access. (don't even think about it)

Client-side applications

[tggzzz]

Where java?
- Real time processing. (don't)

Maybe you can't, but many people and companies "do", very successfully. I've done it personally. Application domains: telecoms components and systems, financial systems.

I wouldn't use it for hard realtime embedded systems, but Java is perfectly satisfactory for some soft realtime embedded systems.

As I noted, both HP and Tek also used Smalltalk embedded in their instruments.

[NivagSwerdna]

I've been going back and forth with a new software engineering hire. He's wanting to move everything to Java claiming it's what everyone uses and is the most used in industrial environments. I've yet to meet a customer who wants it. It's 100% been C and C#.

You shouldn't hire them.  Any hire should be flexible enough to use a tool appropriate for the task and it isn't always Java.

[nctnico]

I've been going back and forth with a new software engineering hire. He's wanting to move everything to Java claiming it's what everyone uses and is the most used in industrial environments. I've yet to meet a customer who wants it. It's 100% been C and C#.

I would find it really surprising for a piece of software for an industrial automation project to be written in Java. Is this really the case?

I'd look at your customers and see what fits their needs. C/C++/C# seem much easier to me to deploy because you can create a single installer blob which doesn't depend on a third party runtime (the Java runtime can be upgraded and cause all kinds of breakage). I would be very carefull with changing directions because a lot of programmers are completely clueless when it comes to deploying software. Many assume customers have the latest version of the OS, that there are no conflicting libraries and every customer has a genius IT guy around. Another question you might want to ask yourself is whether you ever need Linux or Mac support for your software. In that case C# is absolutely the worse choice and C++ (combined with a cross-platform framework like Qt or WxWidgets) might be the best one.

Besides that there are many similar languages like Java such as Python.

[bd139]

You can do that with a JRE as well. You just bundle it with your application. JRE + SWT + install4j will cover all three major platforms. I've seen this automated. Someone makes a code change, integration and build done and out pops an rpm, a dmg and an msi package.

As for client facing applications though, I'd probably ship Electron now: https://electron.atom.io

Whatever you do stay away from Windows Installer. That shit eating demon and me do regular battles.

The thing with Java is (a) it's actually pretty good in most locations (b) if you can use it in most locations it makes people's skills fungible which is good (c) it's perfectly fine for *everything* other than hard real time systems as tgzzz says but even then some of the embedded JVM and cross compiled Java products are actually pretty good believe it or not (d) there are a lot of mature frameworks out there that make it very easy and reduce the time to market.

As for real time, redundancy, latency control etc, look at akka.io.

Getting a product written in C off the ground is monumentally difficult now. I wouldn't start another product in it now.

Getting a product written in C# off the ground is a monumentally stupid decision at the moment as the platform is going through a transition phase between "corporate Microsoft" and "happy shiny open source Microsoft" but the ship has sailed and the house of cards is falling on the last half.

[jnz]

I honestly can't say what's hot in industrial right now (except for CAN)... But...

I can promise you if anyone came to me suggesting we move to JAVA for anything but maintaining an existing system I'd probably fire them. If you can't see the writing on the wall by now, IDK what to tell you.

[Jeroen3]

If you can't see the writing on the wall by now, IDK what to tell you.

You're no Oracle that's for sure.

[Marco]

Besides that there are many similar languages like Java such as Python.

I fail to see much similarity.

I see more similarity with Electron, complete environment including a default cross platform GUI, often inefficient, large pool of developers. Hell you can (and should) even use static typing with it now because of the Typescript API definitions.

[hendorog]

... it's got lots of mature libraries and tools, particularly free debugging and profiling tools! Stuff tends to work and work well even if it is slightly horrible getting it there sometimes.

This ^

There is just so much mature and well written stuff around now for java that you can nearly always find a good library to do what you need. The hard part is actually picking the libraries and frameworks as there are so many. If you don't like the language there is always Scala. I'm learning that and while it is hard, it removes the ugly from Java quite nicely.

[f5r5e5d]

https://www.springer.com/us/book/9781441981578 doesn't sound like its really mature yet - perhaps some applications would be OK

[hendorog]

https://www.springer.com/us/book/9781441981578 doesn't sound like its really mature yet - perhaps some applications would be OK

I'd be interested to know if anyone is using Java for hard real-time stuff?

[bd139]

https://www.aicas.com/cms/en/JamaicaVM

[Jeroen3]

I think the fact that java is still "big" is because google chose (and modified) it for Android.

I know a few PLC's that have their HMI written in java. With the idea being that you can buy their fancy expensive touch panel, or your PC/phone.
Fast forward to today, running the jre in a browser on regular workstations is almost completely impossible today. Turned out that the jre was not very secure despite being advertised that way.
Running a normal java application on your pc is slow as hell. Even the well made ones.

I'd say go with something else. What? I don't know, that depends on your target audience and how much maintenance you're willing to spend later on.
Don't overspend on aesthetics if it's for industrial though. You're selling functionality and productivity, not fancy and shiny.

[JPortici]

Getting a product written in C# off the ground is a monumentally stupid decision at the moment as the platform is going through a transition phase between "corporate Microsoft" and "happy shiny open source Microsoft" but the ship has sailed and the house of cards is falling on the last half.

i don't know anything about the subject. Well, all i know is that the guys doing apps for us use Xamarin and C# to make multiplatform apps, apparently it's good enought for that.
Anyway, i aways read of people saying that using this or that language is a bad idea, but rarely suggest an alternative. what would you all use then?

[hendorog]

I think the fact that java is still "big" is because google chose (and modified) it for Android.

Fast forward to today, running the jre in a browser on regular workstations is almost completely impossible today. Turned out that the jre was not very secure despite being advertised that way.

The running java in a web browser thing has been a bad (dumb) idea for at least 10 years, probably more. Why people continued to write software that way is beyond me. That is not how java _should_ have been used in the real world and never has been.

Unfortunately non-tech's get confused and think that because java in the browser is bad, then java is bad, oh and javascript is also bad cos of the name...

Java webstart suffered too. It was quite useful back in the day for delivering applications which run locally but can update themselves on demand.

Java is huge in corporates. It's the new COBOL. I doubt Android has that much impact on it's popularity to be honest.

[bd139]

Running it in the browser was a bad idea to start with. There was a lot of hoo har about this when applets first dropped.

Getting a product written in C# off the ground is a monumentally stupid decision at the moment as the platform is going through a transition phase between "corporate Microsoft" and "happy shiny open source Microsoft" but the ship has sailed and the house of cards is falling on the last half.

i don't know anything about the subject. Well, all i know is that the guys doing apps for us use Xamarin and C# to make multiplatform apps, apparently it's good enought for that.
Anyway, i aways read of people saying that using this or that language is a bad idea, but rarely suggest an alternative. what would you all use then?

Give it a few years when MSFT dump it, like they did with: WS-*, WWF, WCF, ClickOnce, AppFabric, Velocity, EF3, Silverlight, Lightswitch etc. The lifecycle is:

1. Market the fuck out of something they are going to do on blogs.
2. Buy in a 3rd party product or chop out a broken CTP
3. Market the fuck out of that saying it'll be fixed soon.
4. Do some turd polish, say it's RTM and dump it on the market.
5. Everyone integrates it.
6. About 6 months in everyone realises it's a pile of crap or MSFT's direction changes like the schizophrenic nightmare that it is.
7. Dumped instantly.
8. EOL'ed and not supported, still quality issues.

Xamarin is exactly the sort of product they will shit on in the future because it's part of their completely failing mobile first cloud first strategy. They screwed a whole mobile platform into the ground with the above (windows phone), they have a cloud platform which is plainly unreliable (azure) and amazon is eating them for lunch, they're trying to gain market share on O365 but large companies are exiting all the time and migrating to GA. They are even facing competition on the second hand market because people would rather buy a second hand device offered by Apple now than a new MSFT device in the consumer sector. Then there's the subscription and enterprise shafting that is turning everyone to Linux on the server and MacOS on the desktop.

Their last ditch is to try and bring up their dev tools cross platform but they're not delivering quality, just version increments. They're like a drunken cat trying not to fall down the toilet.

Would you build a business on the above? Nope.

Electron / Qt / WxWindows / Java+SWT / native apps per platform is the way to go. Something that insulates you from any specific platform volatility.

[wraper]

The running java in a web browser thing has been a bad (dumb) idea for at least 10 years, probably more. Why people continued to write software that way is beyond me. That is not how java _should_ have been used in the real world and never has been.

Yep, I run away from it like a plague. The only virus I got in my PC in last 15 years was because of java with it's endless security vulnerabilities, and it was the latest version of java at that time. I hate that keysight chosen this piece of malware for web interface of their new multimeters  .
http://www.zdnet.com/article/oracle-drops-massive-patch-update-which-fixes-299-vulnerabilities/ 

[mib]

I think the fact that java is still "big" is because google chose (and modified) it for Android.

Google took the complete clusterfuck that was java for mobile and made something usable out of it. Sun totally failed to properly capitalise on java. Oracle have just continued that trend and then some. Java is still relevant, but only for some applications. There's a massive amount of server side stuff that will be java for the foreseeable future. There's also a surprising amount of real time and safety critical code out there - I've even written some of it. Java no longer really has much of a place on desktops though. And anyone still using java applets should be hung, drawn, quartered, revived, shot, revived again and forced to spend the rest of their lives teaching at a coding bootcamp. Applets just never got the security right and won't be given the opportunity to get it right.

To the OP. A new employee coming along saying you need to throw away everything and start again in a new language? Yes, you do need to start again, at the beginning of the recruitment process. NIH is a never ending problem and the only solution is experience. If you have something that works, then don't break it. If you can't find people to maintain your existing code base, you're not offering appropriate salaries.

If, however, you are looking to start again, then python on the device with web/javascript based cloudy bs frontends seems to be the popular choice right now.

I've done a lot of system level software support for industrial control devices over the last few years and that's what they all ask for. Usually they start off asking for 'something like a raspberry pi' but eventually settle on one of the more easily customisable ARM systems. Usually a fairly capable system so they can run a full linux with python, SQL, web server, etc, etc. There is a common trend away from MS technology on devices, but sticking with things that 'developers' can do on their windows PCs with no linux knowledge. Python combined with the various web technologies seems to fit that bill quite well.

[hendorog]

The running java in a web browser thing has been a bad (dumb) idea for at least 10 years, probably more. Why people continued to write software that way is beyond me. That is not how java _should_ have been used in the real world and never has been.

Yep, I run away from it like a plague. The only virus I got in my PC in last 15 years was because of java with it's endless security vulnerabilities. I hate that keysight chosen this piece of malware for web interface of their new multimeters  .

Wow are Keysight really doing that? Crazy...

[bson]

I'd look at your customers and see what fits their needs. C/C++/C# seem much easier to me to deploy because you can create a single installer blob which doesn't depend on a third party runtime (the Java runtime can be upgraded and cause all kinds of breakage).

I recently built some highly scalable server side components in go (see golang.org) for this reason; it compiles to a single static binary that needs exactly one thing to deploy and run: libc.  This makes it perfect for all kinds of self-deploying, auto scaling systems, makes it easy to sandbox develop and test, and can trivially be baked into e.g. an AMI for EC2 and then auto scaled by using an elastic load balancer.  Of course, it has no client-side provisions and is intended only for backend services.  Performance is good as well; while nothing can match well-tuned C++ software (using e.g. Intel vtune and then careful tweaking of memory layout and cache coloring), it's perfectly acceptable for "naive" software.  For backend work I'd say Java is out.  For client side... I'd have to ask who on earth still builds Java applications?  They look and work like crap - it promotes some terrible, laughable practices (like hitting a backend synchronously in a foreground thread).  The exception would be Android, but it has a completely different runtime that's up to snuff.  For client side I think pretty much any sane person by now has accepted that apps need to be native, which means C# on Windows, Swift on Apple, Java on Android, etc.  This is generally simpler than trying to generalize something that runs everywhere but provides a really ghetto UX - penny wise, pound foolish to the extreme.

[Kjelt]

For backend work I'd say Java is out.

Although not my expertise this is what I hear from our AWS developers as well. On the cloud servers you don't want code that needs to be interpreted by another run time library, that cost space and time both which are cloud expenses. They now talk about lambda functions written in for instance Python, much faster and much cheaper, but definitely not my expertise so I shut up 

[hendorog]

For backend work I'd say Java is out.

Although not my expertise this is what I hear from our AWS developers as well. On the cloud servers you don't want code that needs to be interpreted by another run time library, that cost space and time both which are cloud expenses. They now talk about lambda functions written in for instance Python, much faster and much cheaper, but definitely not my expertise so I shut up 

I'd expect Java to blow away Python for performance.
Python isn't particularly fast, although most people assume it is fast. Java OTOH is very fast - although most people assume it is slow.
However I'd expect that Java will consume more RAM than Python.

I don't know much about AWS Lambda either, it seems to be priced in GB.seconds, so I wonder how those two effects balance out at the end of the day.

Edit: Looks like the GB is based on the memory size you chose for the function. I'd guess Java would need more memory to be assigned, but would be faster.

[JPortici]

Electron / Qt / WxWindows / Java+SWT / native apps per platform is the way to go. Something that insulates you from any specific platform volatility.

Thanks. I prefer to focus on the hardware/firmware side of things but then we/the customers have to interact with it somehow
Believe it or not for our needs VB6 is still okay, does its job, a bit annoying on the graphics side when somebody has to use the monitor with a scaling which doesn't result in an integer twips/pixel ratio but most important it works on every windows machine from XP to 10. Customers don't complain, no reason to change.

[NivagSwerdna]

For backend work I'd say Java is out.

Although not my expertise this is what I hear from our AWS developers as well. On the cloud servers you don't want code that needs to be interpreted by another run time library, that cost space and time both which are cloud expenses. They now talk about lambda functions written in for instance Python, much faster and much cheaper, but definitely not my expertise so I shut up 

I can't agree with this statement.  Java makes a good backend for enterprise/cloud applications.  Java post-8 has some functional elements so lambda functions are first class citizens now.  Java is also heavily optimised so the byte code is JITed and the performance can be close to C.  Also Java has very strong development tools (e.g IntelliJ IDEA) and huge third party support, the eco-system is absolutely enormous.  However there are niche alternatives... Scala, Go, etc...

Javascript is on the up for front to back development and is a language of choice for the web generation.  Node.js, meteor etc... and electron mentioned above looks pretty interesting for some use cases.

However, as you get closer to the bare metal you may need to drop down closer to the code and that's where C & C++ still have a niche. e.g. for GPU (CUDA) I use C.

Personally I used to program in C and Assembler, later C++... now my day job is mostly Java with some JavaScript on big platforms and my night job is C on small platforms.

So it really depends on which problem you are trying to solve.

[bd139]

Indeed. Java is one of those things that if you know what you're doing on the back end, you don't actually end up writing much code. Check out the following for example: http://www.dropwizard.io/

Also Java is incredibly fast. I mean really fast. You have no idea how far we can push it (and C#). One of the real problems with it is that it's so fast that you can code yourself into an architectural hole pretty easily and realise you can only scale up and not out because it's been eating your problem domain for lunch.

And fuck RAM, it's cheap - just buy some more! We don't have a single node that doesn't have less than 64GiB of RAM these days. Even the developer workstations have 32GiB.

Python is quick to write but very slow to execute. It really is a turd in production as well. I've managed it and we scrapped it in the end. Go is eating it's lunch on the server-side at the moment as it's half way between python and C.

The only thing that is faster than Java is carefully written C and that's rarely worth it unless you are platform constrained. You lose safety, an excellent toolchain etc which is a cost sink on any team that doesn't NEED to do it.

Incidentally I'm no fan of JavaScript (even in the latest incarnations) but it's pretty damn fast as well.

On the subject of AWS and Lambda, it's a rather risky platform to get into. It's the ultimate vendor lock in. I couldn't entertain that, even though we use oodles of EC2/EBS resources. Remember you're buying your compute from McDonalds if you're going there. Rather I'd have a few cabinets stacked of HPE hardware to fall back on, which incidentally I do

[tggzzz]

Python is quick to write but very slow to execute. It really is a turd in production as well. I've managed it and we scrapped it in the end. Go is eating it's lunch on the server-side at the moment as it's half way between python and C.

Interesting. Are people making significant use of Go's CSP features? The embedded equivalent would be xC, from David May the author of Occam.

[bd139]

It's not quite CSP as per Hoare's paper on the matter, but yes it is being used heavily. We're using it for a few things from  constraint solvers to stuff as dumb as evaluating rules to shift http content. A lot of our constraints involve talking to other 3rd parties so most of the IO is blocking so at allows lowest latency simply through running everything in thousands of goroutines with channel based synchronisation. Also makes failures easy to rationalise.

It's fun as well which is a missing thing these days in most platforms!

Really Erlang is probably a better choice on paper but the learning curve and library support is pretty bad.

Incidentally and not a lot of people know this, most of the NHS's spine2 backbone which is one of the largest and most well hidden bits of "enterprise" kit out there runs on Ubuntu with Erlang and Riak and a big chunk of gov.uk runs on Go as well.

[tggzzz]

It's not quite CSP as per Hoare's paper on the matter, but yes it is being used heavily. We're using it for a few things from  constraint solvers to stuff as dumb as evaluating rules to shift http content. A lot of our constraints involve talking to other 3rd parties so most of the IO is blocking so at allows lowest latency simply through running everything in thousands of goroutines with channel based synchronisation. Also makes failures easy to rationalise.

Understood there are differences.

For (presumably) similar things, i.e. event processing high availability telecoms systems, I've used the half-sync-half-async design pattern:

• input threads grab asynchronous events from external equipment
  
• events directed to and stored in FIFO in front of the relevant phonecall object
  
• as a worker thread becomes available, it grabs an event from a FIFO and processes it until completion (which is often sending another asynchronous event to external equipment)

That ends up being vaguely similar to Erlang without the pattern matching capabilities.

It's fun as well which is a missing thing these days in most platforms!

Yes indeed! That's one reason I like xC on xCORE for embedded hard realtime systems.

Really Erlang is probably a better choice on paper but the learning curve and library support is pretty bad.

Incidentally and not a lot of people know this, most of the NHS's spine2 backbone which is one of the largest and most well hidden bits of "enterprise" kit out there runs on Ubuntu with Erlang and Riak and a big chunk of gov.uk runs on Go as well.

I've been beguiled by Erlang for a couple of decades, but never been able to justify using it. That info about spine2 is interesting and intriguing.

[jnz]

Java is huge in corporates. It's the new COBOL.

I think that's an excellent way to put it!

Now the question is, am I trying to keep up with corperates/mindset/integration or am I doing something newer/better? For me, I see Java and despite it's "glorious potential" I get ram heavy dumbness. Why would I choose Cobol [Java]?

So to the OP, yea, IDK, but if you aren't using it now and don't need to - I don't know why you'd switch. Again, I'd probably fire someone who came to me in my line of work and suggested Java as it would be so out of place and regressive.

[hendorog]

Java is huge in corporates. It's the new COBOL.

I think that's an excellent way to put it!

Now the question is, am I trying to keep up with corperates/mindset/integration or am I doing something newer/better? For me, I see Java and despite it's "glorious potential" I get ram heavy dumbness. Why would I choose Cobol [Java]?

So to the OP, yea, IDK, but if you aren't using it now and don't need to - I don't know why you'd switch. Again, I'd probably fire someone who came to me in my line of work and suggested Java as it would be so out of place and regressive.

There are a couple of big reasons that come to mind, from a corporate developer mindset:
* Real freedom from vendor lock-in (i.e. OS independent, DB independent, App server independent)
- In a corporate, big deals are done with vendors and if you are locked in you have no freedom to negotiate.
* Huge, just huge ecosystem of high quality, free frameworks, libraries and tools
- In a corporate, getting $$ to buy some (unanticipated) library for .NET is a 1 month delay minimum. You go to your boss cap in hand, and someone always wants to check the choice of library. It just makes you look bad and gives the power trippers their time in the sun. With java you can just find the right library and continue working and avoid the politics.

Smaller reasons:
* If you don't like the language then switch to Scala instead, or one of the other options - same JVM, same libraries, same code base.
- .NET has other language options too obviously, but I think the JVM options are less well known.
* Performance - Java code gets faster and faster the more often it runs.
* You can swap out the JVM as well - maybe for one of the realtime ones (credit to @bd139)

There is also perhaps a lesson here for you as a boss - never dismiss anything out of hand. There is usually(always?) some clever thing hiding in any stupid sounding idea, but you have to open your mind to be able to see it. Defer it if you need to, but never dismiss it without giving it some thought and the person a chance to explain.

[tggzzz]

There is also perhaps a lesson here for you as a boss - never dismiss anything out of hand. There is usually(always?) some clever thing hiding in any stupid sounding idea, but you have to open your mind to be able to see it. Defer it if you need to, but never dismiss it without giving it some thought and the person a chance to explain.

Yes. I don't fell the need to write any more.

[funkathustra]

As for client facing applications though, I'd probably ship Electron now: https://electron.atom.io

Especially for cross-platform support. It seems like we've given up on "native-looking toolkits" and decided to just make everything look like web sites.

The thing with Java is (a) it's actually pretty good in most locations (b) if you can use it in most locations it makes people's skills fungible which is good (c) it's perfectly fine for *everything* other than hard real time systems as tgzzz says but even then some of the embedded JVM and cross compiled Java products are actually pretty good believe it or not (d) there are a lot of mature frameworks out there that make it very easy and reduce the time to market.

This is all true. Anyone who complains about Java's speed or deployability hasn't been around recently, as that hasn't been an issue for a while.

My problem with Java is its lack of productivity for event-driven programming found in GUI development. It's just so far behind C# and Javascript and Python. Java 8 helps a bit, but the Java developers seem bent on keeping the language as basic as possible, so if there's a way of implementing something but subclassing some interface and implementing it as anonymous classes, that's good enough for them.

Getting a product written in C# off the ground is a monumentally stupid decision at the moment as the platform is going through a transition phase between "corporate Microsoft" and "happy shiny open source Microsoft" but the ship has sailed and the house of cards is falling on the last half.

Eh, this is where I start disagreeing with you. The .NET Core stuff is really almost 100% server-oriented, not client-oriented. And .NET Standard isn't going away anytime soon. Probably at least for 10-15 years. And even then, nothing gets truly retired at Microsoft — they just stop talking about it. For example, even though they're ancient technologies, you're more than welcome to develop WinForms or MFC apps that target the latest, greatest .NET and C++ libraries. They just don't brag about that stuff anymore.

Depending on cross-platform needs, .NET might struggle a bit. WPF (and UWP if you're targeting Windows 10) are fantastic GUI toolkits, but they have no support on macOS or Linux. Which is a pitty; XAML's data-binding system makes everything else look 10 years old (except the Javascript MVVM-ish libraries that have since copied it), and it's definitely the most productive GUI toolkit I've used — especially for data-centric designs.

I've built stuff in Xamarin.Forms (nothing huge, but more than just toys), and it deploys nicely to Windows, iOS, and Android — there's also some emerging support for macOS. But you really need to figure out what technology you need that's best for your application.

It's funny that your new dev is gung-ho about Java. I didn't think anyone was excited about Java anymore.

Let the new guy play around and see what he comes up with.

[nctnico]

For client side I think pretty much any sane person by now has accepted that apps need to be native, which means C# on Windows, Swift on Apple, Java on Android, etc.  This is generally simpler than trying to generalize something that runs everywhere but provides a really ghetto UX - penny wise, pound foolish to the extreme.

In my experience Qt and WxWidgets are pretty good at providing a way to compile native looking programs for various OSses from the same sourcecode so you don't have to write the same application in various languages. Maybe you didn't notice that because you can't see it 

[vodka]

Java is huge in corporates. It's the new COBOL.

I think that's an excellent way to put it!

Now the question is, am I trying to keep up with corperates/mindset/integration or am I doing something newer/better? For me, I see Java and despite it's "glorious potential" I get ram heavy dumbness. Why would I choose Cobol [Java]?

So to the OP, yea, IDK, but if you aren't using it now and don't need to - I don't know why you'd switch. Again, I'd probably fire someone who came to me in my line of work and suggested Java as it would be so out of place and regressive.

1. You have been compared with normal car like 600 (JAVA) versus with a Racing car(Cobol) .
2 Cobol is 100 times more easier to program and  maintining its code than JAVA. Cobol hasn't the kilometric sentence like the JAVA. Intead of "myOBj.mymethod.mysecmethod.myATT" like JAVA , on COBOL use a "PERFORM" or "Call" you pass the variables by reference or by valor and you  forget the problems.
3 On Cobol you have less of 100 functions  besides with references documents, on change JAVA his documents are authentic MESS , it have more pages than the holy bible.

The curious stuff of the new  programming languages respect to the olds, it is than you have to write more code for doing exactly the same, when by logic would have that to be less .
I think that a near future , the programmers will be fired and replaced by AI software for doing the 90% of the code , after the humans will link the parts of the software. 

[Kjelt]

I think that a near future , the programmers will be fired and replaced by AI software for doing the 90% of the code , after the humans will link the parts of the software. 

Near future? No way.
AI can repeat earlier learnings, perhaps combine those but there is no creativity, no soul.
I have heard AI compositions after the AI "listened" to 1000 hours of Mozart and it still was rubbish, never mind what it should have produced if Mozart never existed and the AI should create everything from scratch without example.

[bd139]

Even humans haven’t worked out how to write software yet. In the scale of things, comparing to any other engineering discipline, we’re still at the stage of massive Victorian style train wrecks. AI also doesn’t really exist yet. I’d be surprised if we have anything as good as a cat in the next 50 years or so (Kurzweil is full of shit) and cats lick their own butt hole. Even IBM’s research in this area turned out to be a mechanical Turk.

[tggzzz]

Even humans haven’t worked out how to write software yet. In the scale of things, comparing to any other engineering discipline, we’re still at the stage of massive Victorian style train wrecks. AI also doesn’t really exist yet. I’d be surprised if we have anything as good as a cat in the next 50 years or so (Kurzweil is full of shit) and cats lick their own butt hole. Even IBM’s research in this area turned out to be a mechanical Turk.

Arguably since we are at the stage of Victorian bridge failures, some people have worked out how to do it. But not most.

Arguably AI doesn't have to be right, all that is needed is that it is better than typical humans, and that its failures don't result in its sellers becoming involuntary guests of Her Majesty. Legislators, wake up.

[Jeroen3]

We're only programming for shortly over 60 years yet. That is not very long.

[Howardlong]

Re: AI.

AI has seen a resurgence in the last year or two, but it was all the rage in academia back in the 80s.

I suspect that the reason why the Google/Youtube adpocolypse demonetisation debacle rages (as in a recent evblab video and very many other places) is largely due to AI based algorithms. Youtube have difficulty producing any detailed objective guidelines because they don’t actually really know enough about how or understand why their algorithms are choosing specific content to demonetise. If they did, they wouldn’t be in the mess they’re in now.

Sure, we know they can adjust the throttle to increase or decrease the false positives, which is what they’ve done, but I am not sure I’d want the throttle in my car or plane to be driven by such those algorithms.

I agree regarding legislation and AI, this is going to be a rocky road. If you make something that inadvertently turns out to be dangerous, you are at risk of being deemed negligent. I’d suggest if you don’t know how your machine is making its decisions, and it is not sufficiently limited by enough safeguards, then that is negligence, and you are liable.

[tggzzz]

I agree regarding legislation and AI, this is going to be a rocky road. If you make something that inadvertently turns out to be dangerous, you are at risk of being deemed negligent. I’d suggest if you don’t know how your machine is making its decisions, and it is not sufficiently limited by enough safeguards, then that is negligence, and you are liable.

Never equate the law with either justice or common sense

A good place to keep a watching eye on these things (and many more relevant to eevblog readers) is comp.risks. Expertly moderated, low volume, high SNR, recommended.

[bd139]

Also contains squirrel related incidents!