Swift or Java?

Dear community. I’m new to programming (and posting to forums!) and would be very grateful for your help. I’m a mature student studying for a conversion course in Computing and have written a dissertation comparing Java and Swift for new programmers. Part of this is a ‘guideline’ for new students to object-oriented programming.

For feedback on the guideline, I’d be really interested to hear if you think I’m right or wrong in what I’ve concluded, and for any comments on which language, as a student of OOP you found to be easiest to learn, had the best IDE, or was of the most relevance.

Critical evaluation

• When choosing which language to learn there are multiple factors to consider – ease of learning, working environment (Integrated Development Environment), the raw speed and the relevance of the chosen language; How applicable is it to the intended use?

• The results of my critical analysis demonstrated that both object-oriented languages are straightforward to pick up, with a wealth of learning materials available. However, of the two programming languages, Swift is easier to pick up do to the more straightforward syntax and fresh and modern learning materials.

o As an example, there is no ‘main’ method required in Swift and the syntax is certainly more intuitive and readable.

o While Java is associated with a large volume of learning material, built up over three decades, Swift is only five years old but first and third-party material has a more exciting look and feel about it.

• In terms of the IDEs, Java certainly wins in terms of choice – there are many IDEs to choose from, and if a student doesn’t like one, it is straightforward to try another. As a personal preference, I found the Xcode interface to be a more pleasing environment in which to work.

• When it comes to popularity and practical application, Java is the preference - only 7% of developers on stack Overflow (a popular question and answer site for developers) are currently using Swift, compared to Java’s 41% (Stack Overflow, 2019).


• In term of raw speed, my quantitative analysis of the bubble sort and prime decomposition algorithms demonstrated that Java is orders of magnitude faster than Swift when repeatedly processing these looped algorithms. Although this may have a lot to do with the code being run in Swift playgrounds, this significant performance differences may be a deciding factor.

• The comparatively sluggish speed of Swift may be judged as being ‘worth it’ depending on the intention of the student: If the intention is to work in established, often speed-critical areas, then Java is the clear winner. Alternatively, if iOS development is the end-goal, then the choice should be Swift.


• In terms of ease of use and inspirational, modern materials, Swift is an excellent language to learn. Additionally, if programming apps within the iOS environment is the number one goal, then Swift is the clear choice.

• Should aspiring programmers require a well-rounded introduction to object-oriented programming, while keeping their future goals open, or consider speed to be a significant goal in the applications that they produce, then their decision should be weighted towards Java.

Let me know what you think...
Many thanks

If you compile and link your Swift code, you will find that execution time is orders of magnitude faster than what you measured in the Swift playground. Whether it's faster than Java depends, although in my experience, Swift executables are most often faster than Java, on the order of C/C++/Fortran, which I also use frequently in addition to Swift.

The Swift playground is just that, a playground for prototyping and figuring things out. Production quality code does not use the playground; it's compiled and executed as native machine code.

Your recommendations and observations are mis-leading in that regard.


On the performance side, I'd expect Swift to be faster than Java. Playgrounds are definitely not a good way of measuring performance, as there is a big added weight relative to inspecting and showing everything in real time to the user.

But for the main topic, I think that the main factor here would be the platform of choice:
if the student wants to tinker with iOS apps, it's useless to learn Java (not considering j2objc a thing here...).
On the other side for Android Java is supported (even though I recon Kotlin is preferred), while Swift is kinda working but still has issues as is not officially supported.
Then there are still more use-cases, e.g. Server (Java is prevalent but Swift is picking up), Machine Learning (see Swift4TensorFlow), Scripts, Web, Embedded systems, etc...

In practice I think that "what language to learn" is something that can be answered only after "what do you want to do with it".


Hi. Thanks for your response - much appreciated. Yes I expected Swift to be faster, and I’d kind of come to the same conclusions regarding Playgrounds. Thanks for the explanation on why this is.

Yes, it does come down to the platform and the question ‘what do I want to achieve’ should definitely inform that.

I’m actually not sure how to test the speed outside Playgrounds - I wonder if it’s possible to run code not in a Playground, buy not in a compiled app either...

Many thanks again.

There's an amazing swift benchmark app called Attabench that you may be interested in

1 Like

You can create a macOS console application with XCode, and then add a "Unit Test target" with "File > New > Target...", choosing "macOS" and "macOS Unit Testing Bundle".
In the generated file "Test.swift", you'll find an example of how to write a performance test using the measure function. You can then use the "Test" functionality of Xcode to run your tests, and you get some nice graphical overview of the results :slight_smile:

1 Like

I wouldn't recommend this, as test code (and apps/libraries built for testing) are compiled without optimisations for the sake of debuggability.

To compile and run a simple Swift file (let's call it test.swift), first compile it (with optimisations, since the Java JIT will be optimising as well):

swiftc -O test.swift

Then run it:


The swift compiler will give the output executable the same name as the input file by default ("test" in this case)

To benchmark, you should run the intensive work several times (e.g. in a for loop), storing the time before/after the loop executes, subtract them to get the total duration, and divide by the number of iterations to find the average amount of time the intensive work took.


Thanks for your very valid points here. I definitely expected Swift to be faster, and I’d come to the same conclusions regarding Playgrounds. When you talk about ‘production quality code’ it makes me wonder if it’s possible to test the speed outside a Playground (but not in a compiled app). I guess I could try exploring Swift’s REPL?

I also agree that the conclusions mislead in this respect, and have amended to make it clear that I’m talking about Swift run in a Playground...

Your feedback is much appreciated - cheers!


It's worth noting that this is an area of active work. We are building a language server which should allow first-class integration with other editors, such as VSCode (Xcode is switching to use this same component, extending the protocol as required, so all editors should be on equal footing eventually).


This is a very superficial evaluation of two incredibly different programming languages. I'm not even sure what the point of this is, but in any case the decision on whether to use Swift and/or Java for some kind of application should rest on some more substantial arguments than "fresh and modern learning materials" or "bubble sort is faster in Java".


Hi Ian, welcome to the forums,

I commented this on the (now deleted) StackOverflow question you asked. And it still has me puzzled:

How can you be new to programming, yet also have written a dissertation comparing Swift and Java? So are you experienced, or are you not?

This will surely come off as insulting or ad-homenium, but it's quite clear that you're not yet sufficiently knowledgable to be making the sort of analysis you're trying to make. Not to any effective degree, at least.

Uh yes, entirely. It ENTIRELY has to do with the code being in playgrounds. Playground optimize for fast compilation time (for fast user-feedback), not for fast run-time. Additionally, they tie into the code in a bunch of places, to produce rich user previews of data, show how many time functions were executed, etc. Comparing this to a Java program is completely invalid, and it's only made worse by the fact that you looped the same code many times, giving the JIT compiler more opportunities to learn and optimize.


Swift REPL is the underlying mechanism for the playground. Will get about the same results.

1 Like

Only by default. You can (and should) run performance tests in Release mode.

1 Like

Thanks Jonathan - interesting to know :+1:

Hi Alexander. Thank you for your comments. Although quite blunt - they do make sense to me. Just to clear up your confusion, I am ‘new to programming’ in that I’m studying for a conversion Masters course in Computing. My background is in Biochemistry so this is very different. I take your point about not yet being sufficiently knowledgeable to carry out this analysis - I can but try!


Great - thanks cukr :+1:

1 Like

Very interesting - I appreciate you getting back to me with your constructive thoughts on how to achieve this. I’ll have a read around this area.

1 Like

When creating apps for Apple’s platforms, Swift is obviously first choice, Objective-C near second (more so if you have pre-existing code), and maybe Objective-C++ if you need it. Thanks to recent ABI stability (and inclusion of runtime libraries in the operating systems), there’s little reason not to use Swift for new apps.

But outside of the walled garden, Swift’s benefits becomes “iffy” – lack of development tools, small community, and inconclusive overall performance gains when compared with “established” languages. Have a look at this other thread reporting the experiences of developing/maintaining a server-side math-oriented app for four years and counting.

I'm curious at your goal of testing the code "not compiled". What are your assumptions here?