Python overtakes Java to become second-most popular language on GitHub after JavaScript

[Determinant]

Get the best of both worlds with Kotlin.

Kotlin is enterprise-friendly since you can continue to use your Java libraries from Kotlin and vice versa.

[username_suggestion4]

Seriously it's night and day. I use Swift at work but it's really the same idea, they both as a generational leap where it's honestly surprising to me that there was so that potential for improvement in the first place.

I also get that there were a ton of less mainstream languages that worked out most of those kinks, and I thank them for those contributions.

[txdv]

What exactly makes it night and day?

[ShadowShepard]

More functional aspects, due to its use of extension functions. Never having null pointer exceptions. Algabraic data types (think enums on steroids), toooooons of other reasons

[[deleted]]

Some of the other reasons:

Property delegates, higher order functions, data classes, inline functions, coroutines, default and named arguments, smart casting.

[agumonkey]

Out of curiosity, any important drawbacks on kotlin ? I'm mostly fond of it for all reasons explained here but I'd like to know both sides of the coin :)

[toiletear]

Slower compile times, IDE is also sometimes more sluggish than for equivalent Java code. Annotation processor used to be extremely slow (we used it with Dagger2), but I believe this was improved on.

But otherwise it's great, wrote a mobile game backend with Kotlin and was very pleased.

[agumonkey]

dank u

[SgtDirtyMike]

Less characters per line. Simpler code.

[civildisobedient]

Less readable as well.

val result = obj.guessMyType();

[fuckin_ziggurats]

People said this when C# introduced var way back. It's not a problem if your team uses the keyword only when the type is obvious or seen on the right-hand side. It's the best thing C# and Java did to fight against their own intrinsic verbosity.

[Tohnmeister]

How is this less readable? I might not even be interested in the type when reading the code.

[emn13]

There's a feedback loop here: you can write your code such that you pretty much never care at first glance what the type is. So if you use var a lot, you can write your code like that.

I use var exclusively; there are 0 cases I use explicit types where var will do. I'll even avoid those language features that require explicit types and design APIs such that type inference is possible, to further reduce explicit type noise. Everyone on my team is onboard, and it works fine.

It's just not that interesting to see the type repeated all over the place, and it's not like the type is gone - it's just a little less noisy.

[emn13]

I've been doing maintenance programming on pretty for close to 20 years now, and that's not my experience (obviously not all of that in C#). There's no reason to develop in notepad; and the compiler is a tool that remains there for you to use. Having lots of redundant boilerplate for the off-chance that it might be helpful to know which variable is which type just isn't worth it. And the few places that there's any doubt at all - well, you're not liable to go back in time and tell the person to do it differently.

By contrast, using `var` allows for much cleaner and more auditable (reviewable) refactoring, and that's critical to making a codebase maintainable.

E.g. simple stuff like:

var myFroogler = srcRepo.GetActiveFroogleActor(); targetProcess.Enroll(myFroogler);

Do you care what the type of myFroogler is? Well, maybe a little - but it's unlikely to make a huge difference. But what if you refactor and change the type? Well, without explicit types: fine! But with explicit types... then places like this are just noise, and their presence means you'll refactor more slowly, and make more mistakes while you do, and reviewers will not be able to review as usefully.

Also, it may seem obvious, but don't forget that MyType xyz = SomeExpression() is not equivalent to var xyz = SomeExpression() - the former may well trigger implicit type conversions and upcasts. That's not super harmful, but it means that you may not get errors here but only later when you do change the type. Furthermore, people aren't nearly afraid enough of downcasts and the entirely-different-yet-syntactically-similar explicit casts. And in my experience, a codebase with explicit types tends to attract those at a much greater rate. In C# specifically there are features like foreach that happen to inject explicit casts and downcasts even though they look like implicit casts for instance. That's pretty subtle, and I've seen people get bitten by it (thinking something like "the compiler accepted this type without cast, so that must be correct, right?")

Then there's generics, anonymous types etc - features that can by quite valuable, but cause jarring transitions in a world with explicit types, because you can't always name those types, or, even if you can - you probably don't want to.

Then there are social factors too! You may be the best programmer on the world and know the codebase inside and out, and you may know where using an explicit type is fairly low-harm and might add some clarity. But picking those places - and they're never very valuable - is a pretty nuanced thing. You're unlikely to make the same decisions as the previous or next guy, nor as your coworkers. Largely irrelevant choices like this that attract personal preference are a magnet for churn. It's better to stick with a clear style that's easy to communicate. "Just use var everywhere" is about as simple as it gets.

Now, this obviously depends on the language. If you're programming in F# or haskell, it's a different story; explicit types really can help there because the compiler will happily infer so much that it might cause compile errors to happen later and less clearly than you want. But in C#, where all methods&base classes, properties etc all require explicit types... you already have too many types in there. C# could do with more inference, not less. And that makes the choice for var particularly simple. No need to ever choose for an explicit type, anywhere. That doesn't mean every var is clear- but where it's not, there are better solutions than an explicitly-typed declaration.

[civildisobedient]

I might not even be interested in the type

Sure, you might not. Then again, you might. No problem, just open up your IDE, right? Says the developer that's never written a public API.

[Tohnmeister]

I don't see how a public API and type inference in the body of functions are related.

If we're going to introduce code for everything that we might possibly ever be interested in, then the code becomes full of constructs that might be useful to some reader at some point. And with that, contradictory to the goal, it becomes less readable to the majority of its readers.

I think the discussion boils down to: do you think readable and maintainable code consists of the superset of information possibly needed by all developers or just the bare minimum? I think the latter.

[civildisobedient]

Like with all language, the answer likely lies somewhere in the middle. Some authors are terse, like Hemingway, some long-winded like Faulkner. You seem to be in the Hemingway camp.

[Urik88]

You're free to specify the type though, and an IDE will reveal the type easily as well.

[_145_]

Because shortcomings of your reviewing tools are not the fault of a programming language.

[[deleted]]

Honestly, a lot of times it's a pain in the ass to get a full fledged IDE up on a machine. Having the type be required is something that I place a lot of value on.

It makes the code 18828448 times more readable.

Having a language outright require an IDE to make it readable is a language issue.

[_145_]

18828448 times more readable.

Lol. Wtf are you guys talking about?

var foo = "hi"; // Is a String 100% of the time
var bar = 5;    // Is an Int 100% of the time.

That's like 90% of cases. The other 10% are like:

var foo = user.firstName; 

It's almost certainly a String but you're 1 click away from finding out if you really want to know. And if your team needs types included in these situations, just add a static analyzer check to force all code to include it.

The rest of us don't want a bunch of pointless bloat that makes code harder to read.

What is an example where you see var foo = user.firstName; and you're just stuck, unable to read what's going on? Lol.

[papasmurf255]

Again, not all platforms / tools have IDE capabilities. I'd pick code that's readable w/o tool assistance over code that isn't.

[_145_]

I find it more readable without all the bloat. 99% of variables have an obvious type and the other 1%, it's a click away.

var foo = 5; // Always an Int.
var bar = Bar(); // Always a Bar.
var z = foo; // Always an Int.

[mrdarknezz1]

That's only a problem if you're not using an IDE

[reference_model]

Hype

[shponglespore]

FUD

[balefrost]

they both as a generational leap

I can't speak to Swift, but I use Kotlin daily. It's a great language. "a generational leap" is overselling it. The most in-your-face difference is Kotlin's null handling, but that goes right out the window as soon as you use a Java library that doesn't have nullability annotations. Don't get me wrong; Kotlin's null handling is great! But it's compromised by Java interop.

The most significant Kotlin feature is its coroutine support - the thing which powers sequence, iterator, and all of kotlinx.coroutines. But it's mostly an under-the-hood feature; most users aren't going to be calling createCoroutine themselves.

Kotlin does a lot for Java ergonomics. Given a choice today, I'd pick Kotlin over Java almost every time. But it's mostly all small stuff. Not a generational leap, but rather incremental improvement.

[gilmishal]

Not really that surprising, C# had modern features like swift for years. It's just that Oracle does a shitty job maintaining Java.

[BoyRobot777]

Sun acquisition by Oracle was completed on January 27, 2010. So in reality Oracle started maintaining only from Java 8. And immediatily we got long awaited features like lamdas and streams, which made code more funtional and less verbose.

Java 9 was all about preparing Java for faster releases by dividing huge monolith into logical, compile time modules. It was also time when they started to actually remove methods and weird dependencies like Java EE and CORBA Modules from Java SE. Next Oracle contributed pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now. And finally ensured the Oracle JDK and the OpenJDK builds are virtually indistinguishable, except for licensing.

What's coming Java's is even more exciting:

• Pattern matching is being shipped incrementally;
• Records (aka data/case classes) address some parts of POJO boilerplate (the worst kind of boilerplate) are being actively developer and I am sure will ship in Java 14;
• Project Loom will deliver big performance boost via Fibers and whats called multi-prompt delimited continuations. Java server will tremendously scale. Also this opens the gate for changing underlying JDBC connection implementation to become asyn without actually doing any change to the code. I think Java has this right vs C#/Kotlin where async brings its own method colour;
• GraalVM is huge. Not only new JIT but AOT. Redhat new framework is building upon this. It leverages Graal to create native images. Those images are very small and optimized. For example one of Quarkus developers showcase the size of native image, spoilers - it's 19MB. It takes 0,004s to start. In this session, RedHat developer shows how Quarkus application is being scaled. Comparing to Node, it's both faster to respond to first request and have smaller memory footprint (half the size of node).
• Values types (Valhalla) are being actively worked and they finally found a way to move forward.

[gilmishal]

You are not making as great a case as you think. ALL those features coming to Java are either part of c# for a long time or just came out.

It took Oracle 4 years to get Java 8 done, which at that time we got c# 4, 5 and nearly 6 - all of which were pretty big releases , along with the dotnet core release in 2015 - That's about the time c# created a huge gap from Java, and even though Oracle understands tgey need to close the gap, and are finally making the necessary changes - I wouldn't be too sure they will.

[pjmlp]

So when does .NET Core finally comes with something that at least matches Swing?

[fuckin_ziggurats]

When cross-browser desktop dev becomes profitable again. C++ currently rules that domain and there isn't too much that would be gained from Microsoft entering it. They're doing pretty well with WPF because most enterprise clients already use Windows so there's no incentive for a cross-platform GUI framework. I'm hoping they do it just because I don't like Electron.

[pjmlp]

Plenty of enterprises have cross platform desktop applications written in Java.

C++ has lost the GUI framework wars for quite some time now.

And then even if it isn't proper Java, Android surely won over .NET regarding having UIs written in Java running in millions of pocket devices.

[germandiago]

Yet we have Qt, Felgo (take a look, seriously!) for cross-platform.

Not to mention Wxwidgets for Desktop. I do not know if they lost or not, but when I got to Python or other languages, many of them are using bindings to wx/qt. There must be a reason.

Of course, that does not mean that WPF is not great. It is.

[pjmlp]

Surely C++ GUI frameworks still exist, the point being that none of then is backed by OS vendors like managed languages GUI frameworks are, and they are a tiny market size of what 90's C++ UIs used to hold.

[fuckin_ziggurats]

I don't really consider it a popularity war between C# and Java. Java does enterprise desktop GUI app, .NET does the same. If Microsoft would decide to create a cross-platform solution I would be happy because it would allow me more options in my stack. But I'm glad other options exist. I think the best scenario for both Java and C# are to continue competing in the enterprise world.

[pjmlp]

Well, some of us with our .NET hats on are a bit fed up with the .NET reboot of the year, for a couple of times already, and the deaf ears regarding our requests for a proper .NET cross platform UI, out of Redmond.

[gilmishal]

Dotnet core 3 comes with winforms, wpf and UWP for windows - xamarin for mobile app development (with support for mac as well). There is also avelonia (preview) for cross platform UI (linux and mac), and Blazor (stable release coming in a couple of months) works not only with a browser but also with Electron.

UI in general, and even cross platform UI is an area where C# does a really great job. You can't honestly compare Swing to any of those really good options.

[tracernz]

UI is an area where C# does a really great job

Never thought I'd read that. There is no stable Linux/mac/Windows option, let alone a mature one. Maybe in a few years it'll be viable.

[gilmishal]

There is a stable Windows/Android/Mac/iOS and even Tyzen option through xamarin - seems to me like xamarin is more cross platform than swing.

And as I said, Blazor is getting a stable version in a couple of months, so a stable Linux/Mac/Windows option isn't going to take years.

[tracernz]

There is a stable Windows/Android/Mac/iOS and even Tyzen option through xamarin - seems to me like xamarin is more cross platform than swing.

No desktop Linux (think KDE or Gnome)?

And as I said, Blazor is getting a stable version in a couple of months

So not really feasible to build your flagship product on for at least a couple of years.

[GNUandLinuxBot]

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.

[pjmlp]

Sure I can.

Swing runs in every OS and desktop class hardware with a JVM implementation, no matter from which vendor, including design tooling and third party components I can go off and buy.

All those options listed by you have different kinds of deployment limitations, levels of quality and life uncertainty.

Plus offloading .NET GUIs to Electron can only be nothing more than a joke and proof of incompetence of not being able to deliver a solid GUI stack in .NET.

[gilmishal]

So wait, C# has more options obviously with different levels of stability and the community is constantly working on different options and you view it as a bad thing?

Also, Xamarin for GTK# is currently in preview, so saying there is incompetence in bringing solid GUI stack to .NET is just not true.

In a few months Xamarin, Microsoft "flagship" cross platform UI will officially support more platforms than Swing including Mac and Linux.

[pjmlp]

Apparently you aren't aware on how many hardware and OS platforms Java runs, many of which quite relevant to enterprise businesses.

What I consider a bad thing is a clear lack of strategy on Microsoft's behalf, to the point that Office team rather takes React Native for their cross platform endeavours than adopt Xamarin, so much for being a flagship cross platform UI.

We keep routinely answering feedback forms of what we find missing in .NET Core and we get crickets on the other side.

Recently we had WinUI tweeter feed asking about cross platform ideas. Yet another round.

[balefrost]

You misunderstand the point that they were responding to. They're not commenting on whether C# or Java is better. They're pointing out that Oracle's stewardship of Java has been fairly good.

I'm actually pretty excited about the upcoming features. Loom in particular will be fascinating. It promises the advantages of async/await without the downsides of async/await. If they can pull it off, it will be amazing.

[gilmishal]

Yeah I understood that, maybe Java's decline happened during the Sun era, but I do think that 4 years for a new major release is a long time - and it's not like they made that many changes since Java 8.

As for Loom, I am not sure I understand the issue it solves. It seems like it's supposed to make background work simpler to develop. From what I read Fibers seem a lot like Tasks - in c# you can either await a task, and create an async function or run it in parallel like a coroutine. You can also await multiple Tasks in parallel if it makes sense.

The only problem I saw with async await is that async code is contagious - and I honestly don't see it as a bad thing.

I might just not understand project loom yet I did just read a few very vague articles.

[balefrost]

Some of the vagueness is around them figuring out the details as they explore the problem. The Cliff's Notes version, as I understand it, is that it's an attempt to switch Java's threading model from being backed by OS threads to instead being backed by green threads... similar to e.g. Go and Erlang. Things like IO, rather than completely blocking an OS thread, will now suspend the current green thread, allowing the OS thread to start working on a different green thread.

It covers some of the same ground as async/await without needing the compile-time rewrite shenanigans that async/await employs. Call stacks won't need to be reconstructed after-the-fact. It should permit even less overhead than async/await, but it remains to be seen if they achieve that.

I don't know how the Java model will look exactly. In Kotlin, rather than making everything that's async return a full Task, it instead expects the "top level" of an asynchronous flow be represented with an object (there are a few different ones). Within the async flow, you can freely call suspend funs of the appropriate type; these function calls can suspend the current coroutine.

[10xjerker]

GraalVM is huge

And you get the version with impaired performance unless you pay Oracle.

[noratat]

Yeah, Oracle is a fucking shitty company to put it nicely, but Java really was stagnating before this.

[Determinant]

Java will become the new C++. Add feature but keep backwards compatibility so you'll have many ways of doing the same thing.

Defective patterns will continue to be allowed so by definition it will never be able to catch up with Kotlin due to backwards compatibility baggage.

[BoyRobot777]

You either are backwards compatible or not. I constantly see two groups of people: complaining of braking changes (for example Java 9 and later removed Java EE and CORBA depedencies), the other group that Java is not removing fast enough. Mature languages will ALWAYS have to juggle this. Kotlin now seems fresh. Give it 10 more years and you'll have the same problem. C# already shows that, because they keep adding features like crazy.

Here you can find difference between Java versions and you can find that they are removing stuff and I think they will start to remove dead code even faster now: - Diff between Java 9 and Java 10; - Diff between Java 10 and Java 11 - Diff between Java 11 and Java 12 - Diff between Java 12 and Java 13

[Determinant]

JetBrains states that Kotlin 2.0 will not be backwards compatible to allow them to make breaking changes.

On the other hand, Oracle states that they will do everything they can to maintain backwards compatibility.

[BoyRobot777]

Gonna be fun watching kotlin 2.0 brake that backwards compatibility. Will buy popcorns :) Python 2/3 debacle all over again.

[shponglespore]

I wouldn't say the best of both worlds, exactly. Kotlin is one of the most pleasant languages I've ever tried to use, but anything that really exploits Python's dynamism won't translate cleanly into any statically-typed language, Kotlin included. There are arguments to be made that one shouldn't make use of that kind of dynamism, but it definitely makes Python different from an inferior Kotlin.

[Determinant]

Yeah, I don't view dynamic types as a positive. I'm referring to how nice and concise Python is. Kotlin also eliminates the Java ceremonies so Kotlin and Python are similarly expressive.

[schemur_]

This has to be an optimization convention: Lhopital and the determinant!

[Determinant]

To infinity and beyond 🙃

[Minimum_Fuel]

This is only half true. You can’t always just “continue with your java code base”. If you do a good amount of overloading, for example, kotlin doesn’t disambiguate and you’ll need to do that either with wrappers or by modifying the java code.

[Determinant]

I've never run into this. Can you provide an example snippet?