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

41–50 of 346 posts

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

#41

Post by pushpop »

kumarvvr wrote: post #39
pushpop wrote: 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…

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.

I’ve already addressed that point elsewhere in this thread

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

#42

Post by empath75 »

toyg wrote: 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…

Type checking as an add-on is okay but it is not the same thing as a statically typed language.

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

#43

Post by ris »

buro9 wrote: post #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…

What you're actually saying here is "Using Go I'm going to leave the application with unmaintained versions of its libraries", which is a bit of an alarm-bells statement from a security point of view.

It's perfectly possible to build a python application that is extremely reliably tied to its dependencies, you just have to avoid the default python package "management" solutions that get shoved down everyone's throat (pip, virtualenv, pipfile, tox and the like). I've been building python projects on top of Nix for years and have managed to maintain stable and reliable results.

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

#44

Post by empath75 »

ChrisSD wrote: post #40

This is more of a general observation but why are Rust and Go so often mentioned in the same sentence? They are designed around very different use cases such that a direct comparison doesn't seem to warrant as much attention as it seems to get.

They’re different use-cases but they’re both modern statically typed languages that are ergonomically nice compared to previous alternatives in their spaces.

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

#45

Post by ris »

LawnboyMax wrote: post #28

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

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

#46

Post by pushpop »

pytester wrote: post #38
pushpop wrote: post #31

Earlier quoted context omitted.

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

You’re flip flopping all over the place with your descriptions of tests. Broadly speaking, There are two types of tests being discussed here. Those are positive tests and negative tests.

Positive being that the code does what you expect under normal operation. Those you’d obviously need in any language

Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in. If your compiler flat out refuses to send a string type to a function that is designed to accept an integer then you’re already covering a whole class of bugs without needing to write specific tests for it.

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

#47

Post by empath75 »

ris wrote: post #43
buro9 wrote: post #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…

What you're actually saying here is "Using Go I'm going to leave the application with unmaintained versions of its libraries", which is a bit of an alarm-bells statement from a security point of view. It's perfectly possible to build a python application that is extremely reliably tied to its dependencies, you just have to avoid the default python package "management" solutions that get shoved down everyone's throat…

“It’s easy to do it if you build your own dependency management system” doesn’t sound like it’s easy to do it.

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

#48

Post by ptx »

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.

I've been doing some Java lately, and it seems to me like Java libraries are often doing (and making the programmer do) a lot of work just to get back the dynamism that Python has by default. Many kinds of errors are only detectable at runtime:

* dependency injection errors,

* template errors,

* magic annotation malfunctions, etc.

The last one in particular actually seems less safe than Python's decorator mechanism. Java splits it in two parts, so that the annotation classes used at compile time are separate from the library that will process them to actually do something. If the latter part is somehow broken, the code will just do nothing, so you don't even get a runtime error.

In Python, decorators are just functions that serve as annotations as well as doing the actual work. There is usually no separate processing part that can go missing. I've never encountered similar problems in Python.

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

#49

Post by cube2222 »

ris wrote: post #43
buro9 wrote: post #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…

What you're actually saying here is "Using Go I'm going to leave the application with unmaintained versions of its libraries", which is a bit of an alarm-bells statement from a security point of view. It's perfectly possible to build a python application that is extremely reliably tied to its dependencies, you just have to avoid the default python package "management" solutions that get shoved down everyone's throat…

No, it's really more about the ecosystem and tooling being very stable. Code you've written 6 years ago will most probably work with the current version of Go + updated libraries.

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

#50

Post by empath75 »

xyproto wrote: 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.

I’m working in a team of 5 people who has never used go prior to 9 months ago and had no training in it and we’ve just been unbelievably productive in it. We came to it from a combination of python and javascript backgrounds and have no problems collaborating or jumping into each other’s code.

To me the main advantage of it is that the small number of primitives and simple syntax forces people to in general be very explicit about what you’re doing. The code almost doesn’t need comments.

Post reply on HN