Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Candle: Torch Replacement in Rust

github.com

Post reply on HN
Print view View original

181–190 of 192 posts

Re: Candle: Torch Replacement in Rust

#181

Post by devjab »

IshKebab wrote: post #119
devjab wrote: post #65

Earlier quoted context omitted.

> Python is a pain in the ass in production environments. I really dislike blanket statements like that one. Because any programming language can be a pain in production environments. One of the disadvantages of Python is also one of it's advantages. Because it's much easier to end up with a terrible production environment when you use "chaos" languages like Python or JavaScript, the tooling to avoid the pain points…

Saying "any programming language can be a pain in production environments" is technically true but irrelevant and misleading. It implies that all programming languages are equally painful in production, but that obviously isn't the case. Python is definitely among the worst. Easily the worst among popular languages. It's closely followed by C++. Go and Rust are faaar nicer. Totally different league.

> Python is definitely among the worst.

I don't think that is true at all.

Django would frankly be an excellent choice for most web apps and if you're into microservice architecture then frameworks like pantherpy are almost as great as Java's Quarkus. That being said, we do try to limit our Python use to be exclusively for the BI/AI/ML part of our business and that's solely because that's the language those people work with in my area of the world.

This is mainly for pragmatic reasons. We use Typescript for most things because it's nice to have a language that's shared between the front and backend of things when you work in the small teams that are non-tech Enterprise. Then when we need efficiency we use C (and Rust more and more because it protects us from ourselves), when we do embedded it's C and when we need something like Odata or whatever .NET(y) it's C#.

I think Go is nice to write and terrible to work with. Not so much because of the language but because you're going to be writing basically all your libraries from scratch, or alternatively, putting massive maintenance efforts into the ones you consume. Which to be fair, isn't that different from using Typescript, but as long as the frontend of enterprise apps is as it is you're going to be working with Typescript whether you like it or not.

Re: Candle: Torch Replacement in Rust

#182

Post by ddorian43 »

bombela wrote: post #120
devjab wrote: post #65

Earlier quoted context omitted.

> Python is a pain in the ass in production environments. I really dislike blanket statements like that one. Because any programming language can be a pain in production environments. One of the disadvantages of Python is also one of it's advantages. Because it's much easier to end up with a terrible production environment when you use "chaos" languages like Python or JavaScript, the tooling to avoid the pain points…

My experience is that python is a mess in production. Even with a full CI, tests, mypy for static typing, pinned dependencies recursively, bazel with custom rules to build those dependencies (because many python dep have undeclared deps). And of course abysmal performances. And I wouldn't dare letting juniors touch python. Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative l…

> Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative language available right now.

But what about along with the ecosystem/libraries. Would you say in total Java might be better (assuming webdev)? Especially with the Loom project where you don't have to do "async" syntax.

Re: Candle: Torch Replacement in Rust

#183

Post by yodelshady »

tracker1 wrote: post #76
jahewson wrote: post #66

Earlier quoted context omitted.

Rust for web dev instead of Go? I want to believe. What’s the killer app?

I would say for me, the killer app would be just about anything you might reach for Electron with, but want a much smaller install footprint. Tauri in and of itself is pretty cool, kind of a lighter alternative to electron using native platform browser engine. In general, I would probably reach for Rust if I needed to do anything wither Web-Assembly (wasm) as the path to working is much nicer than other languages imo…

Tauri might be cool in theory, but Hello World consumers TWO POINT EIGHT GIGABYTES of hard disk on my machine.

Arguing "Rust has no dev speed penalty" in that context is just... no. You are damaging your own cause there, because all advocacy becomes laughable.

Re: Candle: Torch Replacement in Rust

#184

Post by CryZe »

yodelshady wrote: post #183
tracker1 wrote: post #76

Earlier quoted context omitted.

I would say for me, the killer app would be just about anything you might reach for Electron with, but want a much smaller install footprint. Tauri in and of itself is pretty cool, kind of a lighter alternative to electron using native platform browser engine. In general, I would probably reach for Rust if I needed to do anything wither Web-Assembly (wasm) as the path to working is much nicer than other languages imo…

Tauri might be cool in theory, but Hello World consumers TWO POINT EIGHT GIGABYTES of hard disk on my machine. Arguing "Rust has no dev speed penalty" in that context is just... no. You are damaging your own cause there, because all advocacy becomes laughable.

> but Hello World consumers TWO POINT EIGHT GIGABYTES of hard disk on my machine.

While yes, that's really bad, it's just temporary build files. The actual executable should be fairly tiny.

Re: Candle: Torch Replacement in Rust

#185

Post by bombela »

ddorian43 wrote: post #182
bombela wrote: post #120

Earlier quoted context omitted.

My experience is that python is a mess in production. Even with a full CI, tests, mypy for static typing, pinned dependencies recursively, bazel with custom rules to build those dependencies (because many python dep have undeclared deps). And of course abysmal performances. And I wouldn't dare letting juniors touch python. Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative l…

> Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative language available right now. But what about along with the ecosystem/libraries. Would you say in total Java might be better (assuming webdev)? Especially with the Loom project where you don't have to do "async" syntax.

I understand "ecosystem/libraries" as code available for free. That a quick search online would convince most of us that it is trustworthy enough. That we hope won't require us to ever have to read, modify, and re-design the code. And if we are lucky has a state of the art abstraction for the domain it solves. So that we can get going with our task at hand as quickly and efficiently as possible.

Under this light, Rust has now quite a large ecosystem of pretty good quality I would say.

I have only written small thread safe system level libraries in Java. But I sure noticed that javac did not have a borrow checker ;)

For webdev I had no problem with Rust async or not. But my definition of webdev is reduced to a web server that calls out to a database or another service.

Re: Candle: Torch Replacement in Rust

#186

Post by Qworg »

tikhonj wrote: post #96
Qworg wrote: post #82

Earlier quoted context omitted.

I made the call between Haskell and Rust for my fintech startup. I chose Rust when I realized how few Haskell programmers there were available to hire - at 20 engineers, we'd be one of the largest shops on the West Coast of the US AFAIK. That said, we were one of the largest Rust shops outside of the FAANGs, but Rust was straightforward to teach to C/C++ folks.

We actually had the opposite experience in hiring for our Haskell team: it was substantially easier to find legitimately strong engineers for Haskell than for other teams using Python and Scala. I figure it comes down to two things: 1. A lot more people want to do Haskell than there are Haskell jobs 2. Haskell is an easy way to signal (show not tell) that our team is willing to do things differently—especially import…

! Amazing. I had seen so many strong Haskell teams that Rust seemed like the play, for the same reasoning.

I'm glad it worked out for both of us.

Re: Candle: Torch Replacement in Rust

#187

Post by lsaferite »

fnord123 wrote: post #151
maximilianburke wrote: post #109

Earlier quoted context omitted.

> This is "I don't like python", but phrased adversarially. But it is an incredible pain in the ass in production environments. Environment drift is something that _always_ seems to happen, no matter how diligent people are about using venvs or dependency managers or w/e. One of favorites was when we did a dependency upgrade (something that required a change to Click) we had an upgrade of Black forced on us in order…

>we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. Unlikely. If you are using pre-commit to run black then the version being used lives outside your venv and hence not subject to dependencies you are using. Poetry should also be outside your venv.

> There's always someone saying "you're using it wrong"

I feel like your reply is demonstrating this comment perfectly. You could be perfectly correct, but their point still stands that _they_ had a horrible experience that shouldn't have been so difficult. If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.

Re: Candle: Torch Replacement in Rust

#188

Post by alex_lav »

lsaferite wrote: post #187
fnord123 wrote: post #151

Earlier quoted context omitted.

>we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. Unlikely. If you are using pre-commit to run black then the version being used lives outside your venv and hence not subject to dependencies you are using. Poetry should also be outside your venv.

> There's always someone saying "you're using it wrong" I feel like your reply is demonstrating this comment perfectly. You could be perfectly correct, but their point still stands that _they_ had a horrible experience that shouldn't have been so difficult. If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.

A person had a bad experience. There's a decent chance that bad experience is more that person's fault than it is any technology's. But also:

> If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.

This has never happened for any technology ever. People misconfigure things all the time. Even hardened technologies get used incorrectly very frequently. It's just the reality of our industry. Which is why I say, all of this is just a proxy for "I didn't like my experience with Python", which is fine! But also in no way condemning of the technology.

Re: Candle: Torch Replacement in Rust

#189

Post by lencx »

tracker1 wrote: post #76
jahewson wrote: post #66

Earlier quoted context omitted.

Rust for web dev instead of Go? I want to believe. What’s the killer app?

I would say for me, the killer app would be just about anything you might reach for Electron with, but want a much smaller install footprint. Tauri in and of itself is pretty cool, kind of a lighter alternative to electron using native platform browser engine. In general, I would probably reach for Rust if I needed to do anything wither Web-Assembly (wasm) as the path to working is much nicer than other languages imo…

Tauri is indeed very cool, and also very small (the installation package is typically under 5MB). I used it to build a wrapper application for the ChatGPT official website, extending the site with many interesting features through script injection. However, the compatibility of the system webview across different platforms is a frustrating matter. https://github.com/lencx/ChatGPT

Re: Candle: Torch Replacement in Rust

#190

Post by fnord123 »

maximilianburke wrote: post #158
fnord123 wrote: post #151

Earlier quoted context omitted.

>we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. Unlikely. If you are using pre-commit to run black then the version being used lives outside your venv and hence not subject to dependencies you are using. Poetry should also be outside your venv.

It's not "unlikely"; it's something that happened. And, again, if something that was configured wrong this goes back to how managing Python is a pain in the ass. I should be able to dedicate my brain power to the problems I need to solve, not what things need to be in my venv and what things need to be outside of it.

I agree that managing python development environments is a pain in the ass. I'm completely with you there.

But I'm curious what the nature of a black upgrade being forced on you. Like a manager or stakeholder had an edict stating everyone must upgrade to 23.x?

Post reply on HN