Live data from Hacker News

On Learning Rust and Go: Migrating Away from Python

blog.liw.fi

31–40 of 346 posts

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

#31
post #18

Earlier quoted context omitted.

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…

>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, if I'm writing…

Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situations when test coverage was good but a basic type check seemed so obvious it was forgotten to be added. Some of those tests wouldn’t even have been needed in Rust or Go.

I do agree that tests are important; hence why I raised that point from the outset. But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust. Which is the point I was raising. Go and Rust are better at catching stupid user error.

Clearly though you can write large projects in Python if you’re disciplined enough. Same could be said for C, BBC BASIC or even assembly. The question isn’t whether you can, it’s whether other languages makes it easier or not.

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

#32
I'm going to have a go with Rust and Go too, but for different reasons.

IMO Python is still the best language to go with when you are writing anything "scripty":

- Stuff that's not expected to be long. Do one thing well, let some other program do another, compose the higher order functions from functions that work. Of course this isn't always possible.

- Stuff where the types are not going to confuse you. Often you just have a few types, and it's fairly obvious what you can do with a given object. If you get too many types, there's a good chance it will start to get confusing and then strong typing would help.

- Stuff where performance is not a problem. Don't write your HFT system in Python. You simulation though, might benefit from orchestration of some VMs.

The ultimate use case for Python is glue code. And guess what, a lot of code is just glue. A good glue language has a large ecosystem of libs, and some language features that make it easy to read. That's Python in a nutshell: whitespace formatting makes things easy to read, and you get built in list/dict syntax to keep everything short and sweet.

For me Rust and Go are interesting having come from C++. There's a lot of pitfalls in C++ that might be helped with Rust. At the moment I have a whole load of Valgrind suite tests that look for potential problems. Perhaps Rust can bake those into the language? I haven't had time to look at it yet.

Go seems to be interesting as a compromise between easy and fast, and by the sound of it things have turned out well. I have people on my team using it, and it seems to be the thing to do for web services that need to be faster than nodejs but you don't want to spend a load of time making sure a c++ version is correct.

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

#33
post #24

The strengths of Go become apparent when working in teams and when deploying, not when reading blogs about the language before trying to write code in it.

Exactly this.

Rust is quite the opposite of Go in that regard - just like C or C++, it makes it really easy to write over-abstracted and clever code that is hard to understand, audit or review.

Rust is also an extremely powerful tool and a ray of hope for systems programming, but comparing it to Go is an apples and oranges comparison.

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

#34
post #30

> Note that I've not written any significant code in either language, so I'm just writing based on what I've learnt by reading. So he’s basically comparing 20+ years of Python usage with marketing material from Go and Rust. Right. I wish people could be honest with their motivations, instead of making up excuses to justify this sort of change. Here it’s a classic case of “I got bored and I don’t like the new features…

> Here it’s a classic case of “I got bored and I don’t like the new features, want new shiny”, wrapped in a bit of whining

This seems to be a rather shallow reading of the blogpost, and the way you phrased your reaction is not exactly polite either. If anything, the "adoption rates" of Python (like those of ECMAscript, a language of a similar vintage all-things-considered) are most easily explained by non-technical factors, so I have quite a bit of trouble making sense of your comment.

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

#35
I'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 a lot in the last 6 years.

My Go code written at the same time (6+ years ago) hasn't had any of it's libraries change so much that I've needed to do anything. Every now and then I pull the next major version of Go and recompile and it's done.

This is all side project stuff but a lot of people use it (monthly average visitors being +250k)... it's non-profit and I don't wish to have to maintain it much.

It worked once, if nothing has changed in the functionality it should keep working... but this isn't as true in non-compiled languages where you need to depend on so much of the environment, let alone build culture that doesn't fully vendor dependencies.

I like Python, but prefer to write code and move forward with other projects.

As to Rust vs Go. I code in both and only picked Go here because a lot of the code in another project I worked on can be used here. I'd probably try Rust if I was starting from scratch now. But I'd be a little concerned bit rot would affect Rust too, it's still quite early for the wider ecosystem.

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

#36

I'm going to have a go with Rust and Go too, but for different reasons. IMO Python is still the best language to go with when you are writing anything "scripty": - Stuff that's not expected to be long. Do one thing well, let some other program do another, compose the higher order functions from functions that work. Of course this isn't always possible. - Stuff where the types are not going to confuse you. Often you j…

C++ versions are never correct

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

#37
post #30

> Note that I've not written any significant code in either language, so I'm just writing based on what I've learnt by reading. So he’s basically comparing 20+ years of Python usage with marketing material from Go and Rust. Right. I wish people could be honest with their motivations, instead of making up excuses to justify this sort of change. Here it’s a classic case of “I got bored and I don’t like the new features…

Perhaps there should be apostasy punishments for Python defectors. /s

Python's typing story is far from perfect and rather annoying compared to other languages. Python is good for interacting with the operating system, networking and other things.

But wanting a proper compiler is an honest motivation.

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

#38
post #31

Earlier quoted context omitted.

>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, if I'm writing…

Like I said, tests are also subject to user error. I’ve seen scenarios where tests passed when they shouldn’t have because the test itself was wrong. Or situations when test coverage was good but a basic type check seemed so obvious it was forgotten to be added. Some of those tests wouldn’t even have been needed in Rust or Go. I do agree that tests are important; hence why I raised that point from the outset. But ult…

>But ultimately in Python you’re still having to add extra tests just to catch up with the default behaviour of Go and Rust.

You don't though. The tests you'd write which would catch these "stupid user errors" are basic ones which you'd be remiss not to write in any language.

The fact that frequently developers do choose not to write any tests at all on large code bases does mean that they start to rely heavily on compiler catching 'stupid user errors' but it doesn't have to be that way.

>Go and Rust are better at catching stupid user error.

...if you don't have a basic level of tests, yes.

(although rust does provide certain type level protection against, say, data race bugs which python doesn't).

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

#39
post #18
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…

Statically typed languages are more robust, as far as reducing errors is concerned.However, with modern static type checking tooling in Python, for small to medium sized programs, pythons benefits far outweigh its shortcomings.
Post reply on HN