Apple Migrates Its Password Monitoring Service to Swift from Java, Gains 40% Performance Uplift (infoq.com) 74
Meta and AWS have used Rust, and Netflix uses Go,reports the programming news site InfoQ. But using another language, Apple recently "migrated its global Password Monitoring service from Java to Swift, achieving a 40% increase in throughput, and significantly reducing memory usage."
This freed up nearly 50% of their previously allocated Kubernetes capacity, according to the article, and even "improved startup time, and simplified concurrency." In a recent post, Apple engineers detailed how the rewrite helped the service scale to billions of requests per day while improving responsiveness and maintainability... "Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency."
Apple's Password Monitoring service, part of the broader Password app's ecosystem, is responsible for securely checking whether a user's saved credentials have appeared in known data breaches, without revealing any private information to Apple. It handles billions of requests daily, performing cryptographic comparisons using privacy-preserving protocols. This workload demands high computational throughput, tight latency bounds, and elastic scaling across regions... Apple's previous Java implementation struggled to meet the service's growing performance and scalability needs. Garbage collection caused unpredictable pause times under load, degrading latency consistency. Startup overhead — from JVM initialization, class loading, and just-in-time compilation, slowed the system's ability to scale in real time. Additionally, the service's memory footprint, often reaching tens of gigabytes per instance, reduced infrastructure efficiency and raised operational costs.
Originally developed as a client-side language for Apple platforms, Swift has since expanded into server-side use cases.... Swift's deterministic memory management, based on reference counting rather than garbage collection (GC), eliminated latency spikes caused by GC pauses. This consistency proved critical for a low-latency system at scale. After tuning, Apple reported sub-millisecond 99.9th percentile latencies and a dramatic drop in memory usage: Swift instances consumed hundreds of megabytes, compared to tens of gigabytes with Java.
"While this isn't a sign that Java and similar languages are in decline," concludes InfoQ's article, "there is growing evidence that at the uppermost end of performance requirements, some are finding that general-purpose runtimes no longer suffice."
This freed up nearly 50% of their previously allocated Kubernetes capacity, according to the article, and even "improved startup time, and simplified concurrency." In a recent post, Apple engineers detailed how the rewrite helped the service scale to billions of requests per day while improving responsiveness and maintainability... "Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency."
Apple's Password Monitoring service, part of the broader Password app's ecosystem, is responsible for securely checking whether a user's saved credentials have appeared in known data breaches, without revealing any private information to Apple. It handles billions of requests daily, performing cryptographic comparisons using privacy-preserving protocols. This workload demands high computational throughput, tight latency bounds, and elastic scaling across regions... Apple's previous Java implementation struggled to meet the service's growing performance and scalability needs. Garbage collection caused unpredictable pause times under load, degrading latency consistency. Startup overhead — from JVM initialization, class loading, and just-in-time compilation, slowed the system's ability to scale in real time. Additionally, the service's memory footprint, often reaching tens of gigabytes per instance, reduced infrastructure efficiency and raised operational costs.
Originally developed as a client-side language for Apple platforms, Swift has since expanded into server-side use cases.... Swift's deterministic memory management, based on reference counting rather than garbage collection (GC), eliminated latency spikes caused by GC pauses. This consistency proved critical for a low-latency system at scale. After tuning, Apple reported sub-millisecond 99.9th percentile latencies and a dramatic drop in memory usage: Swift instances consumed hundreds of megabytes, compared to tens of gigabytes with Java.
"While this isn't a sign that Java and similar languages are in decline," concludes InfoQ's article, "there is growing evidence that at the uppermost end of performance requirements, some are finding that general-purpose runtimes no longer suffice."
Uh oh (Score:2)
Now angle of sphere is going to go on a German fueled rant about how memory consumption doesn't matter because Java is awesome and totally isn't needlessly verbose.
Re: (Score:2)
Basically like this:
https://youtu.be/oy2VqDi4sFg?t... [youtu.be]
Re: (Score:2)
I was half-expecting this:
https://www.youtube.com/watch?... [youtube.com]
Re: Uh oh (Score:1)
Re: (Score:1)
Everything is illegal in Germany.
Re: (Score:3)
I wonder if Apple started the migration after the change in Oracle's licensing model in January 2023?
The Java SE Universal Subscription was introduced in January 2023 to an outcry from licensing experts and analysts. It moved licensing of Java from a per-user basis to a per-employee basis. At the time, Oracle said it was "a simple, low-cost monthly subscription that includes Java SE Licensing and Support for use on Desktops, Servers or Cloud deployments." However, licensing advisors said early calculations to help some clients showed that the revamp might increase costs by up to ten times. Later, analysis from Gartner found the per-employee subscription model to be two to five times more expensive than the legacy model. https://developers.slashdot.or... [slashdot.org]
Re: (Score:2)
That alone should be lol-worthy, but it's not even true- it's actually ~4300x faster. There is, in fact, probably nothing fucking slower than Python. I'd like to know how much global warming is accelerated by people using that pile-of-shit language.
Java. Python. What the fuck is it with that guy loving truly fucking terrible languages.
Re: (Score:2)
If you want a loop to be so much slower, you need to hand craft an example for a special case.
For instance you could use some odd matrix dimensions, perhaps a 3D matrix, with a sparce implementation, and compare "odd matrix values" in a C implementation versus a pure Python implementation (one that does not call a C/Fortran library for that) ...
Otherwise: I suggest to stay out of discussion of topics you have no clue about.
Python - as in pure Python, that is not just glue calling C - is significantly slower
Re: (Score:2)
P.S.
We talked about an multiplication loop, and not an add loop.
Most C/C++ compilers will optimize a loop like that away anyway ...
Re: (Score:2)
Most C/C++ compilers will optimize a loop like that away anyway ...
Which is why in my test, I made sure to print the result. If you don't use the result, it will in fact optimize it away. If you use the result, it cannot optimize it away.
A multiplication test is more difficult to do, since where other languages will overflow, Python will not, its performance will just continue to go down the larger the composite values get.
Prior to overflow/precision-extension, the ratio of performance difference will not be different, though.
Python will continue to be impressively bad
Re: (Score:2)
If you use the result, it cannot optimize it away.
It can. The compiler calculates the result and sends it to the print function.
Facepalm. That is standard since decades.
Python will not, its performance will just continue to go down the larger the composite values get. ... they should have written it at least for the 12 most common CPU architectures in assembly ...
Yeah, sucks that the multiplication for arbitrary big numbers is implemented in C
Re: (Score:2)
It can. The compiler calculates the result and sends it to the print function.
OK- that's fair.
It can do that.
It can also look at what the loop is doing and optimize the algorithm while still faithfully computing the answer.
But then again- so can an interpreted language. Note the Perl v. Python analysis: Python is still many times slower than Perl, also an interpreted language.
With optimizations, and using an command-line given iterator limit, preventing pre-calculation:
*@*-mbp4:~$ time ./test 1000000000
500000000500000000
real 0m0.016s
user 0m0.004s
sys 0m0.011s
Using zero optimization at all (simple naive conditional add and branch instructions emitted- verified with obj
It's not the language. It's tech debt. (Score:5, Insightful)
Whenever you rewrite a product in a new stack you pretty much create it from scratch. You do things right and don't bring all the patchwork and tech debt with you. That's what caused this speed-up. No the change of the language.
Re:It's not the language. It's tech debt. (Score:4, Interesting)
More than likely, but Java does have a lot of inherent problems that almost certainly didn't help. It's also quite plausible that garbage collection was biting them pretty hard; example: https://discord.com/blog/why-d... [discord.com]. The whole reason for switching in that case was because of GC, which is inherent to the language's runtime, and you can't do anything about it. And of course: Java IS a memory hog. Java DOES take a long time to spin up, both initially and for new threads.
They probably would have done slightly better with rust given you can simply rely on normal pointers instead of reference counting, but knowing Apple that probably came down to an NIH decision.
Give the statistics of the java vs swift code (Score:2)
- number of classes
- Number of classes which inherit from another class
- Number of external API endpoints
- Number of internal API endpoints
- Number of calls to external systems, databases, services, storage, etc.
- Number of methods
- Breakdown of methods into deciles by lines of code per method (actual lines of code, comments, white space removed)
- Number of try catch blocks in the code
- Number of throw exceptions in the code
- Number of lambda calls in the code
- Number of namespaces
- Average number of identi
object - wire format - object (Score:2)
A guess would be that they did multiple repeated object -> wire format (text, json, http body) -> object format for each call.
Re: (Score:2)
Most of those points are rather irrelevant regarding speed. For example name spaces. Or lambda calls.
However some things are interesting, especially the over all system architecture as in "end points".
Re: (Score:3)
Garbage collection is faster than reference counting, not slower. Reference counting has the benefits of being deterministic and avoiding pauses, but it has more overhead overall. If you're concerned about throughput, garbage collection wins.
I'd take this story with a grain of salt. Apple claims the language they invented and promote is better than others. What a surprise! It sounds more like propaganda than a real technical analysis.
Re: (Score:2)
ARC, as you mention, is deterministic and avoids non-deterministic pauses.
In the case where a particular run may not run any mark-and-sweep, it will perform better, depending on what really needs to be done for destruction, but only just barely- however, cross some transparent threshold, and instantly watch your throughput be far less. Modern multi-generational collectors exist precisely because of this problem.
This is easily demonstrable in benchmarks.
Of course, since we'r
Re: (Score:2)
Of course, since we're talking about Java, anyway, Swift is going to perform better, period, even if Java's GC doesn't run at all.
Actually: nope. The only performance issue would during the time when the Java Byte code is not JIT compiled yet. That can be avoided by native compiling.
And then: Java does not have the reference counting overhead ... that was the point of your parent.
Example:
// implementation dependent, can be a simple pointe
public class Something {
Something prev = null;
Re: (Score:2)
They did not say or claim "the language is better".
From an language geek point of view: Swift is better than Java. As a language. But on both cases we have an eco system. The ecosystem of Java is much richer. And the fancy things you can do with Java, for example reflection, build in serialization, byte code morphing/instrumentations: is much more geeky.
In the long run, those languages merge more or less into look a-likes.
Example would be enums. Swift, Java (and brethren like Groovy, Kotlin, Scala), Dart ha
Re: (Score:2)
One of the things to note here is that this is a mature, well defined, and simple microservice and one with little actual data concurrency.
So for this, Java IS overkill and the challenges of tuning GC are going to be real. So i'm not surprised that other languages did better. Go, Rust, C or C++ would also have been good choices.
The peak and trough of a day differ by approximately 50% regionally. To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. A faster bootstrap time is a crucial requirement to support this dynamic scaling strategy.
One thing of note though is that java app startup times for an app that size are still going to be say ~1 min. and that's going to be cut to what ? 10 sec? This is not reall
If you think Java has problems.... (Score:4, Informative)
More than likely, but Java does have a lot of inherent problems that almost certainly didn't help. It's also quite plausible that garbage collection was biting them pretty hard; example: https://discord.com/blog/why-d... [discord.com]. The whole reason for switching in that case was because of GC, which is inherent to the language's runtime, and you can't do anything about it. And of course: Java IS a memory hog. Java DOES take a long time to spin up, both initially and for new threads.
They probably would have done slightly better with rust given you can simply rely on normal pointers instead of reference counting, but knowing Apple that probably came down to an NIH decision.
...try their competitors!!!
If you're comparing to Rust?...OK, fair...if you're comparing to Go...oh, that's a painfully slow and disappointing garbage platform...the difficulty of C with the performance of node/Python. Node.js and Python are famously slow and bloated...and C# just really doesn't compete, even before you consider the MS factor.
We are in a new interesting era where platformless choices are becoming an option, like Rust. Go was interesting...until you see the performance...since Java is almost twice as fast...not sure the point. Java is a memory piggy, but I've been working with it for over 25 years, on some platforms that are HUGE and very performance sensitive. It holds up extremely well and scales well and is the most reliable platform I've worked with, by far.
Startup and memory are just not a concern in most business scenarios. No one cares about startup time. Whether it take 1 second or 1 minute to startup...doesn't matter. Thread startup time is also pretty fast, so not sure what you're talking about there...that might be programmer error if it's slower.
Memory usage?...similarly, no server operator cares...RAM is cheap...new instances aren't. It's far cheaper to throw RAM at a platform than cores or machines.
One huge advantage?: Java is predictable and reliable. However it runs for the first week is how it's going to run for it's first decade. I have applications that were started 20 years ago and have most of their code from 10 years ago....running strong, serving millions of users for a highly profitable business....doing real work for real money....upgraded 100s of times...ran in 3 different clouds as well as on-prem. No memory leak issues, great performance (compared to the time the company tried writing services in node.js), just reliability and predictability.
Re: (Score:2)
dude, i'm relatively a fan of server side java, but where is this coming from?
Go...oh, that's a painfully slow and disappointing garbage platform...the difficulty of C with the performance of node/Python.
i've only played with Go a little, but from what i read i thought was generally quite good. Like faster than or on par with Java for CPU and network usecases.
Re: (Score:2)
I've worked with Go a bit. It's definitely easier than C in that you've got a garbage collector to help you avoid segfaults (and unlike Java, you're not forced to pass everything but primitive types by reference) and you don't have to drop your function signatures into every file you're calling them from.
But Go has a few drawbacks that really ruin the language for me: No enums. Period. This really sucks for somebody like me who makes heavy use of Rust's excellent enums (really, IMO rust's killer feature IS
Re: (Score:3)
Node.js and Python are famously slow and bloated...and C# just really doesn't compete, even before you consider the MS factor.
Golang will perform way better than those (and who the FUCK thought making a server side language out of js was a good idea?) But actually if somebody held a gun to my head and said pick C# or Java for your next project, I'd take C#. Java honestly feels like an early alpha release of C#. C# is heavily inspired by Java, but also eliminated most of its crap. Like for example, checking if two strings are equal ACTUALLY CHECKS IF THEY'RE EQUAL, not merely the same fucking class instance. C# has CLI tooling that
Re: (Score:2)
Until they are. Like embedded work.
Frankly: you are an idiot.
Java in embedded environments has no start up time that is in any way different than any other language.
The system powers on.
The CPU jumps to a predefined address in ROM.
The boot loader verifies the ROM images
The execution starts usually with loading the real executable from a ROM or flash, at least partially into RAM.
The boot loader unpacks the RAM image and verifies it.
After other verifications are done: it jumps into the start up code, either
Re: (Score:2)
It's also quite plausible that garbage collection was biting them pretty hard
So says the summary. But it would be interesting to know why. Modern Java (since 20 years) has no GC spikes.
The whole reason for switching in that case was because of GC, which is inherent to the language's runtime, So says the summary. But that is unlikely.
and you can't do anything about it. Yes, we all know that YOU can not do anything about it. Because YOU know nothing about Java. Obviously there are 100ds of things you can do
Re: (Score:3)
You do things right and don't bring all the patchwork and tech debt with you.
You also fail to bring certain subtle business requirements with you, that have organically developed over time, while also reintroducing many bugs that were fixed years ago.
Re: (Score:2)
*cough* Vista *cough*
Re: It's not the language. It's tech debt. (Score:2)
Sometimes it's for the better. ;-)
Re: (Score:2)
Rewriting usually only works on small projects. Projects where tech debt can't really accumulate because they're relatively small and self contained and making modifications is relatively trivial.
Larger projects accumulate tech debt because it's large, unwieldy to the point where mak
Re: (Score:2)
Here, the problem looks like it was relatively self-contained and small, and likely had very little tech debt to begin with being likely something can easily have refactored.
This exactly. it's a relatively simple microservice with a small and stateless API and well defined behavior. It's a dream candidate for this kind of experimentation.
Their original app was probably garbage (Score:2)
Whenever you rewrite a product in a new stack you pretty much create it from scratch. You do things right and don't bring all the patchwork and tech debt with you. That's what caused this speed-up. No the change of the language.
Agreed! In addition, Apple has a BAD history when it comes to software. They have the "reverse-midas-touch" when it comes to software...in that anything they touch turns to shit....look at iTunes as a shining example. They've gotten better in the last decade, but I will wager their legacy app was garbage...probably some old struts app from the early aughts...maybe some EJB 2.1 magic?
What I am interested in, when evaluating platforms, is how much of a performance benefit Swift will provide vs a well-w
Re: (Score:2)
They've gotten better in the last decade, but I will wager their legacy app was garbage...probably some old struts app from the early aughts...maybe some EJB 2.1 magic?
Likely it was written with their own Java Frameworks.
https://en.wikipedia.org/wiki/... [wikipedia.org]
And https://en.wikipedia.org/wiki/... [wikipedia.org]
And as you said later migrated to other EJB servers.
Those old technologies did easy scale. And no one is porting a running system to modern EJB standards.
What I am interested in, when evaluating platforms, is how much of
Re: (Score:2)
most likely, they do actually hint at architectural changes in the otherwise uninformative but boasting abstract. except we'll never really know because they won't show any code to compare.
dunno, i'm an old nerd and somehow still do have a soft spot for /. but ... who actually reads this sort of retarded advertising crapware nowadays?
Re: (Score:2)
Swift in general tends to outperform Java by 20% or so.
Obviously some of it is a superior refactor. Some of it is the fact that Java is shit.
Re: It's not the language. It's tech debt. (Score:2)
say what? (Score:3)
"...close to 85% reduction in lines of code..."
Extremely unlikely. Worse yet, anyone who would claim this is clearly not a programmer.
Re: (Score:1)
If you've ever worked on a legacy codebase then you know it grows organically and a lot of new additions can be nearly duplicates of existing code, just tweaked for different scenarios. And sometimes dead code isn't removed. This isn't a fault of the language, but of the new people working on the system that haven't gotten properly familiar with what's already there, and reviewers not calling out submissions for these problems because they're under the gun to just "approve, approve, approve."
In other words
Re: (Score:2)
Bullshit. An 85% reduction would be 20 lines of code reduced to 3 lines. There is no explanation for such a reduction, and dead code isn't code.
Re: (Score:3)
Depending on how old the Java code was it could have had:
A lot of boiler plate interface / factory / etc patterns.
Collection modifiers run as for loops instead of single line functions like apply / map / etc.
Much more concise when it comes to import statements.
Swift has named parameters, so maybe the Java code used a parameter object as arguments for readability.
Swift lets you write extensions for pre-existing classes which can neaten up a lot of code (granted you can do this in Java with some interesting a
Re: say what? (Score:4, Insightful)
dead code isn't code.
That is the necrophilia motto. "Dead body is not a body. No crime."
Re: (Score:2)
I do not know Swift, but I have worked professionally in 11 programming languages and studied a few others. Some languages are just more efficient at expressing either specific topics or general notation. Java tends to be verbose. As an example: Quicksort in Java is ~30 lines of code. Quicksort in Haskell is 5 lines for similar time complexity. It's not beyond imagination that Swift, as a more modern language where advanced features let you express whole chunks of code in one keyword, could be really effici
Re: (Score:2)
In Java style taught in schools, they'd have an explosion of tiny classes that do not do a lot of work. Then you have a whole group of design patterns that only exist because of having to put everything into OOP. Such as the Singleton pattern or the flyweight pattern which exist to circumvent the rigid paradigm of Java.
If you define protocols and a lot of language overhead that adds up to a lot of compiler bound code that produces next to nothing in the end but hints to the compiler.
I could see a rewrite ge
Re: (Score:2)
Then you have a whole group of design patterns that only exist because of having to put everything into OOP. I suggest to go back to school then.
Such as the Singleton pattern Has nothing to do with OOP. Ooops.
or the flyweight pattern which exist to circumvent the rigid paradigm of Java.
Has nothing to do with OOP. Oooops
That imported generic and adapted source code adds a lot.
There is no difference between "importing" code and calling it, versus writing the code yourself.
And on top of that: code in libraries
Re: (Score:3)
I'd say this is plausible, but mainly because Java has a lot of ceremonious cruft that most languages don't even need. I've never used swift, but if it doesn't force you to bundle everything into a namespace and a class like Java does, then it already has a big advantage in terms of being concise, and most of all, using fewer lines. That would be especially true if they followed a lot of Java'isms like creating getters and setters for everything, which in most cases is really just an excuse to add a lot of
Re: (Score:2)
a language may have cruft but that doesn't mean code written in that language does, and things like namespaces don't account for 17 out of every 20 lines of code. Yes, different languages could have different line counts, but not differences so great.
Re: (Score:2)
In an extremely heavy allocate/free environment, GC in Java will take something like 10 minutes out of every hour. Which is significant, but you shouldn't see a 40% increase in throughput from that either.
Someone else suggested they were probably parsing JSON/XML repeatedly or something similar, which is possible considering 'parsing' is just a simple function c
Re: (Score:2)
force you to bundle everything into a namespace and a class like Java does
Java does not force you to put anything into "namespaces".
As usual you are misinformed.
I strongly suggest to stop ranting about stuff you obviously never have used.
Re: (Score:2)
Extremely unlikely.
It's not: you're assuming that the Java code they wrote before wasn't just horrendously awful.
In 1994, the "Design Patterns" book was published. I have nothing against the book, but it was widely misunderstood. It is a descriptions of patterns of design that are in common use, so everyone has a common set of names to refer to. And maybe if you spot those patterns in your code, you can be inspired to generalise a bit in obvious ways and/or simplify things by splitting them along the lines
Not News (Score:5, Insightful)
Apple reports that the language Apple wrote performs well when a bunch of Apple engineers use it to remake a project. Why is this news?
There are hundreds, if not *thousands* of devs on Slashdot who have rewritten something ... even in the same language ... and seen massive performance improvements. The fact that a 2.0 version of something has the potential to be better than the 1.0 is not news, and neither is anything else in this article.
It doesn't even offer a real comparison of Java vs. Swift, because they didn't just translate Java => Swift ... they wrote an entirely new version of the code, so it's impossible to tell what parts of the performance increase came from the language change, and what came from the rewrite.
Where's the AI? (Score:3)
I fell down the stairs and hurt myself. AI has made me all better. Thank you, AI!
Java (Score:2)
Java vs it's competitors (Score:2)
While I know Java doesn't inherently have to be slow and use excessive resources, I've never seen a significantly complex Java application that utilizes resources as expected. The CPU and memory usage is always a factor of 10X what I'd expect from a C++ application. I don't know the reasons as I'm not a Java developer, but I also don't find Java enticing enough to learn enough to find out.
Java is quite fast and reasonable in memory usage. It is far superior to it's normal competitors, Go (the slowest disappointment I've ever used), Python, JavaScript, and C#. While C# and Go are better languages than Python & JavaScript, IMHO, Java is the king of those 5 when it comes to response time performance.
Now if you're comparing well-written Java to well-written C++...C++ should have a strong and noticeable advantage. Rust is noticeably faster and lighter as well.
Java's strength is speed
Re: (Score:2)
Of languages that suck, Java doesn't really suck! For languages that do not use resources well, Java does not use resources poorly!
Garbage collected languages do not use memory well. Applications that avoid dynamic memory use can mitigate that shortcoming.
Re: Java vs it's competitors (Score:1)
I tend to view Java as a holdover people locked into what their doing, a bit like Cobol.
These same people try to force Java into lambda architectures and claim the performance problems are not their fault.
Re: (Score:2)
Re: (Score:2)
Well, alternative to what?
This particular project?
There most likely is none.
Python would be quite okay. As there likely is not much business logic but mostly orchestrating of requests to various servers.
The question regarding the old system would be: were there application servers? As in server applications that have "fat" business logic. If so, Python likely drops out.
So, what is left: .NET and C# ... would be a big jump in terms of tools and libraries. A small jump in language.
o jumping to
o another langua
Re: (Score:2)
Java is quite fast and reasonable in memory usage. It is far superior to it's normal competitors
and C#.
lolwut? [vercel.app]
and Go
lolwut? [vercel.app]
Seriously, what fucking universe are you in where Java is competitive?
Now Python- lol- I'll give you that, but Python and Java aren't really comparable. Python is an interpreted language, Java is not.
Re: (Score:2)
Is this your "I write something, but do not say what it means" week?
In your "lolwut" examples Java is nearly all the time faster than C#.
For some reason I assumed you wanted to claim the opposite. But no idea.
Go versus Java has some impressive wins for Go, but also a lot of wins for Java (e.g. Mandelbrot and such)
So the answer seems to be: it depends :P
Re: (Score:2)
The CPU and memory usage is always a factor of 10X what I'd expect from a C++ application. ...
That is unlikely to be true. Because then you would need to have an equivalent C++ program
I do not think that enterprise systems do exist in such an extend that you can compare C++ versus Java.
Ironically (Score:2)
Java usually gives me swift performance gains, especially early in the morning. :-)
Re: (Score:2)
If I have too much it gives me the shits.
Re: (Score:2)
You know slashdot is full of old farts (no offence) when we start discussing our health problems and bowel movements. I am having a very hard job not adding to the conversation.
Same as it ever was (Score:1)
This has always been the case. Since the late 50's there were languages designed to run fast and others that were programmer-friendly instead of machine-friendly.
Performance (Score:2)
has never been one of Java's strong suits.