Why I can't set what parameters are mutable explicitly?

[Dan_Micsa]

@Elrod

Rust does it even better. From this call site, can you guess which is a mutable borrow, which is immutable, and which is passed by value (which gives ownership in Rust, invalidating it in this scope):
foo(&mut x, &y, z)

Yes this is what I like more in Rust vs C++ too. Everything is const for peace of mind and ‘&’ and mut are used to specify how is passed and used each thing. A bit simpler than C++ but achieving the same effect. Things are much rarer mutable than const. It will be so much clearer if Julia would follow such a convention.

[DNF]

@Dan_Micsa

Please instead of NO give an example when the declared variable has no type.

You don’t declare variables in Julia. You just assign values. So here:

function foo()
    x = 3
    println(x)
    x = "Hello"  # this works, since the variable x has no type. It is just a name.
    println(x)
end

julia> foo()
3
Hello

x is just a label that you use to refer to a value. It has no inherent type.

@Dan_Micsa

I think you are a bit confused by the “dynamic” buzzed word.

I am not using “dynamic” as a buzzword, but as a technical definition. C and C++ are statically typed, Julia, Python etc. are dynamically typed.

[Dan_Micsa]

Ah x=3 “uses” a Int64 type after that x=“Hello” “uses” a String type. TYVM for helping me. Just insert a typeof(x) after each “use” of x= and you’ll see the type_of that variable at that momment in time.

Do you see that even you can find the answer to this?

I dared to extend a bit your own example to make it more clearer:

g(v::Int64)=println("I'm called with an Int64 type!")
g(v::String)=println("I'm called with a String type!")

function foo()
    x = 3
    println(typeof(x))
    g(x)
    println(x)
    x = "Hello"  # this works, since the variable x has no type. It is just a name.
    println(typeof(x))
    g(x)
    println(x)
end

foo()

Output:
Int64   
I'm called with an Int64 type!
3
String
I'm called with a String type!
Hello

[lmiq]

Can we revive this comment? I think the path possible to Julia is more or less non-controversial, though not easy:

Comparison of Rust to Julia for scientific computing?

This is really my hope too. Julia still has a number of unresolved tradeoffs, but they are not inherent any more than the performance/productivity tradeoff that Julia has already shattered are. They may be fixable but they are not easy to fix. The first tradeoff that Julia really needs to tackle is the JIT latency one. Lots of work has been done here but I think what will really “fix” it will be having a tiered JIT where an interpreted version of code starts executing immediately until a fast …

[DNF]

I don’t have the time to keep hammering this point in. Perhaps this StackOverflow answer by Stefan Karpinski (one of the Julia language creators) types - Is Julia dynamically typed? - Stack Overflow can clarify some concepts.

It contains this sentence which may pique your interest:

Julia is squarely in the dynamic camp: types are a property of values not expressions.

There is also this previous discussion thread: Explicit denotation of variability and immutability (perhaps this post is of particular interest: Explicit denotation of variability and immutability - #16 by StefanKarpinski)

Good luck.

[Dan_Micsa]

Is a lot of work done to make it faster, to compile standalone executables, to use less memory. Essential things for success. Watch some JuliaCon 2022 are a lot of presentations regarding this. This issue with very adhoc way of address constantness similarly poor with Python can be a serios problem too. Derivation from concrete types can be a serious issue too for many types of applications that requires OOP behaviour, CAD, GUI, edtors, spreadsheets.

I still hope it will become an important language.

[Dan_Micsa]

ty for not having time. Again the fabulous word “dynamic” is used. If you want we call every language “dynamic” if makes you happy of corse calling them “dynamic” doesn’t have anything with the initial problem: “At each momment in time every declared variable in Julia has a well known type that you can query with typeof().” Is just another irrelevant link that adds noise to the problem that we discuss.

P.S. I’m still waiting a simple example that exemplify the “dynamism” of Julia and the fantomatic unknown types when variables are declared.

[dlakelan]

@Dan_Micsa

At each momment in time every declared variable in Julia has a well known type that you can query with typeof().”

At runtime whereas every type of every variable is known to g++ before the program is even built much less executed.

g++ can give you error messages before the program runs… Julia can not always do that.

It’s like me asking you to prove x+1 > 0 by looking at the expression… A static language can use the additional information that x is a positive integer… A dynamic language has to say things like "if the user passes me a positive integer this will be true, if the user passes me a complex number this will be meaningless and I need to throw an error because complex numbers are not ordered… Let’s run the program and find out what happens!

[DNF]

@Dan_Micsa

Again the fabulous word “dynamic” is used.

If you don’t believe dynamic typing exists and is just a buzzword, then I am not equipped to debate that with you. I’ll just note that the linked stackoverflow question is specifically about whether Julia is a dynamic language. It’s actually called “Is Julia dynamically typed?”

The other link is to a discussion called “Explicit denotation of variability and immutability”. If these are irrelevant noise, then I cannot imagine what would be relevant to you.

Edited: Lastly: due to your tone, I no longer wish to take part in this discussion.

I’m out.

[mbauman]

OK, this is well below the level of discourse we seek to have here (and has been for some time). I’ve closed this thread.

It’s definitely always okay to discuss what dynamic typing means in the context of Julia as compared to other languages. But everyone in the discussion needs to be respectful and agreeable, even in the disagreement.