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

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

#231

Post by ptx » Sun, Mar 24, 2019, 5:12 PM UTC

ryanianian wrote: post #148

ptx wrote: post #48

Earlier quoted context omitted.

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

You seem to be describing things that frameworks like Spring add. Java itself (as a language) doesn't "do" anything with annotations, they are literally just some extra strings in the class-file. Spring and its friends use those strings to do their magic. (Personally I find modern Spring applications as inscrutable as RoR applications which does indeed throw many categories of debugging out the window. Can't set a br…

Right, that's what I was saying. Python does do something with annotations, so you don't get the mysterious magic malfunction that you can get in Java.

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

#232

Post by vonseel » Sun, Mar 24, 2019, 5:20 PM UTC

duckerude wrote: post #213

computerex wrote: post #177

Earlier quoted context omitted.

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

They're optional, and it's possible (and not unusual) to use them in Python 2-compatible code with an alternative comment-based syntax and a backport of the typing module. It's possible to start using type hints without migrating to Python 3, and it's possible to migrate to Python 3 without using type hints. They're almost orthogonal. It's weird to bring it up like this - do you have any experience migrating code to…

I’ve done all of that. I guess it depends on the codebase, but transitioning to Python 3 wasn’t so difficult, I suppose it should only be easier now than it was in 2016/17.

Coming back to Python in 2019, it seems almost mandatory to be on Python 3.4+. I can not imagine someone still using Python 2.7. Except for this one place I worked that was stuck in the last century, God bless their little souls.

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

#233

Post by civility » Sun, Mar 24, 2019, 5:26 PM UTC

steveklabnik wrote: post #219

civility wrote: post #217

Earlier quoted context omitted.

> Yes and no; Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.

I think you mean well with this comment, but you're thinking about it incorrectly. Imagine that it's possible to implement these features in the FastISel subset; okay, we do that. Now, we're generating way more code. So we're back to square one. Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. And that's what we're talking about here, compilation sp…

You added to your comment while I was replying, so adding to what I said in the sibling reply:

> Being able to implement something does not mean that by implementing it a different way, it will certainly be faster.

Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more.

> You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works.

Yeah, actually I can. The claim is that LLVM is slow, so it's not Rust's fault. But LLVM isn't slow when compiling a language with nearly equivalent features, so that's a poor excuse. That's how engineering, logic, and accountability work. There is nothing in Rust which doesn't have an analog in C++, and C++ compilers aren't as slow as the Rust compiler.

> note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly."

You brought FastISel into the discussion. This is just another part of the shell game. Compare clang++, g++, and rustc with optimizations on or off.

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

#234

Post by yawaramin » Sun, Mar 24, 2019, 5:28 PM UTC

atoav wrote: post #187

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 was a year long Python user when I stared learning Rust. Reason: I knew just enough C/C++ that I knew I wouldn’t be able to pull through learning it properly from a perspective of time. But I wanted a strongly typed fast alternative to Python without garbage collection. I had read some stuff about Rust and it seemed like a interesting language, mature enough for my applications. I tried it out and came to like it m…

May I ask what your use case was that required a no-GC language?

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

#235

Post by steveklabnik » Sun, Mar 24, 2019, 5:29 PM UTC

civility wrote: post #233

steveklabnik wrote: post #219

Earlier quoted context omitted.

I think you mean well with this comment, but you're thinking about it incorrectly. Imagine that it's possible to implement these features in the FastISel subset; okay, we do that. Now, we're generating way more code. So we're back to square one. Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. And that's what we're talking about here, compilation sp…

You added to your comment while I was replying, so adding to what I said in the sibling reply: > Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more. > You can't just say "well, Zig compiles to LLVM, and it compil…

> The claim is that LLVM is slow, so it's not Rust's fault.

I never claimed this. I claimed that there are a number of interlocking issues that make Rust compilation slow, and pointed out one that I haven’t seen a ton of discussion about before as an example of how it’s not a simple problem.

I also started this conversation by acknowledging one of the things that you said, which was that we generate a lot of LLVM-IR. That’s one that does get talked about a lot.

I don’t think we’re really gonna make any progress here so I’ll leave it at that.

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

#236

Post by vonseel » Sun, Mar 24, 2019, 5:34 PM UTC

pagefault123 wrote: post #37

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…

Perhaps there should be apostasy punishments for Python defectors. /s Python's typing story is far from perfect and rather annoying compared to other languages. Python is good for interacting with the operating system, networking and other things. But wanting a proper compiler is an honest motivation.

If one were to write perfectly type-annotated Python, and a hypothetical perfectly annotated standard library existed, what’s preventing a faster runtime being developed with performance similar to C#, for example? That will never happen, so maybe “what if” isn’t even worth asking

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

#237

Post by catern » Sun, Mar 24, 2019, 5:39 PM UTC

vonseel wrote: post #236

pagefault123 wrote: post #37

Earlier quoted context omitted.

Perhaps there should be apostasy punishments for Python defectors. /s Python's typing story is far from perfect and rather annoying compared to other languages. Python is good for interacting with the operating system, networking and other things. But wanting a proper compiler is an honest motivation.

If one were to write perfectly type-annotated Python, and a hypothetical perfectly annotated standard library existed, what’s preventing a faster runtime being developed with performance similar to C#, for example? That will never happen, so maybe “what if” isn’t even worth asking

It's already being done: https://github.com/mypyc/mypyc

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

#238

Post by vonseel » Sun, Mar 24, 2019, 5:41 PM UTC

sfifs wrote: post #86

typon wrote: post #59

Earlier quoted context omitted.

Yet the entire data science world is built on Python. I don't understand this blatant disregard of reality.

Python is ideally suited for data science and machine learning because 80% of the work tends to be data exploration, transformations and feature engineering and 19% of the work is iterative development of models. In such workflows the lack of type checking & simple REPL is a huge feature. Most of the underlying code for ML is anyway written in Fortran or C and Python becomes a very convenient front end glue For the 1…

I’m not sure how many people will ever even work on CRUD apps of that scale.

Even a mere 1,000 req/sec adds up to 86.4M per day. That sounds like something at least as popular as Stack Overflow, for example. How many web apps are there, really, that have millions of users?

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

#239

Post by pushpop » Sun, Mar 24, 2019, 5:41 PM UTC

pytester wrote: post #227

pushpop wrote: post #176

Earlier quoted context omitted.

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

Your answers are exactly in line with the views usually espoused by a developer who skimps on TDD and automated testing and thus over relies on compiler type checking to catch trivial bugs. The idea that you've been doing it like this for 30 years is somewhat depressing.

Weird how you've come to that conclusion when I've been the one talking about testing and you keep shrugging it off with "well I prefer exceptions" because "sometimes you have to debug things on production".

I honestly don't think you know the first thing about writing stable software so are now just lashing out at me.

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

#240

Post by civility » Sun, Mar 24, 2019, 5:42 PM UTC

steveklabnik wrote: post #235

civility wrote: post #233

Earlier quoted context omitted.

You added to your comment while I was replying, so adding to what I said in the sibling reply: > Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more. > You can't just say "well, Zig compiles to LLVM, and it compil…

> The claim is that LLVM is slow, so it's not Rust's fault. I never claimed this. I claimed that there are a number of interlocking issues that make Rust compilation slow, and pointed out one that I haven’t seen a ton of discussion about before as an example of how it’s not a simple problem. I also started this conversation by acknowledging one of the things that you said, which was that we generate a lot of LLVM-IR.…

> I never claimed this.

No, the person I first replied to did. Then you jumped in and defended his position with your "yes and no" comment.

> I don’t think we’re really gonna make any progress here so I’ll leave it at that.

I agree. I always appreciate your friendliness and thoughtfulness, but I've never gotten you or anyone else on the Rust team to budge an inch on the problems with Rust. (which is a shame, because it's close to being a great language...)