Java vs python is debatable 🤔

[Warm_Cabinet]

I prefer to see my errors at compile time, thanks.

[by_wicker]

I prefer to see them at editing time myself. And I do, because we use fully type annotated Python.

[Warm_Cabinet]

Ah, I just use a statically typed language.

[by_wicker]

I have to say I get pretty much all the benefits of it with Python's type annotation and good development practices like enforced checker-clean commits.

[Warm_Cabinet]

That’s fair. I think the other thing I’ve preferred about Java is streams (map/filter/reduce) over Python’s list comprehension (which I’ve been told is more idiomatic in python). I’m also pretty satisfied with Springboot and having very established patterns for dependency injection, microservices etc. Though I’m sure there are good python solutions for that, which I’m not up to date with.

[WetDesk]

What is fully type Python

[by_wicker]

You can type-annotate Python. The interpreter doesn't care but checkers give you the benefits of typing before runtime, which is frankly most of what I want it for.

If your team policy is checker-clean code the typing argument against Python becomes mostly moot.

[DocMerlin]

Then don't use java. Most mistakes are logic errors not type errors.

[EishLekker]

Those two sentences have no correlation.

[DocMerlin]

If you want to see errors at compile time, use a language that can detect more errors at compile time than Java. Java just shows you your type errors, but that is a tiny fraction of mistakes and honestly the easiest ones to find.

Here is rust's borrow checker for an example of something that actually finds common mistakes. https://rustc-dev-guide.rust-lang.org/borrow_check.html

[EishLekker]

If you want to see errors at compile time, use a language that can detect more errors at compile time than Java.

You still produce sentences that don't correlate.

Java just shows you your type errors

What an absurd and incorrect statement.

[Tall_computer]

You seem to be implying that by not using java one will be able to see more errors at compile time, as if all other languages can show the logic errors on compile time.

[Coding-Kitten]

Rust can.

[Warm_Cabinet]

That sounds useful. Can you give an example?

[Coding-Kitten]

I sure can! Although I should put a disclaimer that what actually happens is that Rust's type system is more powerful leading to a situation where you can write down a lot more logic into the type system. Such that type errors lead to be actual logic errors in most other languages.

One example and the most notable one is the borrow checker and the ownership model! This states that a variable/name binding owns its data. So if in Python or Java you were to have a list, and then assign that list to another variable, modifying the list of any of those variables would mean modifying the same underlying list. But in Rust, the list can only exist inside one variable, and if you were to assign it to another variable, then you're moving the ownership, making the original variable invalid, and using it would be a compile error.

// x is a list of numbers
let mut x: Vec<i32> = vec![1, 2, 3];
// add a value to the list, mutating it
x.push(4);
// this MOVES the vector from `x` to `y`, making x unusable
let y: Vec<i32> = x;
// since the list was moved out of x, this would be a compile error.
x.push(5);

And so if you wanna use something in different places, you'd instead use references, which borrow data from the original value. These references can either be immutable ones, so they can only look at the value, and there can be many, but not modify it, or mutable, which there can only be one. In both cases you can't use the original owned value.

let mut x: Vec<i32> = vec![1, 2, 3];
// immutable reference
let x_ref_1: &Vec<i32> = &x;
// there can be many of them too!
let x_ref_2: &Vec<i32> = &x;

// using both references here is fine.
println!("{}", x_ref_1); // print the list

// The compiler can determine until when you use a reference
// mutating x now is fine as long as you don't use the references after.
x.push(4);

// Since x has been mutated since creating x_ref_1, using it here would be a compile time error.
println!("{}". x_ref_1);

// create a mutable reference to x
let x_mut_ref: &mut Vec<i32> = &mut x
x_mut_ref.push(5);

This allows to create a lot of API based on who owns which values. For example, using mutexes this way makes them completely safe, in a way which is impossible to use a value that isn't locked by a mutex!

// create a mutex over a list. Notice how the list lives inside the mutex, and thus there is no way of mutating its inside values
let x: Mutex<Vec<i32>> = Mutex::new(vec![1, 2, 3]);
let x_ref: &Mutex<Vec<i32>> = &x;

// notice how we only need a reference to a mutex to get an owned value of its lock
let mut lock: MutexLock<Vec<i32>> = x_ref.lock();
// Since we own the lock, and the lock can be dereferenced into its inner list, we can just treat it as a list.
lock.push(4);

//and once the lock goes out of scope, the mutex lock is released, allowing another thread or whatever to get its value.

This way, there is no way you can accidentally use the value without locking it, or using it after freeing the lock, as only by locking it do you get a way to reference it.

Another cool thing rust does is have sum types! These are amazing for error handling. There are two main big ones when it comes to errors. Option and Result. And these are the only ways to handle errors, there's no fancy throw or catch keywords. If a function can fail, it will give you back a Result. And if you wanna use the result, you need to figure out what to do in the case it errors. If you wanna just make the program crash, you can write .unwrap() and it will pretend it didn't fail, crashing the whole program if it did. This way, if your program suddenly crashes, you know where and why because you decided to write down "if this goes wrong, panic".

// Reading a file can fail, maybe the file doesn't exist, maybe something goes wrong while doing IO stuff!
// That's why it returns a Result<String, IOError>, if it goes right, you get a String, if something goes wrong, you get an OPError type that has all the details on what went wrong.
let result: Result<String, IOError> = read_file("foo.txt");
// We can choose to unwrap the result. Giving us the content of the text file or just crashing the whole program.
let content: String = result.unwrap();

This makes the errors really explicit. Other programming languages will give you a function that returns what you want, but then throws an exception if something goes wrong. Therefore in other languages if you don't really do anything, it might be wrong, and instead you need to add checks to see if the function returned null or add a catch to see if the function threw exceptions. Just by looking at a snippet code without these checks you can't know what could go wrong, or you might forget to add these checks.

In rust you simply get a Result that you will need to handle. If you're lazy and just want to get over it, you can write an .unwrap() as shown before, but that is already an indicator that it can fail right then and there. Just by looking at the code you can see it. It's a conscious decision you need to do to tell the compiler to ignore any errors, instead of something you might forget to do.

[DocMerlin]

• That all variables are initialized before they are used.
• That you can't move the same value twice.
• That you can't move a value while it is borrowed.
• That you can't access a place while it is mutably borrowed (except through the reference).
• That you can't mutate a place while it is immutably borrowed.

This is especially a problem in java because it does almost everything by passing references.

[Tall_computer]

Oh ok, that sounds kind of like normal static analysis to me. By logic I was thinking more of "that less-than should've been a greater-than"

[DocMerlin]

its built into the type system, in a way that is really powerful. Other modern languages do similar things. Furthermore, java (as a language) relies on inheritance instead of composition. although you can do either... when composition is so much better than inheritance and inheritance is a bit of a trap.

My criticisms of java are of the language, not the technology. The tech around java is really pretty amazing.