Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Learning Rust and Go: Migrating Away from Python

blog.liw.fi

Post reply on HN
Print view View original

11–20 of 346 posts

Re: On Learning Rust and Go: Migrating Away from Python

#11

Post by codetrotter »

jMyles wrote: post #4
fxj wrote: post #2

After 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…

I largely agree with what you said but

> there's nothing lingual about python that stops it from being compiled

Are you sure? Python is a very dynamic language. Some of the most dynamic parts of python might not be possible to compile fully ahead of time and might need to be JITed, because the behavior of the code will only be possible to determine at runtime.

Re: On Learning Rust and Go: Migrating Away from Python

#12

Post by dcuthbertson »

fxj wrote: post #2

After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.

Maybe I'm picking nits, but the author is comparing programming experiences in each of those languages, which is perfectly valid. For example, last year I was part of a team that rewrote a very large Node.js program (several hundred thousand lines of code) in Go. The differences in following control flow and in the edit-build-test loop are like night and day.

We've found Go meets our needs better than Node.js for writing and debugging large programs. The languages are very different. Both are used for small and large programs. The experience in using them is what makes us choose one over the other.

Re: On Learning Rust and Go: Migrating Away from Python

#13

Post by Bishonen88 »

IshKebab wrote: post #10
jacquesm wrote: post #8

15Kloc 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.

Most of the above is due to a proper IDE. Python, too, has one: PyCharm. Comes with 'find usage of variables', 'jump to definition', types checking, syntax correction, import optimization and much much more. 15k with pycharm is a walk in a park

\*More than one, of course. But I use only PyCharm :)

Re: On Learning Rust and Go: Migrating Away from Python

#15

Post by AsyncAwait »

kumarvvr wrote: post #7

At 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?

That maybe your personal opinion is not an objective fact?

Re: On Learning Rust and Go: Migrating Away from Python

#16

Post by julienfr112 »

Line of code is a relative measure. If you leverage package like numpy/pandas, asyncio and co, you could easily write python code that are ten fold shorter than their C/rust/go equivalent. And improving speed when you make a good use of numpy requires quite an amount of time and skills.

Re: On Learning Rust and Go: Migrating Away from Python

#17

Post by mateuszf »

Bishonen88 wrote: post #13
IshKebab wrote: post #10

Earlier quoted context omitted.

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.

Most of the above is due to a proper IDE. Python, too, has one : PyCharm. Comes with 'find usage of variables', 'jump to definition', types checking, syntax correction, import optimization and much much more. 15k with pycharm is a walk in a park \ *More than one, of course. But I use only PyCharm :)

It depends on the language. The more metaprogramming is used the harder to automatically refactor.

While you can do reflection/code generation even in Java, for the non-framework code almost nobody does it.

That's why I feel lot safer with large codebases in Java, even though I love some dynamic languages too. I don't think they're as scalable for big programs though.

Re: On Learning Rust and Go: Migrating Away from Python

#18

Post by pushpop »

jacquesm wrote: post #9
kumarvvr wrote: post #7

At 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).

It’s not just about code organisation though. Both Rust and Go have fantastic compilers which catch a great many dumb but common user errors before you even get to the stage of testing.

Obviously this doesn’t replace the need for functional tests but writing those tests is as much prone to user error as writing the code itself. So having a compiler check for stupidity up front is always going to be a bonus.

Also the static type system helps a lot too. Having dynamic types can be awfully convenient at times and I completely relate to why some people like them but static types means your structures and classes effectively have written specifications defined in the code itself which the compiler verifies the rest of your program against. So if you’re accidentally trying to write text to a numeric type, your compiler will catch that.

In my experience the extra up front overhead (in terms of development time) of static typed AOT compiled languages end up saving you development time in the long run when working against larger projects.

Re: On Learning Rust and Go: Migrating Away from Python

#19

Post by pytester »

jacquesm wrote: post #8

15Kloc 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…

From glancing at the obnam code it looks relatively okay: https://github.com/lukipuki/obnam/tree/master/obnamlib

The one thing that stands out to me is that it's heavy on the unit tests and light on integration tests which would make an application like this (at least for me) more difficult to handle. I'd go heavier on integration testing and lighter on unit testing.

Re: On Learning Rust and Go: Migrating Away from Python

#20

Post by nurettin »

pushpop wrote: post #18
jacquesm wrote: post #9

Earlier quoted context omitted.

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).

It’s not just about code organisation though. Both Rust and Go have fantastic compilers which catch a great many dumb but common user errors before you even get to the stage of testing. Obviously this doesn’t replace the need for functional tests but writing those tests is as much prone to user error as writing the code itself. So having a compiler check for stupidity up front is always going to be a bonus. Also the…

Mypy and type hints does catch that.
Post reply on HN