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

271–280 of 346 posts

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

#271

Post by atombender »

tomjakubowski wrote: post #262
Animats wrote: post #250

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

> Rust has no idea when to stop adding features. > 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. I don't understand how you can reconcile these beliefs. They stabilized too many features, but you also want more nightly-only features to be stabilized? It's my experience as a Rust programmer since pre-1.0 that very few libraries require nig…

I suspect what OP is referring to is the fact that it's just hard to avoid Nightly entirely, even if you don't need the new features.

All it takes is that one library you want to use requires Nightly. Since Rust adds features all the time, it's not uncommon for library authors to start using these features before they're in Stable. It's just the nature of a young language with an active community who likes being on the bleeding edge.

This also extends to the toolchain; it's not that long ago that RLS and Rustfmt were still Nightly-only, for example.

The presence of Nightly alone gives you a choice that usually doesn't exist with other languages. Not too long ago I went down the rabbit hole with some text stream stuff (Unicode is surprisingly poorly supported in places), and ended up with a temporary workaround because the std::io::Chars API wasn't in Stable yet and I just didn't want to deal with Nightly. But it was tempting. With other languages such as Go, the choice generally isn't there, even though you could theoretically download HEAD and go from there.

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

#272

Post by IshKebab »

nnq wrote: post #96
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.

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

No I'm not.

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

#273

Post by dwaltrip »

siteshwar wrote: post #54

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

One should evaluate all relevant characteristics, both technical and non-technical.

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

#274

Post by burntsushi »

atombender wrote: post #271
tomjakubowski wrote: post #262

Earlier quoted context omitted.

> Rust has no idea when to stop adding features. > 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. I don't understand how you can reconcile these beliefs. They stabilized too many features, but you also want more nightly-only features to be stabilized? It's my experience as a Rust programmer since pre-1.0 that very few libraries require nig…

I suspect what OP is referring to is the fact that it's just hard to avoid Nightly entirely, even if you don't need the new features. All it takes is that one library you want to use requires Nightly. Since Rust adds features all the time, it's not uncommon for library authors to start using these features before they're in Stable. It's just the nature of a young language with an active community who likes being on t…

It's not hard to avoid nightly at all. I've been targeting stable Rust in all my applications and libraries since Rust 1.0 was released. The only exception is adding a new nightly-only feature, but always gated behind an Cargo feature.

This is a classic case of our standards of success continually moving, and that some domains are better suited to stable Rust than others. For example, if you want ergonomic async/await, then you need to use nightly. But otherwise, the number of crates needing nightly has shrunk enormously over the last few years.

> it's not uncommon for library authors to start using these features before they're in Stable

I would say this is actually pretty uncommon.

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

#275

Post by sandGorgon »

AsyncAwait wrote: post #170
mylons wrote: post #139

Earlier quoted context omitted.

i’ve used pycharm to refactor 100k+ LOC bases. pycharm also uses the type hints that are PART OF THE LANGUAGE (aka pythonic) as of python 3.x and enforces them.

I've used Pycharm extensively in production. It's hands down the best Python IDE, but the refactoring is nowhere near as reliable as with IDEA, Golang etc. Having a static type system provides refactoring certainty that simply cannot be achieved with a dynamic language. You cannot do with heuristics what you can do with static types.

Pycharm is built on top of IDEA.

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

#276

Post by joseph8th »

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…

Not using Nix but there have been a few libs I've "pinned" in our remote agent by the expediency of simply including the package source wholesale in our app root. Currently just an old version of PySNMP, but there were others before recent upgrades to cx_Freeze. No doubt there were other approaches, but this one is foolproof.

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

#277

Post by dkersten »

killaken2000 wrote: post #141
acqq wrote: post #92

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

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

Languages encourage various ways or styles of solving problems, though, and some of those ways require more self-discipline or care than others. For example, many languages with static types make it so that you can make sweeping changes to the interfaces between things and the compiler will catch any mismatches for you, but in a language like Python, you'd better hope you have a unit test that will catch it.

I like Python well enough, have been using it since mid-2001 and was very much a hardcore Python enthusiast for a number of years, but nowadays I prefer languages that encourage immutability and functional programming styles, as I find that they make it much easier to avoid bugs. I've had plenty of Python experiences where bugs were caused because something somewhere else was mutating stuff behind my back, messing up my mostly-unrelated code. Usually this other code was also written by someone else, so I had no way of knowing about it. This kind of thing can be prevented in other languages, but requires a lot of discipline to avoid in Python (and other languages, I'm only picking on Python here since that's the topic of the article). These problems won't follow you to the next language, if the next language is more suited to avoid them.

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

#278

Post by weberc2 »

Rotareti wrote: post #255
weberc2 wrote: post #172

Earlier quoted context omitted.

As someone who does most of their professional development in Python, I’ve been eagerly waiting for something like Mypy, but my experience with it has been really disappointing and frustrating compared to languages like Go. Mypy mostly seems immature, buggy, and completely unergonomic (typing support was shoehorned into the syntax so most things chafe—declaring a type variable or a callable that takes args and kwargs…

As someone who works full time in Python and TypeScript, I find the typing experience quite similar in both languages. You can be "productive" in both languages "in medium-to-large-sized projects". > Mypy mostly seems immature, buggy ... That was my experience some time ago as well, but it's getting better from release to release. Look at the repo [0], it's continuously improving. I find Mypy deserves more recognitio…

That’s great to hear. It’s been a while so I should go back and try it again!

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

#279

Post by wrmsr »

mlthoughts2018 wrote: post #261
throwawaymath wrote: post #257

Earlier quoted context omitted.

No it isn't? The substantive portions of the software aren't written in Python. Python is a thin interface to the actual library. Users of the library who need to rapidly prototype can leverage the library using its Python frontend, but the authors of the library did not write the library in Python.

To program in CPython is to use thin wrappers around C-level implemented extension types and modules. For example, all major built-in container types. If you program in Python for performance-critical applications, as I do, then you will frequently hand-write C-level extension modules, write extension modules in Cython, use JIT tools like numba. All of this stuff “is Python.”

even for the crud apps so frequently referred to in this thread the equivalent 'real code' is the sql rdbms written in c or c++ no matter what the webapp language is. i don't advocate using python in million line monoliths despite it being my favorite lang in general at the moment but the volume of cognitive dissonance and false dichotomies in this thread is crushing.

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

#280

Post by bobwaycott »

rujuladanh wrote: post #246
bobwaycott wrote: post #214

Earlier quoted context omitted.

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.

I never suggested LOC was an estimator of complexity. Heck, I’m not saying anything about complexity at all. Nor did I indicate there was any need to write a single line of code to figure out a problem space. You may be taking my statement either too literally or out of its intended context.
Post reply on HN