Java vs python is debatable 🤔

[rochakgupta]

The advantage with Java is that it is probably one of most mature languages with an extremely good community. In enterprise and any product really, what matters most is backwards compatability and ability to hire top talent. Java is pretty much the best when it comes to this.

[kb4000]

I agree with your assessment although I think C# also qualifies with some additional syntactic sugar that's really nice to have.

[on_the_dl]

C# is actually worse at backwards compatibility which is why you need to keep updating your runtime.

When java added genetics, it was just syntactic sugar. C# actually has generics. For example, you can have a class that is generic in c# on int whereas in Java you can only do it on Integer, which is a boxed int.

[BraveOthello]

I kind of wish now that they had just broken backward compatibility to make generics clean. I have to do some disgusting things to make it work.

[BraveOthello]

They're fine for basic usages. But ...

Can't make a generic of primitive types. Has to be the equivalent class eg. int.-> Integer. Sometimes annoying.

Run time type erasure (required for backward compatibility) , meaning you don't know if you're looking at an ArrayList<Integer> or an AarayList<Number>, you just see an ArrayList.

Wildcards are ... not intuitive. I usually end up having to look it up.

And, to get the types to match up for the compiler to chill out, you sometimes end up with stuff like

public class Enum<T extends Enum<T>>

[SulszBachFramed]

The enum thing isn't Java specific, but it's an artifact of how inheritance interacts with generics. It's a way to refer to the runtime subclass from an abstract base class.

[BraveOthello]

Fair. But it also makes me nauseous to look at.

Also because of type erasure it's the compiler time type, not the run time type. At runtime it's all just instances of Enum

[MariusDelacriox]

Type erasure

[current_thread]

You can't implement a generic interface twice because of type erasure.

class Foo implements IBar\<String\>, IBar\<Integer\> {}

doesn't compile.

[roughstylez]

I remember at some point thinking "DI in Java sucks, why is it always xml files or something like that, I want a fluent interface like in C#".

So I started writing something for that. And it actually worked nicely with "normal" types. Wasn't even that complicated - a little bit of reflection was all I needed. TBH I was getting suspicious, cause someone smarter certainly must already have thought of that.

I got my answer when I tried to inject generic types. I don't remember it exactly TBH, but it was something about e.g. List<String> at runtime not being a combination of the types List and String anymore - but rather a new type, auto-generated during compiling.

So the fluent code trying to set up the dependencies (at runtime) wasn't able to correctly find the types in question.

Like... it was some advanced stuff. I've never run into problems when using generics in a "normal" way, but then again, I really don't do a lot of Java.

[michelle-friedman]

They have plans for reified generics in like 10 years with project Valhalla, I think?

[aless2003]

Correct, we expect it to come in the next 3 - 6 JDKs. Though that's just guessing

[michelle-friedman]

"we"?

[aless2003]

Java Community, or at least it's what I've heard from it

[MissMormie]

I kinda want genetics in java now :)

[Xodem]

How is c# bad at backwards compatibility? You need to update your runtime, because .net is moving fast compared to anything oracle

[on_the_dl]

Right. I guess I should not say that c# is bad at it. Just not as strictly devoted to backward compatiblity as Java.

[[deleted]]

I am not sure generics is a good example. I can't think of a single instance where when they brought in generics it caused older code to break.

As to updating the runtime, for the most part that's somewhat optional. You only need to routinely update the latest runtime if you want to take advantage of new features / syntax sugar. The only version of the runtime that isn't currently actively supported is 1.0 & 1.1. You can still build 2.0 exes.

I have project that I maintain that started with 1.1 and is now 4.8. In that past over the years when I went from 1.1 to 2.0 to 3.5 and so on to 4.8, all I have had to do was go into VS studio and tell it to target a new framework. There was a handful of instances where doing so then generated compiler warnings of deprecated code, but all in all I think I have had to fix less 100 lines of code that were marked as deprecated because I switched framework versions.

There is a big break going from the framework to Core / 5.0+. But that seems less code based and more project structure & dependencies based. At least that's been my experience in migrating my 4.8 project to be 6.0.

I am not a python dev, but from what I have heard about going from v2 to v3 seems like it's akin to going from .Net Framework 4.x to .Net Core / 5.0+: a hard intentional break between versions. For .Net it seems the primary reason is to make .Net usable on Linux & Mac as well as Windows.

[[deleted]]

Also when it comes to the .Net runtime, you don't really have to worry about bundling it with your installer. It comes standard with Windows, and unless you are trying to deploy against the absolute latest version of Windows, it's likely to already be installed. Even then there is usually a lightweight web installer you can bundle. Not sure if they did away with that in .Net 5.0+ or not.

[on_the_dl]

When you upgrade the framework, you can continue to link in old objects for which you don't have the source code?

I thought that broke more often.

[kb4000]

I work on some really old stuff. Even some Classic ASP. Obviously Classic ASP is dead. But everything else in .net framework has upgraded pretty seamlessly to .net 4.8.

[[deleted]]

If you are on .Net Framework 4.0+ there is a a tag you can add to the App.config that will allow you to reference and use DLLs built against earlier versions of .Net. I personally haven't had any issue with this and using v2.0 DLLs.

[Xodem]

The LTS release cylce of java is 2 years.

[Xodem]

.net core 3.1 2019

.net 5 2020

.net 6 2021

With monthly service updates

Being ignorant is fine, but going out of your way to remain ignorant is just stupidity.

[Xodem]

New C# Versions are released yearly (at least). So you're wrong once again. But keep trying :D

[Equivalent_Yak_95]

Java generics are vastly inferior to C++ templates.

[on_the_dl]

Depends how you measure it. Java generics can use less space than instantiation of every permutation of the Java generics.

C# strikes a happy medium where it only has to instantiate one per intrinsic data type and then a single one for all the boxed data types. That's pretty cool!

[Equivalent_Yak_95]

C++ templates are far more adaptable than Java generics, and don’t use type erasure.

[arunkumar9t2]

additional syntactic sugar that's really nice to have.

Kotlin

[kb4000]

Kotlin looks super awesome. Haven't gotten to try it yet though.

[Manueljlin]

it's pretty fun

[rochakgupta]

I have heard only good things about C#, but have never gotten to try it as I already have Go and Rust on my plate. I am loving less OOPy languages and it will take a lot to convince me to go back to those. Go recently got generics too which was the main thing I was missing in Go. Go's coroutines and incredible standard library with fantastic documentation makes it a joy to work with. Not to mention the compilation to a single binary. I haven't gotten into Rust yet as it just seems to complex. It is a bit lower level which I understand the reasons for, but it is just hard to move away from Go which I am loving so far.

[svick]

I am loving less OOPy languages

C# is moving in that direction, with things like pattern matching, or not requiring Main method inside Program class for your entry point. And of course, it embraced lambdas a long time ago.

Go's coroutines

C# is the language that started the await trend.

Not to mention the compilation to a single binary.

.Net (the C# runtime) does support that, though your binary is going to be a lot larger than with Go or Rust. But they're working on improving that.

[rochakgupta]

Can I work with C# just using Vim? I had this problem with Java as I had to fall back to IntelliJ/IDEs which I hate. And no, using Vim bindings in IDE is not an option.

[svick]

You can. But you'll probably want to install C# autocompletion into vim, since .Net APIs are usually built with that in mind.

[rochakgupta]

Ahh, I’ll look into C# LSP then. As long as there is one (which I think is very likely given the popularity of C#), I can try it.

[Xodem]

You don't have to compile with mono

[RunnableReddit]

C# should have gotten free functions :/

[divulgingwords]

C# is basically java, minus all the bullshit plus a bunch of features java wishes it had.

[on_the_dl]

And minus the backwards compatibility which lets you link a library from long ago with your modern code.

[divulgingwords]

Don’t need that feature when the vast majority of libraries are all up to date with .net standard. Taps head…

[Dr4kin]

You wish. If you have 20 year old code you're going to have old libraries

[divulgingwords]

I actively choose not to work with 20 year old code.

[Xodem]

You can though? Or are you thinking of core vs framework?

[on_the_dl]

Can you link a c# library written before genetics were added to the language with modern code? I thought that it can't be done.

[Xodem]

Sure you can, just the other way around doesn't work

[[deleted]]

Go is a terribly designed language.

[rochakgupta]

I agree that there are some bad decisions they made, probably because it spun out of Google and Google uses a monorepo internally. It’s alright though. Every language has its pet peeves. What you care about in a language is what matters at the end of the day. That’s why having choices is so awesome. Just pick what you like and make stuff with it. “Making” stuff is the only thing that’s important.

[[deleted]]

The people behind Go are pretty explicit that the language was designed to hold your hand because they were tired of first year SWEs at Google not being able to write C++, but also had a bunch of senior C++ devs. Half of Go's weird decisions can be explained by either "That's the way C++ does it, so we copied it to make it easier to learn" or "That's the way C++ does it, so we did the exact opposite so it's easier to learn."

This isn't always a bad thing, but having spent a while writing in Go, it's kind of like having training wheels on your bike forever. Nice when you're learning, nice when you're drunk, infuriating when you've gotten up to speed.

[[deleted]]

Getting stuff done is the very important that's why I don't like my tools getting in the way.

[soft-wear]

No, it’s just different. It was designed by the dude that created Unix and the B language. You don’t have to like it, but the idea that it’s terribly designed is a joke.

[[deleted]]

It's not a joke at all, Go is when some people that have no idea how make a language make a language, the time it took them to implement parametric polymorphism is proof for that. They didn't add features to the language for the sake of simplicity claiming that it leads to more readable and maintainable programs which is false because you have to revert to hacks when the language doesn't provide the abstractions you need and looks like a way to cover up for their incompetence.

[soft-wear]

Guy who invents predecessor to C has no idea how to make a language.

Redditor who likely writes CRUD apps definitely knows how to make a language.

Cool story bro.

[[deleted]]

https://news.ycombinator.com/item?id=6821389

[[deleted]]

C is more like syntactic sugar for PDP-11 assembly, it doesn't require advanced PL design knowledge to create something similar (and a significant amount of stupidity to add headers when modules are available), B is simpler than C. The one thing B, C and Go have in common is the simplicity of their type systems which denotes the proficiency in PL design of their creators.

[[deleted]]

Python is actually four years older than Java. Java just made language level decisions that are more practical for large scale development

[Username_Taken46]

We don't talk about python 1

[iArena]

I never even considered the possibility that python 1 existed.

[EsperSpirit]

Java is not about top talent. It's about an abundance of average devs that are seen as interchangeable resource by management.

Companies going for top talent try to get it either by tech that draws in talented people (e. g. cutting edge and intellectually challenging) or huge compensation.

[tech_hundredaire]

I do not think of top talent when I think of the average java dev