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

151–160 of 346 posts

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

#151

Post by computerex »

mylons wrote: post #139
computerex wrote: post #127

Earlier quoted context omitted.

Wow. It's amazing the lengths people go to to maintain their delusions. Show me one python IDE in action doing effective refactoring across a large, nontrivial python code base. And you didn't even mention concurrency and skipped over it altogether! > use type hints or one of the many libs that enforce types... As if that's pythonic. Heard of duck typing? And those are things you have to do yourself, as additional wo…

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 said I need to see it in action on youtube or something, somewhat like https://www.youtube.com/watch?v=gjLAoYxSLTE

Anyone can claim anything without providing sufficient proof. I once refactored a 200 million line assembly program over lunch.

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

#152

Post by pytester »

pushpop wrote: post #104
pytester wrote: post #93

Earlier quoted context omitted.

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

I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times. This might be fine for your typical use cases but it is a terrible way to go about building software if you’re writing headless services. The point of functional tests is they catch developer errors before your codebase hits production. Which you…

>I have no problems with exception per se but what you’ve now done is push your error checking into the runtime which means your application could crash at unexpected times.

In theory but in theory any application could crash at an unexpected time.

In my experience on a half decent code base these sanity checks never trigger during production in normal code; they're designed to get triggered during tests. They're there to make it easy to track down the root cause of bugs.

The times when they did get triggered on production code I did it intentionally as a way to debug a train-wreck of an application in production.

>it is a terrible way to go about building software if you’re writing headless services. Disclaimer: I write services used by millions of people (literally) each day.

It's worked fine for me.

I've been doing this for 10 years - on many projects that have had millions of users. You're not special.

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

#153

Post by 0815test »

tomrod wrote: post #114
coleifer wrote: post #61

Dude wants a compiler and wants to go fast. And he picks rust? Guys been hanging out way too long on hackernews.

Why not Rust? I am in a similar situation to the author. Python handles most of what I need, but that last 20% I need more.

The Rust compiler is well known for having rather less-than-stellar performance, and this can definitely impact larger projects. (Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation. It's not exactly an easy issue to address, given that LLVM itself is rather old and clunky code; written in C++ for maximum portability, not so much performance.)

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

#154

Post by phkahler »

sidcool wrote: post #130

I have a genuine question. One of Rust's biggest plus points is having no GC and the related overhead at runtime. Go, on the other hand does use GC. Then how come so many successful Systems programs (e.g. Kubernetes) are written in Go. Anything I am missing here?

GC is one of those features that divide languages. It isn't a big limitation but it usually precludes hard real time performance. Rust caught the public's attention more recently than go. Both are still in their early days as far as adoption is concerned.

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

#155

Post by mylons »

computerex wrote: post #151
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 said I need to see it in action on youtube or something, somewhat like https://www.youtube.com/watch?v=gjLAoYxSLTE Anyone can claim anything without providing sufficient proof. I once refactored a 200 million line assembly program over lunch.

ok. tell me what i’ve done and haven’t done. you’re the expert.

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

#156

Post by brown9-2 »

kod wrote: post #134
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.

My experience of working with Go in teams is that it encourages copy-paste programming and "works on my machine" deployment problems.

How does it “encourage” the latter?

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

#157

Post by amelius »

sidcool wrote: post #130

I have a genuine question. One of Rust's biggest plus points is having no GC and the related overhead at runtime. Go, on the other hand does use GC. Then how come so many successful Systems programs (e.g. Kubernetes) are written in Go. Anything I am missing here?

Rust is still in research phase, as many programming patterns have no clear counterpart in Rust. Even though Rust's approach is very interesting, it might very well be that its strict typesystem turns out to be a dead-end for some existing programming patterns.

Also, writing self-referential data-structures is very difficult in Rust (but not impossible) due to the type system. I suspect that a lot of developers who just want to get work done get turned off by fighting with the typechecker, and choose GoLang instead.

And also: GoLang is a very accessible language, that can be mastered in a couple of days.

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

#158

Post by phkahler »

gbear605 wrote: post #150
stingraycharles wrote: post #105

Earlier quoted context omitted.

Not saying you’re wrong, but Google re-implemented Java for Android, which is quite different from using Java alone. So it’s not a completely fair comparison.

Of course the reimplementation is what got them into this lawsuit...

I think it's more accurate to say that not paying Oracle is what got them in court. Either way it shows that the steward of a language can be important.

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

#159

Post by makapuf »

guidopallemans wrote: post #116
newen wrote: post #95

Earlier quoted context omitted.

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?

An example: pandas.read_csv https://pandas.pydata.org/pandas-docs/stable/reference/api/p...

Why not have clearer file, filename or data keyword arguments ? Or just file and call open or stringio if you have the file name or data ? Plenty of more explicit solutions.

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

#160

Post by cyp10 »

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

Give me two lines of an innocent man's hand...

Really, changing a Python project is not pretty, because speed and memory usage guarantees vary wildly between releases. One factor is that CPython is constantly being rewritten.

And that does not even cover projects that depend on 20 PyPI packages, which introduces practically guaranteed breakage.

Post reply on HN