Live data from Hacker News

On Learning Rust and Go: Migrating Away from Python

blog.liw.fi

91–100 of 346 posts

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

#91

> Rust is developed by a community, and was started by Mozilla. Go development seems to be de facto controlled by Google, who originated the language. I'd rather bet my non-work future on a language that isn't controlled by a huge corporation, especially one of the main players in today's surveillance economy. Anyone else agree with this view ? Programming languages should be choosen based on technical merits, rather…

"Programming languages should be choosen based on technical merits, rather than who is behind it."

Considering the motivations of the language owner is a valid concern. Many people, for example, jumped on to HHVM as a "faster PHP". Then it started branching away from PHP[1]. Predictable, if you considered Facebook's reasons for having it.

[1] https://hhvm.com/blog/2018/09/12/end-of-php-support-future-o...

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

#92
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…

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 memory."

Also from his current post:

"I could perhaps have been more diligent in how I used Python, and more careful in how I structured my code, but that's my point: a language like Python requires so much self-discipline that at some point it gets too much."

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

#93
post #46

Earlier quoted context omitted.

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

>You’re flip flopping all over the place with your descriptions of tests.

The straw man of my argument living in your head flip flopped. I did no such thing.

When I said "basic tests" I meant demonstrate the behavior under normal circumstances". If you're doing TDD on 60% of your code base you'll write enough of these.

>Negative tests are, amongst other things, checking that your functions behave correctly when you put garbage in.

This is a completely unsuitable use case for a test. If your function expects non-garbage it should raise an exception if it gets garbage with a sanity check.

I wrote one just a few hours ago like so:

    assert no_nans(dataframe)

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

#94
For me I think it comes down to what is the right tool for the job. I have been using Python for years for web scraping & data analysis (via Scrapy and SciPy) and I feel that they are the best tools for what I am doing.

Now that a lot of my scraping needs require me to render the DOM, I have had to run a headless web browser (previously PhantomJS/Splash and now Chrome). Chrome released the Puppeteer library which is the most straight forward way to interact with Headless Chrome. This is in Node so that is what i’m using.

On my last project we needed to parse through a large amount of HTML files to extract relevant information (about 70,000,000) and put it in a DB for further analyses. I have done similar things in Python before, but there are blocking/concurrency issues that can make it slow and frustrating to build.

My solution was to just do this in Go. I can then run my extraction in a goroutine. Go’s selling point for me was speed (relative to Python) and dead simple concurrency - which made it the right tool for the job.

Edit: Spelling, iOS’s autocorrect can be so annoying sometimes :)

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

#95
post #90

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…

> assert(isinstance(arg, type)) The most irritating thing I've found is trying to write a function that accepts either a path or the raw contents of a file. Python 3 makes this easy, you can check against string. Python 2 of course treats everything as a byte string. In the end I just check the length of the input if the interpret identifies as python 2. If it's a short byte string, I assume it's a file name. Otherwi…

Why would you ever do that? Why would you even want a function that accepts either a file name or file contents when both are strings? What's so hard about defining a new function?

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

#96
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.

> 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

...you're doing it wrong.

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

#97
post #76

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…

There is one and only one language that's both correct and the best tool for scripting: Bourne or its superset the Korn shell (not even bash).

You probably mean the POSIX shell [1] ;) I never understood why folks venture into bashisms for no or little gain (bash isn't even the default shell on Debian/Devuan), or would invent/use entire new languages with singleton implementations such as Perl in the 1990s or Python in the 2000s (other than for fun, of course).

Note that Python is actually a descendant of the ABC programming language developed to be human-friendly, not a shell replacement language per se.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

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

#98

For me I think it comes down to what is the right tool for the job. I have been using Python for years for web scraping & data analysis (via Scrapy and SciPy) and I feel that they are the best tools for what I am doing. Now that a lot of my scraping needs require me to render the DOM, I have had to run a headless web browser (previously PhantomJS/Splash and now Chrome). Chrome released the Puppeteer library which is…

> parse through a large amount of HTML files to extract relevant information.

Any idea if Go has an equivalent to Pythons Beautiful Soup? :)

Back when I used to do Python development, Beautiful Soup was awesome for extracting info from possibly-munged HTML. Haven't yet found a good equivalent for Go. :/

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

#99
post #83

Earlier quoted context omitted.

> I began to think that a strong type system You’re confusing static/dynamic and strong/weak. Python is a strongly typed language, but also is dynamicly typed language. Need proof? Try doing this: a = 3 b = “3” c = a + b > having to use lots of assert(isinstance(arg, type)) Python has type hinting now, try using a current version of Python and this isn’t needed.

I think that example shows that Python's type system isn't the weakest out there, but it's still pretty weak. For example, it doesn't have a built-in way to make a dictionary-whose-keys-must-be-integers (so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None). I've often seen learners have trouble with this sort of thing (you read a number fro…

> so with your example above if you wrote thedictionary.get(b) rather than thedictionary.get(a) you'd get an error rather than None

Technically, dict.get() returns None if the item isn't found and you don't provide a different value for its default.

thedictionary[b] would throw a KeyError on the other hand.

One could always subclass dict if they wanted to ensure the keys were always integers or whatever.

> I've often seen learners have trouble with this sort of thing (you read a number from a file, neglect to call int(), and get mysterious lookup failures).

Not sure if you're arguing for a stronger type system or having the language promote the string to an int as (I've heard) other scripting languages do.

Though, once you figure out the language doesn't automagically parse files for you you're well on the way to finding more fun and exciting ways to get python to throw error messages at you.

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

#100
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've worked on a 100kloc statically-typed project yet I can definitely see how static typing helps even with a much smaller code-base: I can't write a thousand line of JavaScript without encountering at least one “undefined is not a function” or equivalent error. Call me a bad programmer if you want, but I do find static typing helpful (and Rust's one is really good compared to say Java, C# or Go).
Post reply on HN