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

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

Post reply on HN
Print view View original

331–340 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#331

Post by nlitened »

lamontcg wrote: post #155

The arguing about Rust seems to miss that Rust protects against more than just security bugs. If you've ever generated some object out of some factory and then tossed it on a list of things and then gone back to generate a new object out of the factory and found that the first object you put on the list got scribbled over because you forgot to clone it, then that's a category of bugs that rust entirely prevents. And…

You can also use immutable/persistent data structures and GC, which gives the same safety from bugs, but is much cheaper from the perspective of precious time spent.

Re: Using Rust at a startup: A cautionary tale

#332

Post by kika »

satvikpendem wrote: post #283
pipe_connector wrote: post #88

Earlier quoted context omitted.

In general I agree with you, but Go's simple syntax means that there are extremely few (if any? I've never run into one) edge cases with checking that an error was at least considered. The guarantees are the same as what you get with e.g. Rust. The only difference is that you have to run a third party's code, which I don't like, either.

> The guarantees are the same as what you get with e.g. Rust. I'm not sure how they could be, given that Rust checks exhaustively and Go doesn't. If one programmer messes up, then that's it, an unhandled exception might occur in the future. I would rather rely on the computer telling me when it should be handled over humans.

And the worst human to tell you that is an SRE

Re: Using Rust at a startup: A cautionary tale

#333

Post by 3a2d29 »

josephcsible wrote: post #324
3a2d29 wrote: post #323

Earlier quoted context omitted.

Right but if you imported one of those crates, then your “safe” rust would have memory safety issues. So bam, you just introduced memory safety issues into your web API. This is like a C++ dev using C++ and causing memory issues unnecessarily just because they don’t want to use a safe language. And Elixir has concurrency and memory safety and it’s guaranteed, so no package you import can violate it. Unlike rust, wher…

My program might also crash if there's a bug in the kernel's filesystem driver, but that's not my bug. And Elixir has FFI, which definitely lets you do unsafe stuff.

It’s not about crashing, it’s about exposing memory that could lead to security vulnerabilities.

And FFI? As in the Unix extensions? That’s the operating systems calls, not the language. By that logic, python is as dangerous as C++.

It’s crazy how so many people on this thread say rust is the only choice because of memory safety, and are now bending over backwards trying to claim memory safety is no big deal. So much so FFI is now being brought up smh.

Re: Using Rust at a startup: A cautionary tale

#334

Post by mancini0 »

satvikpendem wrote: post #284
3a2d29 wrote: post #266

Earlier quoted context omitted.

Fair, but again I think you can get all those things with a GC language. Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

> Speed in programming never matters except in the systems space. This kind of attitude is how we get bloated Electron apps that HN (including me) loves to complain about. Speed should be a first class consideration, not something to throw away for later. > No one is gonna be able to tell Rust vs Go in a web API Debatable, Discord moved from Go to Rust [0] because they were getting latency and CPU spikes from Go's GC…

The problem with Cargo is it only builds rust. I agree it's the best language-specific build tool, but I love the monorepo pattern and future proofing insurances that modern language agnostic build systems like Bazel enable / provide.

Re: Using Rust at a startup: A cautionary tale

#335

Post by josephcsible »

3a2d29 wrote: post #333
josephcsible wrote: post #324

Earlier quoted context omitted.

My program might also crash if there's a bug in the kernel's filesystem driver, but that's not my bug. And Elixir has FFI, which definitely lets you do unsafe stuff.

It’s not about crashing, it’s about exposing memory that could lead to security vulnerabilities. And FFI? As in the Unix extensions? That’s the operating systems calls, not the language. By that logic, python is as dangerous as C++. It’s crazy how so many people on this thread say rust is the only choice because of memory safety, and are now bending over backwards trying to claim memory safety is no big deal. So much…

If "import ctypes;ctypes.string_at(0xdeadbeef)" in Python doesn't count as memory unsafety, then I don't see why the equivalent in Unsafe Rust would.

Re: Using Rust at a startup: A cautionary tale

#336

Post by drogus »

ahungry wrote: post #14

I've noticed that Rust is in an interesting spot - it has a lot of overlapping appeal with various groups. - C/C++ developers like it as an alternative for low level languages - Functional programmers like it because of it's functional features - "Cargo Culters" / "Hot Language" / "Flavor of the Month" followers like it, as it's in vogue at the moment (this is the crowd that has likely shifted from various web/API sc…

I've written a few APIs in Rust and I'm kinda baffled on what the author is trying to convey. On the one hand he mentions that it's a simple CRUD application, on the other hand he mentions complexity that arose from using Rust. I wish he gave some concrete examples of problems that they have. From my experience, when writing web APIs, most of the problems with Rust are not really that visible. Most of the time you get a request, process some data or interact with a database (or both) and return the response. In this scenario you don't often have to deal with lifetimes or any of the advanced stuff.

Re: Using Rust at a startup: A cautionary tale

#337

Post by 3a2d29 »

josephcsible wrote: post #335
3a2d29 wrote: post #333

Earlier quoted context omitted.

It’s not about crashing, it’s about exposing memory that could lead to security vulnerabilities. And FFI? As in the Unix extensions? That’s the operating systems calls, not the language. By that logic, python is as dangerous as C++. It’s crazy how so many people on this thread say rust is the only choice because of memory safety, and are now bending over backwards trying to claim memory safety is no big deal. So much…

If "import ctypes;ctypes.string_at(0xdeadbeef)" in Python doesn't count as memory unsafety, then I don't see why the equivalent in Unsafe Rust would.

No post body was provided.

Re: Using Rust at a startup: A cautionary tale

#338

Post by kika »

optymizer wrote: post #167
pclmulqdq wrote: post #68

Earlier quoted context omitted.

In my experience, Python is one of the least productive programming languages for projects with more than 3 people. If you have a big project, you are going to spend a lot more time reading code than writing it. Python is write-optimized. By contrast, using Rust makes it easy to force a readable coding style on yourself and others.

Python is not readable to you? The beginner friendly, whitespace-enforcing, almost-like-pseudocode-in-English language - that Python? - is not readable enough, but Rust, where you liberally sprinkle ', {}, !, &, :: or #[] everywhere _is_ readable to you? You must be trolling. You know what Rust looks like to me? Perl without the dollar signs. There's your write-only language, you just have it backwards.

How does pattern matching looks like in Python? No, not 3.10 :-) The 99% of Python code that I have to read at a random company is barely 3.7

Re: Using Rust at a startup: A cautionary tale

#339

Post by josephcsible »

3a2d29 wrote: post #337
josephcsible wrote: post #335

Earlier quoted context omitted.

If "import ctypes;ctypes.string_at(0xdeadbeef)" in Python doesn't count as memory unsafety, then I don't see why the equivalent in Unsafe Rust would.

Quoted post unavailable.

I am not a beginner.

Those sorts of security vulnerabilities are possible in Python/Elixir/etc. In both Rust and Python/Elixir/etc., they're only possible when you do certain unusual things. You are claiming that the Rust way does count, but that the other languages' ways don't count, with no justification.

Memory safety does matter. Rust is memory-safe and C++ is not, so your conclusion doesn't follow.

Re: Using Rust at a startup: A cautionary tale

#340

Post by josephcsible »

3a2d29 wrote: post #289
arcticbull wrote: post #287

Earlier quoted context omitted.

> 1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. That's not what you originally claimed though. You made some claims about 'risk of future unsafety' and I'm not sure what that means? For the second half of your claim, Rust's safety guarantees extend well past memory safety - and a collector doesn't guarantee memory safety at all. Yes, most G…

Right, but to my knowledge the other “safety” of rust is concurrency, which is easily attainable with something like Elixir. I’m not saying a GC guarantees all safety, I am saying you can find a GC language that gives all the safety (and technically more) of rust. My quote of “future unsafety” is that even if your code currently uses only safe rust, their will always be the chance someone adds unsafe rust, increasing…

> I am saying you can find a GC language that gives all the safety (and technically more) of rust.

Giving "all the safety" is theoretically possible, but "technically more" is not. And even if you did have "all the safety", you'd still have the big performance disadvantage with a GC language.

> My quote of “future unsafety” is that even if your code currently uses only safe rust, their will always be the chance someone adds unsafe rust, increasing the safety issues.

No there won't. This is what #![forbid(unsafe_code)] is for.

Post reply on HN