On Learning Rust and Go: Migrating Away from Python
1–10 of 346 posts
Re: On Learning Rust and Go: Migrating Away from Python
#2After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.
Re: On Learning Rust and Go: Migrating Away from Python
#3After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.
Even if languages have different typing regimes, that does not mean that they can be compared. They are means to an end after all. Outside the language itself, you can also compare ecosystems, available tooling, etc.
For his ends, statically-typed languages have benefits over Python:
Obnam is about 15000 lines of Python code. That turned out to be too much for me in Python: too often there were bugs that a static, strong type system would have caught.
Re: On Learning Rust and Go: Migrating Away from Python
#4After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.
At a high level, I agree with what you're saying here - that it's difficult to compare rust or go with python. But I take some issue with your reasoning.
> After all python is still an interpreted scripting language.
Is it? Or rather, is this even a well-defined category?
> interpreted
Can't any (OK, almost any) language be either interpreted or compiled? The fact that python is typically run in an interpretive runtime setting doesn't really make it "interpreted" as a language. In fact, since python is nearly always compiled to byte code at runtime, it's arguable just as compiled as it is interpreted.
But that's not even the point: there's nothing lingual about python that stops it from being compiled. It can be compared with other languages that are typical run subsequent to a compilation step without being the apple to an orange.
> scripting
This one speaks to me even less. For python to properly be understood as a "scripting" language, I think you'd have to convince me that the lion's share of community energy is dedicated to a paradigm of running a single module front-to-back as a script.
And this is clearly not so.
Re: On Learning Rust and Go: Migrating Away from Python
#5After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.
I disagree. It's a language, it has symbols, syntax and conventions, it either gets interpreted or it gets compiled.
In the broad swath of languages, go and python are more similar than, say, python and Haskell.
What makes languages apples and oranges is generally not their compilation method but things that are more approach-centric or radically different syntax (which is why I left Rust out. Its syntax has been the thing that's slowed me down most there)
Re: On Learning Rust and Go: Migrating Away from Python
#6After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.
At a high level, I agree with what you're saying here - that it's difficult to compare rust or go with python. But I take some issue with your reasoning. > After all python is still an interpreted scripting language. Is it? Or rather, is this even a well-defined category? > interpreted Can't any (OK, almost any) language be either interpreted or compiled? The fact that python is typically run in an interpretive runti…
They have a historic point but you’re right that their description doesn’t make much sense given the modern way language runtimes are designed.
A better description would be “high level JIT compiled language”.
Re: On Learning Rust and Go: Migrating Away from Python
#7At 15000 loc, if the author found it difficult to organize python code, then it's not python's fault.
I find it a pleasure to organize code in python.
What am I missing here?
Re: On Learning Rust and Go: Migrating Away from Python
#815Kloc and trouble is indicative of other problems than a problem with the language. I wrote multiple 50Kloc and up pieces of software in GFA Basic, arguably a much more limiting and unsafe environment than Python ever was, and yet, that software worked well and was maintainable to the point that its descendants still run 3 decades later.
Python has all the bells and whistles you need to build large code bases, but you do need to get organized, no language can really do that for you and attempts at forcing you to do it give rise to 'factory factory' nonsense. I'm no huge fan of Python, I use it when I have to but Rust is from a bells-and-whistles point of view a step down from Python, it is more a better 'C' than a better Python and Go has it's own share of issues that has kept me away from it so far.
If you want to crank out some research project or application quickly building on the libraries that others provide (especially in machine learning or other data intensive fields) then Python would be my first choice, and something like 'R' probably my second (though I see 'R' mostly as a data scientist's workbench that has a programming language bolted on).
Re: On Learning Rust and Go: Migrating Away from Python
#9At 15000 loc, if the author found it difficult to organize python code, then it's not python's fault. I find it a pleasure to organize code in python. What am I missing here?
Exactly. 15Kloc is just out of the 'this stuff is easy' zone and switching to Rust or Go will make that problem larger, not smaller (because you will need more code to achieve the same effect).
Re: On Learning Rust and Go: Migrating Away from Python
#1015Kloc and trouble is indicative of other problems than a problem with the language. I wrote multiple 50Kloc and up pieces of software in GFA Basic, arguably a much more limiting and unsafe environment than Python ever was, and yet, that software worked well and was maintainable to the point that its descendants still run 3 decades later. Python has all the bells and whistles you need to build large code bases, but y…
I disagree. 15k lines of code is a lot of code to keep entirely in your head all at once, which is basically what you have to do if you're using a language as dynamic as Python. In static languages like Java you can easily use tools to check types are correct, find usages of variables, jump to definitions and so on. And you get compile time errors if you screw up, rather than runtime errors.