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

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

#161

Post by computerex » Sun, Mar 24, 2019, 2:36 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.

Not telling you what you have done or not done. But this is the internet, you need to provide proof in order for your statements to be taken seriously. I am not telling you to do anything, by all means don't provide any proof.

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

#162

Post by 0815test » Sun, Mar 24, 2019, 2:37 PM UTC

amelius wrote: post #157

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

> Also, writing self-referential data-structures is very difficult in Rust (but not impossible) due to the type system.

Not really true (at least, not nearly to the same extent) since Pin was stabilized. I suppose that only serves to prove your point about Rust still being "in research phase", though!

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

#163

Post by gbear605 » Sun, Mar 24, 2019, 2:38 PM UTC

bayesian_horse wrote: post #79

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…

In all three cases, Python, Go and Rust, the language and ecosystem may be in the hands of an organization, but you can probably produce code productively in it for years even if the organization went under or chose unacceptable paths. Go is quite unique in that it produces very independent binaries. This might make software written in it quite future-proof. Personally I like Python's philosophy and the way the commu…

I think a “rust with GC” could actually be a very good intro language. The borrow checker is more than beginners can handle though.

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

#164

Post by cpuguy83 » Sun, Mar 24, 2019, 2:39 PM UTC

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?

Many reasons to choose go over rust. First and foremost, Rust was not 1.0 and was still making breaking changes when Kubernetes came around.

Other things like the situation with async/coroutines is still it great in rust.

Go is, syntactically, a much simpler language than rust.

It all depends on what you need, what you want, and where then community around it is (e.g. Docker came first and was written in Go).

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

#165

Post by Tehnix » Sun, Mar 24, 2019, 2:40 PM UTC

bayesian_horse wrote: post #71

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.

There are type checkers now. Personally I find type systems a lot more annoying because they lead to more verbose code and more cognitive load. There are studies that show bugs being proportional to the number of lines of code, regardless of language. And that effect seems to be more significant than the difference among dynamic and static type systems. Defensive programming can be achieved through various means. Typ…

> Defensive programming can be achieved through various means. Type checking is one of them and often can't replace Unit and Integration testing.

Of course they won’t replace unit or integration tests, but they will replace a lot of damn trivial tests you have to write to make sure you exercise all paths of the program, because there are no types to help you.

Also, at least when I think of defensive programming, I don’t think of how Haskell et al. allow me to more clearly express my intents in the type system. I think of the times where I write JS/TS and cannot rely on any data anywhere being in the format it says it’s in.

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

#166

Post by FraaJad » Sun, Mar 24, 2019, 2:41 PM UTC

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…

If it is stability you are after, choosing Java on JVM will get you there much better. Java written 20 ago still compiles and works fine today.

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

#167

Post by tyingq » Sun, Mar 24, 2019, 2:41 PM UTC

gbear605 wrote: post #146

stochastic_monk wrote: post #136

Earlier quoted context omitted.

What were Facebook’s reasons?

I don’t know anything about HHVM, but plausibly the goal of it is “help Facebook” rather than “be a faster PHP,” and people who came for a faster PHP and are not Facebook are let down by it.

Non-optional strong types is one example where it benefits Facebook, but likely isn't great for those hoping for a "faster PHP". The blog post makes it sound like HHVM will only support hack, and not PHP, sometime in the near future.

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

#168

Post by _underfl0w_ » Sun, Mar 24, 2019, 2:41 PM UTC

typon wrote: post #126

shadowmint wrote: post #68

Earlier quoted context omitted.

no, the trivial frontend is built in python; the real code is usually c++ or c. Ignore that reality if you want to, but it is a fact. Big complicated python projects are seldom pure python, they are usually a friendly python frontend to a serious application written in something else. It seems in no way remarkable that someone wanting to build a serious backend type piece of functionality would pick another language…

I don't understand this logic. The users are learning Python , not C++ when they're trying to learn data science or implement a machine learning model. Should I say Tensor flow isn't written in C++ but CUDA or OpenCL? Any self respecting researcher is training their models on GPU or FPGA, not CPU. The point is that Python is the entry point for large majority of data scientists currently and its absolutely disingenuo…

> The users are learning Python, not C++

The key word here is "users". Python is fantastic for users. It allows users to get things done without having to worry about types or memory or the underlying hardware in any way.

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

#169

Post by newen » Sun, Mar 24, 2019, 2:45 PM UTC

mjw1007 wrote: post #113

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?

One common case where this is attractive is where you have a bunch of "public" functions built on top of each other, with the higher ones passing that parameter on and not otherwise caring what it is: high_level_function(src, ...) ... mid_level_function(src, ...) ... mid_level_function(src, ...) low_level_function(src, ...) ... low_level_function(src, ...) ... If you can make the low-level function generic one way or…

Yeah, that is convenient and I do that often. But I try to wrap the variables in different types depending on their source (e.g. whether it's a filename or file content) so that functions further down can disambiguate between variables explicitly.

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

#170

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

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