The author's series on learning Rust, not linked in the OP https://blog.liw.fi/learning-rust/
I really enjoy the author's blog, which has been discussed here many times over the years https://hn.algolia.com/?query=liw.fi
On Learning Rust and Go: Migrating Away from Python
251–260 of 346 posts
Re: On Learning Rust and Go: Migrating Away from Python
#252I 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?
You are missing the obvious. Go has may successful projects because some people chose to write software in Go as opposed to just have opinion and debates on PL theories, GCs and runtimes.
Now I am not arguing one way or another. People can just have opinions or they can just write software or they can do both.
Re: On Learning Rust and Go: Migrating Away from Python
#253Folks may also be interested in a thorough analysis of porting a big Python app (0install) to OCaml, after considering various alternatives like Rust and Haskell: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...
Re: On Learning Rust and Go: Migrating Away from Python
#254Earlier quoted context omitted.
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?
Or almost any advertisement tracker server.
Re: On Learning Rust and Go: Migrating Away from Python
#255Earlier 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.
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 recognition.
The same guys working on mypyc [1], which I think is very interesting too.
[0]: https://github.com/python/mypy/graphs/contributors [1]: https://github.com/mypyc/mypyc
Re: On Learning Rust and Go: Migrating Away from Python
#256Earlier quoted context omitted.
How does it “encourage” the latter?
gopath, poor standardization of project layout, build processes and dependency management. I've seen people copy protobuf definitions from repo to repo because they couldn't get them building consistently from a different directory, never mind issues with different versions of the go protoc plugin.
GOPATH is no longer needed after Go 1.11 and Go 1.12.
Re: On Learning Rust and Go: Migrating Away from Python
#257Earlier quoted context omitted.
Technically, you'd use a C/C++ library with a Python wrapper.
Yes, that is called Python.
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.
Re: On Learning Rust and Go: Migrating Away from Python
#258Earlier 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…
You missed the point, so I'll repeat it. The parent I was responding to made the comment that python has type hinting, responding to OP's criticism of Python's lack of static typing. My point was, there was no notion of type hinting in python until PEP 484 or whenever it was released, long after the initial release of python. Python was released in 1991 and type hinting was introduced in like 2014. So for the 23 years the language existed prior to type hinting, people made all sorts of arguments/excuses for why that's not needed/unnecessary for Python. Hell, even now as a consequence of this type hinting in python isn't all that common. It may have to do with the fact that for 85% of the language's lifespan, there was no type hinting and duck typing was rampant, which like I said is an approach that goes against type hinting.
So if you want people to be pythonic in py3, they have to make massive changes like replacing duck types with abstract classes.
I think it's weird that you don't question why vast majority of python code has no type hints. Do you have experience in Python?
Re: On Learning Rust and Go: Migrating Away from Python
#259Earlier quoted context omitted.
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 mig…
You know that protocols and static duck typing are possible, right?
They're not at odds at all.
Re: On Learning Rust and Go: Migrating Away from Python
#260Earlier quoted context omitted.
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…
You missed the point, so I'll repeat it. The parent I was responding to made the comment that python has type hinting, responding to OP's criticism of Python's lack of static typing. My point was, there was no notion of type hinting in python until PEP 484 or whenever it was released, long after the initial release of python. Python was released in 1991 and type hinting was introduced in like 2014. So for the 23 year…
It makes sense now, thank you. I think the word "pythonic" was misused in the parent - usually it's normative, but type hints are strictly optional.
I don't think I've seen anyone argue that Python 3 code without type hints is unpythonic. Except maybe the parent, but I think that's just unfortunate wording. It's explicitly using a non-standard definition of pythonic ("part of the language").