Java prevalence in industrial environments?

[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!