Java > Scala

[Paulo Pinto]

Well doing lots of transactions per second while aggregating data
from network elements scattered across mobile network stations
seems quite a lot of work to me.

I worked in several projects from quite a few big mobile companies and I 
can say that most code that runs on the network side doing analysis of 
your mobile activities is either JVM or .Net based.

Since 2004 the middleware used by mobile operators has been being 
migrated from C and C++ codebases mostly to Java and C#. Usually only 
devices with hardware restrictions are left untouched.

Most of the operators software is now Web, Eclipse/Netbeans or Windows 
Forms/WPF based.

Polyglot programming is preferred to one single language (hammer), and 
as such, most project managers don't see as a downside that you need to 
mix languages.

--
Paulo

Am 30.11.2011 16:38, schrieb Regan Heath:
> On Wed, 30 Nov 2011 14:46:10 -0000, Paulo Pinto <pjmlp at progtools.org>
> wrote:
>> I am with Russel here.
>>
>> I work mostly in JVM and .Net environments and although currently I am
>> the opinion that there are too many VM based applications, we hardly
>> have any performance issues.
>
> Then you're not doing enough :p
>
> Seriously tho, I think it's a fairly accurate (as generalisations go)
> statement that you /can/ get more performance out of natively compiled
> code. If you don't need that extra performance, ever, then you're not
> losing anything by using a virtual machine style language.
>
>> When they do happen we are able to track them mostly to bad coding
>> practices.
>
> Yeah, this is the more/most common cause of performance issues (in any
> language). Perhaps a useful measure of a language is how easy/hard it is
> to write bad performing code.
>
>> JNI or P/Invoke are seldom used for performance reasons and mostly to
>> integrate with some specific OS feature.
>
> This is one of the downsides to using JAVA or other sandboxed/JVM style
> languages, when you actually need bare metal access (and in some domains
> that is very rarely) you have to take a hit in performance and/or
> functionality. It's another cost you pay, but one which may not be
> relevant depending on the domain you're in.
>
> The ivory tower of performance with safety with quick development time
> with easy to understand code and tools is simply not possible, there are
> to many decisions in language development which boil down to a trade off
> between one or more of these ideals.
>
> Regan