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

291–300 of 346 posts

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

#291

Post by apta »

rujuladanh wrote: post #247
xedrac wrote: post #241

I'm a long time C++ developer, and recently took a job where I write a lot of Python in a large code base. Initially it seemed great, but I quickly realized how uncomfortable it is to have no safety net up front. The interesting thing is Python eliminates a lot of programming errors you may encounter in C++. But it introduces a whole different set of programming errors you would never see in C++. I don't feel comfort…

Neither Rust nor C++ eliminate logic bugs (and no language can do that). If you are writing code that must work, you should be either formally prove the system (if feasible) or have a huge test suite covering everything.

> Neither Rust nor C++ eliminate logic bugs (and no language can do that).

While true, it's a big benefit to eliminate classes of known bugs (e.g. memory safe languages eliminate undefined behaviors, and Rust eliminates data races). That allows the programmer to pay attention to other aspects of the code, since there's only so much energy one person can spend.

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

#292

Post by apta »

gbear605 wrote: post #142
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.

> Google is of course going to use Go more than most companies would.

You'd be surprised.

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

#293

Post by apta »

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?

> (e.g. Kubernetes)

Kubernetes may as well have been written in Python. It's mainly IO bound, so the benefits of compilation as opposed to running on an interpreted VM (like Python) aren't that big.

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

#294

Post by gbear605 »

rujuladanh wrote: post #249
gbear605 wrote: post #163

Earlier quoted context omitted.

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

There is little point to introduce a GC in Rust. If you don't mind a GC, you have nicer languages out there.

From my perspective, of all the languages that I’ve tried (Java, C, C++, Javascript, Haskell, OCAML, Python, several lisps), PHP, Swift), Rust is the best even without the borrow checker, and the borrow checker is just a nice bonus. Admittedly, there are many languages that I haven’t tried, and I haven’t done significant work with all of those.

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

#295

Post by apta »

ChrisSD wrote: post #200
theshrike79 wrote: post #196

Earlier quoted context omitted.

Both are modern languages but with (IMO) vastly different views on how a language should be constructed. Go went with simplicity to a fault. No generics (use code generation instead), just one way to make a loop, garbage collection. Rust on the other hand has all the bells and whistles a language could have combined with the ability to micro manage every bit of memory you're using. People tend to lean either way.

But those different "views" are born of their different use cases. Rust is meant to be low level, like C++, and thus micro managing memory is an essential feature it can't do without. Go is meant to be a higher level server side language that replaces languages like php, python or Java on the server. It's simple so it's almost as fast to compile as a scripting language is.

Because when golang first came out, it was hyped as a "systems language", and meant to compete with C++. Most people use that term to refer to languages you use to write kernel level software. Of course, contrary to the golang author's wishes, golang ended up being a competitor to python/nodejs/etc. but it's still the case that the marketing hype from when the language first came out affects what people talk about, even if they don't know the context of why that discussion came about in the first place. Rust on the other hand, is a (somewhat) viable C++ replacement, as can be seen in the projects that get implemented in it (e.g. Rust made its way into the Firefox browser, as well as other low level and speed critical networking projects at different companies).

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

#296

Post by coleifer »

dang wrote: post #285
coleifer wrote: post #58

So a typically unimaginative python programmer sees new Kool aid and is thinking about taking a drink. Decides to write blog post about it. And somehow it's #1 on hn.

Please don't break the site guidelines, regardless of how wrong you feel someone else is. We've had to ask you this multiple times before. https://news.ycombinator.com/newsguidelines.html

Which one did you feel I had broken? This post was just meme-filled gas.

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

#297

Post by pdimitar »

mark_l_watson wrote: post #106

Thanks for The writeup, I am going through a similar process. I just retired last Friday (I am an old guy) from managing a machine learning team and everything was done in Python. For personal projects (and past consulting work) I have been loving Lisp languages since the 1980s but many languages have so many of the benefits of Lisp (thinking of Haskell and Julia) and there is definitely a ‘lisp tax’ on deploying and…

If I retired today I'd try really hard to only use Elixir and OCaml.

Elixir is perfect for servers and fault-tolerance. Also scales quite well to several tens of machines before needing any special tooling.

For a huge percent of most projects today Elixir would be ideal.

OCaml I want to use more for its really concise and strict (but extensible) syntax. And mostly for its strong typing and really well-optimized compiled native code.

Congratulations on retirement, relax and tinker at your own pace. ^_^

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

#298

Post by chewxy »

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…

Thanks to this post, I went back to see if my oldest large Go project was working: https://asciinema.org/a/cJosP51z0oScKPLmVUhyNKUOj

9 years later, still works.

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

#299

Post by dang »

coleifer wrote: post #296
dang wrote: post #285

Earlier quoted context omitted.

Please don't break the site guidelines, regardless of how wrong you feel someone else is. We've had to ask you this multiple times before. https://news.ycombinator.com/newsguidelines.html

Which one did you feel I had broken? This post was just meme-filled gas.

You broke the guidelines about name-calling, flamebait, and snark.

HN users need to follow those regardless of how bad an article is or they feel it is.

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

#300

Post by gbear605 »

apta wrote: post #292
gbear605 wrote: post #142

Earlier quoted context omitted.

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.

> Google is of course going to use Go more than most companies would. You'd be surprised.

I’d expect at least higher usage in products that aren’t a business focus. Kubernetes is a good example of that since Google doesn’t actually use it.
Post reply on HN