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

141–150 of 346 posts

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

#141

Post by killaken2000 »

acqq wrote: post #92
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…

See the details here about his project that he maintained in Python for years (since 2006) in Python: https://blog.liw.fi/posts/2017/08/13/retiring_obnam/ I can really understand his: "Obnam has not turned out well, from a maintainability point of view. It seems that every time I try to fix something, I break something else. Usually what breaks is speed or memory use: Obnam gets slower or starts using even more memor…

These two stuck out as well. I wonder if the issue is with their coding practices and not necessarily a fault with the language.

If the issue is one of fundamentals it will only follow them to the next project or language

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

#142

Post by gbear605 »

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?

For one, because in many systems situations, having the garbage collector slowdown is okay. Also Kubernetes is probably a bad example since it’s a Google project and Google is of course going to use Go more than most companies would.

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

#143

Post by sgillen »

computerex wrote: post #127
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 wo…

With regards to refactoring I’ve never had a problem using pycharm for refactoring python. But that is literally the only tool I can say that for.

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

#144

Post by [deleted] »

stochastic_monk wrote: post #136
tyingq wrote: post #91

Earlier quoted context omitted.

"Programming languages should be choosen based on technical merits, rather than who is behind it." Considering the motivations of the language owner is a valid concern. Many people, for example, jumped on to HHVM as a "faster PHP". Then it started branching away from PHP[1]. Predictable, if you considered Facebook's reasons for having it. [1] https://hhvm.com/blog/2018/09/12/end-of-php-support-future-o...

What were Facebook’s reasons?

[deleted]

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

#145

Post by mpweiher »

bayesian_horse wrote: post #84
mpweiher wrote: post #78

Earlier quoted context omitted.

True. However, there is fairly strong evidence that it helps with understanding code.

Please cite that evidence. To me it sounds like circular reasoning, because in my subjective perception, dynamically typed code is a lot easier to understand to begin with. Also, tooling has become a lot better, with and without typecheckers/annotations.

For example: Do Static Type Systems Improve the Maintainability of Software Systems? An Empirical Study

"Despite their importance, whether static type systems influence human software devel- opment capabilities remains an open question. One frequently mentioned argument for static type systems is that they improve the maintainability of software systems—an often used claim for which there is no empirical evidence. This paper describes an experiment which tests whether static type systems improve the maintainability of software systems. The results show rigorous empirical evidence that static type are indeed beneficial to these activities, except for fixing semantic errors."

https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf

Follow on:

An empirical study on the impact of static typing on software maintainability

"We further conduct an exploratory analysis of the data in order to understand possible reasons for the effect of type systems on the three kinds of tasks used in this experiment. From the exploratory analysis, we conclude that developers using a dynamic type system tend to look at different files more frequently when doing programming tasks—which is a potential reason for the observed differences in time."

https://link.springer.com/article/10.1007/s10664-013-9289-1

Note that I wrote "evidence", not "proof". Also, there is no robust evidence for safety improvements.

Are there potential confounders? You bet. Are there other aspects that can help? You bet.

I do find that types help me with older code, despite the fact that my preferred languages (Objective-C, Smalltalk), both have keyword syntax that helps tag arguments even if there's no types or documentation. Particularly protocols help me define the interactions that I expect in my system, which otherwise tend to be only defined implicitly through the objects. I'd prefer real connectors.

When I try to understand Smalltalk code, that's a lot of browsers open and digging etc. When I look at some of my older Objective-C frameworks, all the id types do leave me with a bit of head-scratching. A lot of the times the types are trivial to add, and just make things obvious at a glance.

However, I also totally agree that these languages help me write cleaner code, and that enforced type systems get in the way of useful architectural abstractions. Sometimes I need that id.

¯\_(ツ)_/¯

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

#146

Post by gbear605 »

stochastic_monk wrote: post #136
tyingq wrote: post #91

Earlier quoted context omitted.

"Programming languages should be choosen based on technical merits, rather than who is behind it." Considering the motivations of the language owner is a valid concern. Many people, for example, jumped on to HHVM as a "faster PHP". Then it started branching away from PHP[1]. Predictable, if you considered Facebook's reasons for having it. [1] https://hhvm.com/blog/2018/09/12/end-of-php-support-future-o...

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.

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

#147

Post by akjha »

dcuthbertson wrote: post #12
fxj wrote: post #2

After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.

Maybe I'm picking nits, but the author is comparing programming experiences in each of those languages, which is perfectly valid. For example, last year I was part of a team that rewrote a very large Node.js program (several hundred thousand lines of code) in Go. The differences in following control flow and in the edit-build-test loop are like night and day. We've found Go meets our needs better than Node.js for wri…

Interesting. What are some the benefits you felt with Go in comparison to Node.js?

We already have a largish (couple hundred thousand line) Node.js app written in Typescript and are looking towards other alternatives for the future product as I am not very happy with the quality of Node.js ecosystem.

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

#148

Post by ryanianian »

ptx wrote: post #48
IshKebab wrote: post #10

Earlier quoted context omitted.

I disagree. 15k lines of code is a lot of code to keep entirely in your head all at once, which is basically what you have to do if you're using a language as dynamic as Python. In static languages like Java you can easily use tools to check types are correct, find usages of variables, jump to definitions and so on. And you get compile time errors if you screw up, rather than runtime errors.

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 breakpoint if you have no idea what bootstraps what.)

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

#149

Post by theshrike79 »

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.

The problem is that WAY too many projects are still on Python 2.x.

Either some weird support library hasn't been upgraded to 3.x yet or some expensive piece of software/hardware can't be accessed with Python 3.x

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

#150

Post by gbear605 »

stingraycharles wrote: post #105
russtrotter wrote: post #89

Earlier quoted context omitted.

I'd say, all things being equal, yes, choose languages on tech merit or suitability to task. But look at what's happening with Java and Oracle's handling of it. I think the Google vs Oracle lawsuit is still going through appeal. Ask Google if they wish in hindsight they'd built Android on something else.

Not saying you’re wrong, but Google re-implemented Java for Android, which is quite different from using Java alone. So it’s not a completely fair comparison.

Of course the reimplementation is what got them into this lawsuit...
Post reply on HN