I'm a long time C++ developer, and recently took a job where I write a lot of Python in a large code base. Initially it seemed great, but I quickly realized how uncomfortable it is to have no safety net up front. The interesting thing is Python eliminates a lot of programming errors you may encounter in C++. But it introduces a whole different set of programming errors you would never see in C++. I don't feel comfortable using Python for any project where the code must be correct. I would use Rust every time for that.
On Learning Rust and Go: Migrating Away from Python
241–250 of 346 posts
Re: On Learning Rust and Go: Migrating Away from Python
#242Earlier quoted context omitted.
> The claim is that LLVM is slow, so it's not Rust's fault. I never claimed this. I claimed that there are a number of interlocking issues that make Rust compilation slow, and pointed out one that I haven’t seen a ton of discussion about before as an example of how it’s not a simple problem. I also started this conversation by acknowledging one of the things that you said, which was that we generate a lot of LLVM-IR.…
> I never claimed this. No, the person I first replied to did. Then you jumped in and defended his position with your "yes and no" comment. > I don’t think we’re really gonna make any progress here so I’ll leave it at that. I agree. I always appreciate your friendliness and thoughtfulness, but I've never gotten you or anyone else on the Rust team to budge an inch on the problems with Rust. (which is a shame, because…
I was replying to just you, not defending them.
It seems we’re in full agreement about the problems: compile times are too slow! Everyone acknowledges this. It seems like our disagreement is about the why.
Re: On Learning Rust and Go: Migrating Away from Python
#243Earlier quoted context omitted.
See the details here about his project that he maintained in Python for years (since 2006) in Python: https://blog.liw.fi/posts/2017/08/13/retiring_obnam/ I can really understand his: "Obnam has not turned out well, from a maintainability point of view. It seems that every time I try to fix something, I break something else. Usually what breaks is speed or memory use: Obnam gets slower or starts using even more memor…
Even on larger code bases I've found that the only real discipline needed is maintaining a test suite, and that's true for every language.
https://github.com/lukipuki/obnam/blob/master/obnamlib/bag_s...
https://github.com/lukipuki/obnam/blob/master/obnamlib/blob_...
https://github.com/lukipuki/obnam/blob/master/obnamlib/chunk...
https://github.com/lukipuki/obnam/blob/master/obnamlib/encry...
https://github.com/lukipuki/obnam/blob/master/obnamlib/forge...
https://github.com/lukipuki/obnam/blob/master/obnamlib/hooks...
https://github.com/lukipuki/obnam/blob/master/obnamlib/lockm...
https://github.com/lukipuki/obnam/blob/master/obnamlib/metad...
https://github.com/lukipuki/obnam/blob/master/obnamlib/obj_s...
https://github.com/lukipuki/obnam/blob/master/obnamlib/pathn...
https://github.com/lukipuki/obnam/blob/master/obnamlib/plugi...
https://github.com/lukipuki/obnam/blob/master/obnamlib/repo_...
https://github.com/lukipuki/obnam/blob/master/obnamlib/sizep...
https://github.com/lukipuki/obnam/blob/master/obnamlib/split...
https://github.com/lukipuki/obnam/blob/master/obnamlib/struc...
https://github.com/lukipuki/obnam/blob/master/obnamlib/vfs_l...
Re: On Learning Rust and Go: Migrating Away from Python
#244I'm currently migrating a similarly sized Python and Django application to Go but for different reasons. For me it's bit rot. My Python is approaching EOL on this version and needs upgrading to Python 3, and I have a lot of 3rd party code in here that made things simpler to create but over time they've changed enough or disappeared that I now have to take on work there too. Then Django and it's internals have changed…
I'd chose Python 3 migration and updating/removing/exchanging dependencies over rewriting in a different language I know less well any time. And good look finding replacements for Python/Django packages in Go or Rust. Don't get me wrong. You'll find a lot of libraries for those languages. But probably not everything...
> I'd chose Python 3 migration and updating/removing/exchanging dependencies over rewriting in a different language
They explicitly said they don't want to rewrite. It looks like they have some existing projects in Go that work in a self-contained way and upgrade with minimal effort.
Re: On Learning Rust and Go: Migrating Away from Python
#245Strongly agree with author. I really like Python and at one point thought that it makes sense to write almost any project in it, since it's so versatile and I know it pretty well. After working on a quite large application and having to use lots of assert(isinstance(arg, type) at the beginning of almost every function, I began to think that a strong type system is very much needed for large projects. I believe this w…
You're confusing static typing with strong typing. Python is strongly-typed, but not statically typed. Python's optional typing could also be used to get rid of a lot of your assertions.
You are confusing optional typing with optional static typechecking. Python has the latter, not the former. In other words, everything is typed in Python and it will always check types at runtime.
Re: On Learning Rust and Go: Migrating Away from Python
#246Earlier quoted context omitted.
“15k would be a delight”, implies that 250-300k is not a delight. It sounds like your loss of interest may be correlated with your level of discomfort with increased cognitive load.... the alternative explanation would be strange: you can only be interested in simpler problems/implementations. (Which I doubt)
No, it’s nothing to do with the cognitive load. And I said nothing about discomfort. That’s a pretty interesting interpretation you’ve drawn. I build things from scratch. By the time a project hits that size, I’m utterly bored with it. It’s been figured out and built. It’s been refactored. It’s been tuned in places that need performance improvement. It’s had new features added in. But fundamentally, the idea(s) behin…
LOC is a very bad estimator of complexity. There isn't a need write 100K LOC to figure out "the problem space" either.
Re: On Learning Rust and Go: Migrating Away from Python
#247I'm a long time C++ developer, and recently took a job where I write a lot of Python in a large code base. Initially it seemed great, but I quickly realized how uncomfortable it is to have no safety net up front. The interesting thing is Python eliminates a lot of programming errors you may encounter in C++. But it introduces a whole different set of programming errors you would never see in C++. I don't feel comfort…
Neither Rust nor C++ eliminate logic bugs (and no language can do that).
If you are writing code that must work, you should be either formally prove the system (if feasible) or have a huge test suite covering everything.
Re: On Learning Rust and Go: Migrating Away from Python
#248Earlier quoted context omitted.
These two stuck out as well. I wonder if the issue is with their coding practices and not necessarily a fault with the language. If the issue is one of fundamentals it will only follow them to the next project or language
Are you making that comment by speculating or by having looked at the Obnam codebase? I'm not a Python developer, but I've looked at the Obnam code enough to have written a replacement crypto plugin for it. AFAICT, if Obnam was holding Python wrong, it's too hard to hold it right.
I haven’t looked at the code, but I hope someone who has been using Python for 20+ years knows how to write and use it properly... so yeah, I’m inclined to agree with you.
Re: On Learning Rust and Go: Migrating Away from Python
#249Earlier quoted context omitted.
In all three cases, Python, Go and Rust, the language and ecosystem may be in the hands of an organization, but you can probably produce code productively in it for years even if the organization went under or chose unacceptable paths. Go is quite unique in that it produces very independent binaries. This might make software written in it quite future-proof. Personally I like Python's philosophy and the way the commu…
I think a “rust with GC” could actually be a very good intro language. The borrow checker is more than beginners can handle though.
There is little point to introduce a GC in Rust. If you don't mind a GC, you have nicer languages out there.
Re: On Learning Rust and Go: Migrating Away from Python
#250Having used all three of those languages, I've commented on this before.
Go is mediocre as a a language, but it has one big edge - if you're doing web backend stuff, the libraries for that are the ones used internally by Google. So they're being executed billions of times per second on Google servers and tend to be well behaved. Python tends to have multiple libraries for basic functions like the database interface, all with different bugs. If you write web backend stuff in Go, it will probably work.
Having suffered through the Python 2 to 3 transition, I'm less of a Python fan than I used to be. At some point, they need to stop adding features. Currently, Python is acquiring unchecked "type hints", which look like a terrible idea. Optional typing, sure, but unchecked type hints? If the compiler enforced them, they might be worth something. (And no, running a separate type checking tool is not the answer. Especially since no such tool exists that's production grade and in sync with the language.)
Rust has no idea when to stop adding features. Rust started as an imperative language and then morphed into a semi-functional language. Mostly to get a sane error handling model. The borrow checker was a brilliant innovation, though. I used Rust for a while, but quit about two years ago in disgust. I never want to hear "that only compiles in nightly" again.