On Learning Rust and Go: Migrating Away from Python • Hacker News Board

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

#171

Post by AsyncAwait » Sun, Mar 24, 2019, 2:48 PM UTC

0815test wrote: post #153

tomrod wrote: post #114

Earlier quoted context omitted.

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

> The Rust compiler is well known for having rather less-than-stellar performance.

You can do 'cargo check' to do the analysis part without actually compiling a binary, it's super fast and excellent for development.

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

#172

Post by weberc2 » Sun, Mar 24, 2019, 2:50 PM UTC

Rotareti wrote: post #125

gameswithgo wrote: post #25

Earlier quoted context omitted.

Most of my serious work has been done with statically typed languages, though of course I have worked with dynamically typed ones as well. There are a few things about dynamically typed languages that seem to productivity-negative, but it may just be my lack of understanding of how people expert at a dynamic languages work with them. 1 - When working with a large enough code base that you don't remember exactly what…

Python has type annotations since 3.5 and you can get static type checking via mypy. This is a type system that works quite well IMHO and eleminates most of the issues you mentioned.

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). Python needs a better static typing story in order to be a productive language in medium-to-large-sized projects.

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

#173

Post by theshrike79 » Sun, Mar 24, 2019, 2:51 PM UTC

Annatar wrote: post #76

lordnacho wrote: post #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 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).

From Google's Shell Style Guide[1]:

"If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date."

[1] https://google.github.io/styleguide/shell.xml

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

#174

Post by weberc2 » Sun, Mar 24, 2019, 2:52 PM UTC

kod wrote: post #133

Rotareti wrote: post #125

Earlier quoted context omitted.

Python has type annotations since 3.5 and you can get static type checking via mypy. This is a type system that works quite well IMHO and eleminates most of the issues you mentioned.

The main benefit of Python is the ecosystem of libraries. Those libraries don't have type annotations. Mypy is a far cry from a real statically typed language.

There is typeshed for stubbing libraries that don’t have their own annotations, but there are still several popular libraries that can’t be annotated—like SQLAlchemy or boto—because they generate their own types at runtime.

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

#175

Post by ris » Sun, Mar 24, 2019, 2:53 PM UTC

empath75 wrote: post #47

ris wrote: post #43

Earlier quoted context omitted.

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.

Nix is not "your own dependency management system"

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

#176

Post by pushpop » Sun, Mar 24, 2019, 2:54 PM UTC

pytester wrote: post #152

pushpop wrote: post #104

Earlier quoted context omitted.

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

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

That’s a terribly unsatisfactory answer.

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

There are a lot of conditionals attached to your statement. ;)

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

If you hadnt relied on type checking in your runtime then you might not have needed to get to the stage where you were debugging something in production.

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

I didn’t say I was special. I was just making a point that I have used Python on important services just in case I was coming off as a Python hater.

Btw ive Been doing this for 30 years - though most of that hasn’t been in Python but most of the last 20 years has been high availability systems. Which may explain why I’m less willing to push buggy code to production and rely on exceptions than you.

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

#177

Post by computerex » Sun, Mar 24, 2019, 2:55 PM UTC

mylons wrote: post #155

computerex wrote: post #151

Earlier quoted context omitted.

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.

> pycharm also uses the type hints that are PART OF THE LANGUAGE (aka pythonic) as of python 3.x and enforces them.

Just goes to show you how incredibly messy the transition from 2 to 3 really is. Duck typing and typing hinting are two fundamentally different approaches of doing the same thing that rub against one another. That's one more thing adding onto the long list of things that make it a pain in the ass to migrate from python2 to python3.

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

#178

Post by AsyncAwait » Sun, Mar 24, 2019, 2:57 PM UTC

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…

> I wish people could be honest with their motivations, instead of making up excuses to justify this sort of change

Why do you assume motivations other than what the author claims? I very much started on Python, but as my career progressed, I got tired of being frustrated with poor library documentation and having no static types, making it extremely difficult to figure out even the parameter types to pass in, especially after it's been a while.

After switching to static typing, things have been a lot less brittle and even faster to develop. It is often said that Python is fast to develop in, but this is really only true for prototyping. Making a program and making a robust python program are entirely different, whereas they're much less separate in a statically typed language.

Also, statically typed does not imply FactoryFactory or no type inference, especially for languages like Rust, Swift and to a certain extent Go as well. The code written in Rust, Swift etc. could often be as elegant & short as one in Python, without loosing the benefits of static typing.

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

#179

Post by weberc2 » Sun, Mar 24, 2019, 2:57 PM UTC

coleifer wrote: post #58

So a typically unimaginative python programmer sees new Kool aid and is thinking about taking a drink. Decides to write blog post about it. And somehow it's #1 on hn.

What’s your specific complaint? That someone is picking up other languages? That they are writing about them? I use Python as my primary language too, but I don’t see anything objectionable about these things...

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

#180

Post by mykowebhn » Sun, Mar 24, 2019, 2:58 PM UTC

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…

I feel exactly the same way with all the Rubyists moving to Elixir.