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

181–190 of 346 posts

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

#181

Post by kod »

brown9-2 wrote: post #156
kod wrote: post #134

Earlier quoted context omitted.

My experience of working with Go in teams is that it encourages copy-paste programming and "works on my machine" deployment problems.

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.

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

#182

Post by civility »

0815test wrote: post #153
tomrod wrote: post #114

Earlier quoted context omitted.

Why not Rust? I am in a similar situation to the author. Python handles most of what I need, but that last 20% I need more.

The Rust compiler is well known for having rather less-than-stellar performance, and this can definitely impact larger projects. (Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation. It's not exactly an easy issue to address, given that LLVM itself is rather old and clunky code; written in C++ for maximum portabil…

> Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation.

Considering clang generates LLVM IR and compiles much more quickly than Rust, this argument doesn't hold. The Rust compiler generates IR which chokes LLVM and makes it slow, but they didn't have to do that.

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

#183

Post by oselhn »

coldtea wrote: post #85
mpweiher wrote: post #78

Earlier quoted context omitted.

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

Type hints throughout the code give you exactly the same understanding.

Only if they are correct. I am pretty sure that in old code base it will not be correct unless automatically checked before commit.

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

#184

Post by weberc2 »

therealmarv wrote: post #14

15K LOC in Python. Be prepared to increase your LOCs to at least 33-100% when writing in Rust or Go, hopefully your error rate by line of code will decrease more than your overall LOC. There are not only benefits.

I’ve written a lot of Python and a lot of Go. The errors per loc are much lower in the latter because code density is much lower and because of the type checker. In other words, if you measured errors by statement or something more meaningful than “line” then it would account for the difference in density, but I would still expect far fewer errors in Go.

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

#185

Post by yakshaving_jgt »

mlthoughts2018 wrote: post #128
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…

I see. I guess I should rewrite my Haskell projects into something else then. Yes, I am more than satisfied with how quickly I can develop features according to business needs. Yes, I am more than satisfied with the [observed] robustness. Yes, these businesses are currently 100% of my income. But as you rightly point out, Haskell is bad. /s

A few things are interesting to me here:

1. How we've managed to come to such different conclusions despite supposedly having similar experiences

2. The vigour with which you attacked my rather innocuous comment

3. I had a look at some of your previous comments about Haskell, and you seem to repeat the same talking points over and over, almost verbatim. In fact, this comment you made is particularly interesting:

> it becomes the same shit code mess as any other paradigm.[0]

If what you say is true, then what is your argument exactly? If everything inevitably produces the "same shit code mess", then why are you attacking me for essentially saying "I like Haskell and it is working for me"?

[0]: https://news.ycombinator.com/item?id=19400648

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

#186

Post by coldtea »

oselhn wrote: post #183
coldtea wrote: post #85

Earlier quoted context omitted.

Type hints throughout the code give you exactly the same understanding.

Only if they are correct. I am pretty sure that in old code base it will not be correct unless automatically checked before commit.

That's trivially settled with a static type checker.

So the argument is analogous to saying "how can I trust the types in this Java program are correct, if it has never been compiled".

Well, whether some "old code base" has them correct or not, just run the type checker and find out.

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

#187

Post by atoav »

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 more than I would’ve expected. In fact I tend to use it over python for many things nowadays. One of these things is definitly how the module system works, but I agree with you: if you fuck up in Python with your code structure, the problem is definitly between chair and desk.

However: Rust won’t let you get away for cheap if you don’t think about structure, and this could certainly help some to adopt better practise (which in the end is good for all of us).

Interestingly enough my appreciation for and interest in languages like C and C++ grew a lot, after I had learned Rust. It gave me a good new perspective on C++ and certainly learnd me ton of good patterns and concepts that will definitly end up beeing useful in other languages. Rust certainly is well thought out and good ideas are never bad to look at.

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

#188

Post by bobwaycott »

IshKebab wrote: post #10
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…

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.

15K doesn’t seem like much. I’ve spent the last 5 years keeping 250-300K straight in my head, and have never struggled with it. 15K would be a delight. I can recognize hitting a personal limit at 300K, though—not that I can’t hold more, just that I lose all interest in doing so. That seems to be the point where I grow tired of a problem space.

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

#189

Post by pushpop »

UncleEntity wrote: post #140
pushpop wrote: post #123

Earlier quoted context omitted.

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

My understanding of your argument is it's too much of a burden for devs to run a static type checker manually so the language should force you to run it as part of the compilation process. Sure, yeah, if you want to ensure type safety then use a type safe language...argument over. ...unless you want to do something like duck punch some function into someone else's library and you really don't want to rearchitech how…

Yeah I agree dynamic languages have their place too. I’m actually extremely agnostic about languages.

That said, I’ve been on projects debugging code that has had functions overridden like that and it wasn’t fun. Sometimes people can get too clever for their own good. But you can have that problem regardless of the language

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

#190

Post by theshrike79 »

justinclift wrote: post #98
zachruss92 wrote: post #94

For me I think it comes down to what is the right tool for the job. I have been using Python for years for web scraping & data analysis (via Scrapy and SciPy) and I feel that they are the best tools for what I am doing. Now that a lot of my scraping needs require me to render the DOM, I have had to run a headless web browser (previously PhantomJS/Splash and now Chrome). Chrome released the Puppeteer library which is…

> parse through a large amount of HTML files to extract relevant information. Any idea if Go has an equivalent to Pythons Beautiful Soup? :) Back when I used to do Python development, Beautiful Soup was awesome for extracting info from possibly-munged HTML. Haven't yet found a good equivalent for Go. :/

I haven't found anything that matches Beautiful Soup's ability to parse completely borked HTML.

For HTML that's at least mostly valid, I like goquery: https://github.com/PuerkitoBio/goquery

Post reply on HN