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

121–130 of 346 posts

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

#121

Post by bayesian_horse »

melling wrote: post #112
bayesian_horse wrote: post #71

Earlier quoted context omitted.

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…

I don’t think Haskell or OCaml are more verbose than Python. Other traditional languages are adopting type inference, etc. We could be near an inflection point where we get statically type languages that are as convenient as Python.

Oh sure, but Haskell and OCaml are much less popular than Python, with consequences for community building, recruiting, reusing existing code bases etc.

The popular statically typed languages which are actually Python's competitors are for example C++, C#, Java and the like.

Sure as hell they are more verbose. Even Typescript was extremely intimidating to me when I started to try and understand Typescript code bases.

And I am NOT going to try and teach Haskell or Ocaml as a first programming language...

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

#122

Post by phkahler »

bayesian_horse wrote: post #74
empath75 wrote: post #42

Earlier quoted context omitted.

Type checking as an add-on is okay but it is not the same thing as a statically typed language.

There is no proof or study that statically typed languages are safer in any regard than others.

There was a paper linked here on HN a week or two ago that proved a number of safety guarantees using something similar to Rust. Sometimes there is truth behind the hype.

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

#123

Post by pushpop »

UncleEntity wrote: post #119
pushpop wrote: post #111

Earlier quoted context omitted.

Again, the point is you need your engineers to diligent enough to do so. That isn’t always the case. Which is why I talk about checks being part of the standard language build tools. Humans error. I’ve seen numerous occasions when stuff that should have been added into the tests wasn’t. Even from engineers who are normally thorough. I’ve also seen cases when competent engineers have written test cases that pass when…

This seems a more institutional issue than something python should take care of for you. If your devs are pushing code into production that doesn't pass the tests (or they aren't even running the test suite) then you're asking for trouble no matter what language you use . As much as I love reading 20+ pages of errors c++ likes to spit out when you use a template wrong if I want to do something simple I just reach for…

> If your devs are pushing code into production that doesn't pass the tests (or they aren't even running the test suite) then you're asking for trouble no matter what language you use.

Clearly that’s not even remotely what I said. But I’ve posted the same thing twice already. I see no point posting it a 3rd time.

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

#124

Post by lerax »

melling wrote: post #112
bayesian_horse wrote: post #71

Earlier quoted context omitted.

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…

I don’t think Haskell or OCaml are more verbose than Python. Other traditional languages are adopting type inference, etc. We could be near an inflection point where we get statically type languages that are as convenient as Python.

> I don’t think Haskell or OCaml are more verbose than Python.

I love Haskell computing model, but holy hell, why is so difficult using things like State Monad or even a trivial thing like a global counter [1] ? Why something so simple should be so difficult? Don't say it's because functional programming, Scheme/Racket is not that difficult!

Haskell and OCaml has their own problems, I agreed with you that both languages are more expressive but the code density is not necessary a good thing neither.

[1]: https://github.com/scotty-web/scotty/blob/master/examples/gl...

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

#125

Post by Rotareti »

gameswithgo wrote: post #25
jacquesm wrote: post #8

15Kloc and trouble is indicative of other problems than a problem with the language. I wrote multiple 50Kloc and up pieces of software in GFA Basic, arguably a much more limiting and unsafe environment than Python ever was, and yet, that software worked well and was maintainable to the point that its descendants still run 3 decades later. Python has all the bells and whistles you need to build large code bases, but y…

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.

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

#126

Post by typon »

shadowmint wrote: post #68
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.

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 disingenuous to try to dispute that reality.

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

#127

Post by computerex »

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…

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 work and maintenance rather than getting it free because it's a feature of the language. And you don't always have full control over the stack.

Is there an IDE that will guarantee that no runtime errors will take place due to typing?

> Adoption rates keep exploding

Because python made its way into the rapidly growing machine learning market. Python is great for writing glue code/scripts because it's easy to extend with C. Everyone and their grandma getting into data science use python.

> I have no problem with that, just don’t try to sell it to me on technical grounds, because it looks very much like you have none.

Looks like you are just not willing to accept or even recognize any valid criticism of Python. This type of fanaticism towards the language is not the first time I am seeing it.

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

#128

Post by mlthoughts2018 »

yakshaving_jgt wrote: post #23

I share the author's sentiment, and it's what lead me to Haskell. It's faster and cheaper for me to write prototypes in Haskell than it ever was in Ruby. And at least in startup-world which is the bulk of my career, the speed at which you can build a reasonably robust prototype can be the life or death of a business, and this prototype usually ends up being the production product anyway. Prototypes are seldom rewritt…

I’ve worked professionally in Haskell across three jobs (one huge corp, two start-ups), and seeing how bad Haskell functions in practice, when quickly mutating state to incrementally modify behavior is live-or-die necessary and under constant business pressures from product managers who don’t care about the paradigm of the backend.

I’ve found so many unexpected runtime errors in Haskell, behavioral bugs that require deep, stateful dependency injection to properly test for, type class designs that were set up wrong for some use case last year and now are horribly brittle and unmanageable to try to use it for the new use case that needs customer feedback immediately.

Plus, for all the syntactical niceties of Haskell, the code becomes unreadable the instant you start needing a dozen different GHC compiler pragmas all defining weird special behavior or syntax. Yet it’s just basic Haskell 101 these days to require new compiler pragmas for tons of basic functionality that you could get out of the box in other languages. Getting a whole team up to speed on how to mentally keep track of that from one section of code to the next is a very difficult chore.

My real life experience with Haskell is why I don’t use it professionally any more.

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

#129

Post by LawnboyMax »

jsjohnst wrote: post #52
LawnboyMax wrote: post #28

Strongly agree with author. I really like Python and at one point thought that it makes sense to write almost any project in it, since it's so versatile and I know it pretty well. After working on a quite large application and having to use lots of assert(isinstance(arg, type) at the beginning of almost every function, I began to think that a strong type system is very much needed for large projects. I believe this w…

> I began to think that a strong type system You’re confusing static/dynamic and strong/weak. Python is a strongly typed language, but also is dynamicly typed language. Need proof? Try doing this: a = 3 b = “3” c = a + b > having to use lots of assert(isinstance(arg, type)) Python has type hinting now, try using a current version of Python and this isn’t needed.

I am using the current Python version and tried type hinting. I don't see how it can help much, since types are not enforced;especially when interfacing with not-so-well-tested modules that don't use type hinting and can sometimes return values of unexpected type.

It's definitely a neat feature when writing an application from scratch that interfaces with few other modules or only the well-tested ones.

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

#130

Post by sidcool »

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?
Post reply on HN