Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

271–280 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#271

Earlier quoted context omitted.

FWIW the “parse don’t validate” attitude which has become popular in TypeScript circles does this equally well. In Rust you’ll define the types you expect to deserialize as structs with Deserialize trait implementations, in TypeScript you’ll define a basic schema with runtime decoding and corresponding (inferred) static types. Like you say, maybe 45 seconds more typing, with the same value guarantees. I like that thi…

To me the greatest thing about TypeScript is that there are times that I absolutely know that something doesn't need to be extra safe or to have validation, and I can easily slap a `// @ts-expect-error` on it and either ignore it or come back and fix it later. I know some people think that's a horrible thing and sacrilege, but damn it if it makes it easy to move fast when you need to.

What’s an example where this works be a significant time saver?

In my experience writing a Zod schema to parse something into a typesafe form is quick and easy and you end up with full maintainability

Re: Using Rust at a startup: A cautionary tale

#272

Earlier quoted context omitted.

> an ecosystem that prioritizes safety etc. Idiomatic Rust code is just as cavalier regarding NPEs as Java or Python code. Because the language starts to look really gross when you make your code panic-safe. So you have an `expect` here, an `unwrap` there, and now you're going to have the exact same runtime issues as the more expressive managed languages. No Rust programmer thinks their `expect` will panic, just like…

expect is a lot safer than ignoring a return code.

Java and Python don't use return codes, they use exceptions. If you ignore an exception your program crashes, same as a panic in Rust.

Re: Using Rust at a startup: A cautionary tale

#273

Earlier quoted context omitted.

I've read and written a huge amount of python and rust, also a fan of rust and don't find it particular difficult to read. As long as there is proper linting, both should be readable. That being said, python is about the simplest language there is to read. Of course if you have many times nested and improperly indented list comprehensions- sure that gets confusing. But that should be fixed with proper linting (black…

I don't necessarily agree that Python overall is difficult to read, but one thing that seems to get my every time is the foo = x if y else z

I see where you're coming from.

Many languages support the ternary operator, where it would be:

  foo = y ? x : z
Which "feels better" but I think that's because I learned ternaries first.

Some languages like Rust and Kotlin do support assignment of an if statement like

  foo = if (y) { x } else { z }
And I think that's a good step, as it doesn't need to introduce new syntax, just allows assignment of "blocks"

Re: Using Rust at a startup: A cautionary tale

#274
post #270
post #40

> We hired a ton of people during my time at this company, but only about two or three of the 60+ people that joined the engineering team had previous experience with Rust. This was not for want of trying to find Rust devs — they just aren’t out there. As an experienced Rust dev, I had the opposite problem. I looked for a good Rust job, but couldn't find one. Took an Elixir job instead. I also don't get the complaint…

> I've worked in a dozen languages, and Rust is still the most productive language for me by far. Did you work on it with a team in a serious production environment? Sounds like you struggled to find a Rust job, so I'm not sure how you can know that without really betting on it like these guys did.

> Did you work on it with a team in a serious production environment?

I did. I left because management was a brood of compulsive liars.

Re: Using Rust at a startup: A cautionary tale

#275

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.

In terms of parsing, sure, Python may be slightly simpler. In terms of mentally interpreting the code? Absolutely Rust wins.

Re: Using Rust at a startup: A cautionary tale

#276
While the author's anecdotal evidence is coherent, it's not enough to establish causation. Especially if the measure of productivity is feelings of sluggishness.

Rust or not, there's an argument to be made for statically typed languages improving productivity over the long run [0].

All development can feel sluggish depending on the work hours, estimates, business timelines, engineering skills, and the task at hand.

Programming languages are common targets because - we use them so much - there are so many - and all developers, at some point, must choose to dedicate their time to one over the others.

Finally, productivity itself is only one performance characteristic. To focus only on that (without even a good definition of effect or measure) makes content precisely what the author claims to avoid; flame bait.

[0] - https://www.researchgate.net/publication/338162224_A_Study_o...

Re: Using Rust at a startup: A cautionary tale

#277
Are there languages that copy Rust's type system and compiler ergonomics without the memory safety?

I feel like 90% of my struggles with Rust in the real world have to do with the borrow checker. The two pieces don't feel related enough to me that they need to be interlinked.

Re: Using Rust at a startup: A cautionary tale

#278

While I respect the author's anecdote, this doesn't match my experience. I've been programming for 20+ years across a wide array of languages and I'm by far the most productive in Rust. With a competent teacher, experienced devs should be able to pick up on the memory model pretty quickly, and that is really the only initial blocker to productivity. After that a dev can essentially write procedural code if they want,…

how can you be more productive in rust, where you do have to worry about object lifetimes than in languages where you don't, and where you can focus more on algorithms, say java?

Re: Using Rust at a startup: A cautionary tale

#279
post #201

Earlier quoted context omitted.

You can find a GC language that does all those things that rust does but without: 1. The risk of future unsafety (a GC language will always safer than rust) 2. Faster development that's easier to change on a dime. 3. No risk of memory leaks (which can happen in safe rust)

> 1. The risk of future unsafety (a GC language will always safer than rust) [citation needed] > 2. Faster development that's easier to change on a dime. Yes, development can be faster at the expense of safety, which is a trade-off that favors the use of other languages at early company stages. Agreed here. > 3. No risk of memory leaks (which can happen in safe rust) ... at the expense of making collection non-determ…

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.

2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it.

3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.

Re: Using Rust at a startup: A cautionary tale

#280
post #199

Earlier quoted context omitted.

> Easy test: Would you at least seriously consider using C/C++ for it? Only then should you use Rust. This is a great point. I understand liking a language, but don't bring Rust into a GC space (in industry, personal projects can be what you like!) You can find a GC language with all the features of rust you like.

You can? Imperative, strong type system (no null, adts), reasonably fast, compiles to a single binary. I'm genuinely interested.

Go fits all of those, so does Ada.
Post reply on HN