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

301–310 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#301

Post by josephcsible »

synergy20 wrote: post #25
63 wrote: post #15

There's a reason why we see so many articles like "we rewrote x in rust." Rust makes sense when you've scaled to the point that you're seriously considering performance. Sure, starting with rust can potentially save you time, money, and refactoring down the line but only after you've reached a point that few startups ever hit. Otherwise you're limiting yourself with slow development times (compared to, say, Python) a…

as far as performance is concerned, many other compiled language will do with easier coding, rust does not really stand out there.

> many other compiled language will do with easier coding

At the expense of safety.

Re: Using Rust at a startup: A cautionary tale

#302

Post by josephcsible »

3a2d29 wrote: post #279
arcticbull wrote: post #247

Earlier quoted context omitted.

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

Is Java not a GC language, or does sun.misc.Unsafe not exist?

Re: Using Rust at a startup: A cautionary tale

#303

Post by karmakurtisaani »

fooker wrote: post #101

This matches my experience. I have been doing compiler development in C++ for about 10 years, lisp before that and a bit of python more recently. We could not figure out how to be productive in Rust after starting a greenfield project and sticking to it for a month. Luckily this was not a project which requires incremental updates, we were on the verge of rewriting it in C++.

Well if you had 10 yoe with C++, you would certainly not achieve the same level of productivity with Rust for a while. Your point is valid in the sense that you should use the tool that you know if you need results, but it's not great criticism towards Rust.

Re: Using Rust at a startup: A cautionary tale

#305

Post by vaylian »

mrich wrote: post #206

Languages like Python can go a long way for a startup and is my first choice. Rewrite in Rust when it's clear that the API is stable and performance starts to matter.

Exactly. Iterating on an idea is much easier to do in Python, because you can just use lists, dictionaries and sets to solve most problems. Python's string manipulation is also a lot easier than Rust, because you don't have to think about allocations. Once you have figured out what works, you can start defining your Rust structs and enums to build up a reliable code base.

Re: Using Rust at a startup: A cautionary tale

#306

Post by diptanu »

I am building modelbox right now - https://github.com/tensorland/modelbox I began building this in Rust while also learning the language. It became quickly very complex as I started introducing streams in async traits. I think in a few years things will get a lot better as more people use Rust for building web services, but I had to go back to Go to be more productive and ship this thing out. I loved how the compiler was forcing me to think harder about life times and such.

Re: Using Rust at a startup: A cautionary tale

#307

Post by eyelidlessness »

purplerabbit wrote: post #271
TranquilMarmot wrote: post #166

Earlier quoted context omitted.

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

Won’t speak for GP, but I’ll say why I think @ts-expect-error is a useful tool for this. It’s not so much a time saver as a time rearranger. Assuming a few conditions:

- you actually care about type safety so you’re not going to just `as any`

- you have a linter that will block unsafe commits or merges

- you have some type you want to use after it’s established safe, and an idea you want to fill out without breaking flow for even those 45 seconds or whatever to define your schema

- despite your predilection for type safety, you iterate on ideas like that the way people who prefer dynamic languages talk about: damn the torpedoes, I’m in the REPL

Given those assumptions (which fit a lot of TS devs well), the really good thing about @ts-expect-error in particular is it allows you to save an intermediate step for later, catch it in CI or whatevz, and it'll yell at you when, and only when, you leave it unsafe unnecessarily. It’s a good way to have your safety cake and eat your dynamic prototyping cake too, especially if breaking flow for a yak you’d shave anyway is going to sink your flow.

Re: Using Rust at a startup: A cautionary tale

#308

Post by bpicolo »

candiddevmike wrote: post #50
satvikpendem wrote: post #36

I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

If anything, context param drilling due to lack of thread local variable or similar is way less ergonomic

Re: Using Rust at a startup: A cautionary tale

#309

Post by bpicolo »

Casperin wrote: post #260
3a2d29 wrote: 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.

Kotlin has null safety, and there are plenty of ways to turn jvm into a binary

Re: Using Rust at a startup: A cautionary tale

#310

Post by 3a2d29 »

josephcsible wrote: post #302
3a2d29 wrote: post #279

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

Is Java not a GC language, or does sun.misc.Unsafe not exist?

I don’t why people keep finding one GC language that has unsafe, then declaring my argument wrong.

My point is you can find a safe GC language with all the benefits of rust.

Post reply on HN