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

341–350 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#341

Post by kika »

williamcotton wrote: post #34

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…

It's not a language, because why do you need language for that. But it's called Hasura, written in Haskell. It's a server which translates Postgres into GraphQL.

Re: Using Rust at a startup: A cautionary tale

#342

Post by virtualritz »

fooker wrote: post #281
virtualritz wrote: post #214

Earlier quoted context omitted.

Yes, this matches my experience. It took me almost a year to be as productive (and my code as canonical) in Rust as I was after over two decades of C++. After a month of Rust I was still fighting the borrow checker and grokking basic concepts of the language. So no surprise in what you wrote. However, after that year I am probably a factor of two to ten more productive in Rust. The speedup is about two for everyday c…

>It needs to be integrated with the build and that takes about the same time plus writing/generating a wrapper. It's one line of change for any build system..

> It's one line of change for any build system..

That is simply not true. Lots of build systems assume certain things in certain places and output to be something (what if you want a .so but the build only spits out .a etc.). In any case you may have to resort to shell scrips or launching shell scrips from your own build system. In short: it sucks.

And there is also the case when the dependency has dependencies itself. Adding a dependency is one of the biggest PITAs in any C/C++ project. For these reasons:

1. No standardized build system.

2. No standardized use/configuration of common build systems (everyone uses CMake/SCons/whatever slightly differently)

3. Dependencies may have other dependencies, which use yet another build system (see 1. & 2.)

This is the reason why 'single header library' is a 'feature' C/C++ devs look out for when deciding on taking on a dependency.

It makes adding such 'libraries' as deps a no brainer as far as the above is concerned. I.e. your average Rust crate is to your Rust project as is a single header C/C++ to your C/C++ project. Every other kind of dependency is potential pain.

Re: Using Rust at a startup: A cautionary tale

#343

Post by fooker »

virtualritz wrote: post #342
fooker wrote: post #281

Earlier quoted context omitted.

>It needs to be integrated with the build and that takes about the same time plus writing/generating a wrapper. It's one line of change for any build system..

> It's one line of change for any build system.. That is simply not true. Lots of build systems assume certain things in certain places and output to be something (what if you want a .so but the build only spits out .a etc.). In any case you may have to resort to shell scrips or launching shell scrips from your own build system. In short: it sucks. And there is also the case when the dependency has dependencies itsel…

This is a view of C++ outdated by about 5 years.

Re: Using Rust at a startup: A cautionary tale

#344

Post by panachaud »

styluss wrote: post #252
pipe_connector wrote: post #81

Earlier quoted context omitted.

https://github.com/kisielk/errcheck Every Go project I've worked on has used this linter. I think it should be builtin, but it's very easy to incorporate.

What kind of error does it check?

It looks for code where the err != nil hasn’t been handled

Re: Using Rust at a startup: A cautionary tale

#345

Post by MrJohz »

3a2d29 wrote: post #320
MrJohz wrote: post #213

Earlier quoted context omitted.

The difference is that it's fairly easy to prevent unsafe code from occurring: a "forbid(unsafe_code)" directive prevents unsafe code from even being accepted by the compiler. In C++ there is no equivalent - good linting can prevent some obvious errors, but a lot of valid code is inherently unsafe (in the Rust sense) if used incorrectly or under the wrong assumptions. It's also worth pointing out that most GC languag…

Right but to my knowledge (and I could be wrong) that unsafe tag does to prevent it in the crates. Many memory safety violations have been discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ Maybe I wrong on that, but if it can’t guarantee crate safety, then it doesn’t really do anything.

That's true, but again, it's also true in most other languages that your dependencies can do anything they like, including shipping untrusted, compiled C code.

The value of something like "unsafe" is not that your code is magically protected if it isn't there, but rather that it provides a warning sign as to where dangerous code might lie. So if something goes go wrong - or you're just worried something _might_ go wrong - you know roughly where to look. In the same way, if your Python code includes a C extension and you start getting weird segfaults, you can reasonably guess where to start looking.

Except that, because unsafe is so well integrated in the language, you can often significantly reduce the impact of unsafe to only a few lines, and in most cases you won't need to use it at all.

Re: Using Rust at a startup: A cautionary tale

#346

Post by mlindner »

3a2d29 wrote: post #195
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…

I would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak seems irresponsible. Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue? If you like Result or concurrency, use a GC language wi…

If you're going to use Rust in web anything at all, the backend is the first place you'd think of. You can use Rust in the frontend but it's not exactly a smooth experience. Rust is a systems language.

Re: Using Rust at a startup: A cautionary tale

#347

Post by jvanderbot »

woodruffw wrote: post #146
jvanderbot wrote: post #133

Earlier quoted context omitted.

If you're comparing Rust favorably to JavaScript, and then concluding it's the right tool, I think you need more data points.

I take your comment to be a jab at JS, which I’m not a particular fan of, but I don’t think it holds much water: the GP’s example is nearly identical in Ruby and Python as well, and would have the same problem in those languages.

Another interpretation would be that Rust and JS cannot possibly cover all or even most programming domains, so there must be other languages out there that need to be in the ring for any given application.

Re: Using Rust at a startup: A cautionary tale

#348

Post by anna_hope »

necubi wrote: post #75
yupis wrote: post #11

"Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial" Great point

I don't really agree with that framing. Most of the languages people use to write web apps are safe! The actual tradeoff rust is making is that performance is more important than developer productivity. It's not willing to sacrifice safety for productivity, but fundamentally the reason to use rust is that it's fast. If you don't need performance, you might be better off using any number of safe, GC languages. (That s…

Rust with a robust GC (strong type safety, great error handling paradigm, Option type) would probably be my ideal language.

Re: Using Rust at a startup: A cautionary tale

#349

Post by nicoburns »

3a2d29 wrote: post #210
satvikpendem wrote: post #205

Earlier quoted context omitted.

> "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. They're not the same because how C++ does memory safety and how Rust does it is unequivocal. C++ is unsafe by default, Rust is not, and you are ensured it is not, as I mentioned, via things like the borrow checker. To equivocate them is to fall into the same trap you yourself mention. There are no GC vs non-GC spaces. The point of Rust…

Right but my main point is this: Rust comes with additional risk. It is easier to leak memory, it is easier to be unsafe (especially since you can't guarantee what future other devs will do), but you gain nothing. You get all that risk, but fearless concurrency can be done in GC languages (like Elixir) and many people have created the Result type before. So you have added risk for no benefit. Not to mention its easie…

> It is easier to leak memory

I'm not convinced about this at all. I've had far more issues with memory leaks in JavaScript programs than I have with Rust. The only way you're really likely to leak memory in Rust is creating cycles of Rc and Arc types. But I don't think any of my programs have even contained Rc, and only trivial usages of Arc for global resources, which I absolutely wouldn't want to point to each other. JavaScript will let you create the same problem without making it obvious with type signatures. And while you might be lucky and have the GC sort out your mess, it doesn't always manage to.

Re: Using Rust at a startup: A cautionary tale

#350

Post by 762236 »

pclmulqdq wrote: post #68
insanitybit wrote: post #3

Interesting. By contrast, I wish I had used less Python and more Rust for my company's product because Rust is considerably more productive. We were building gRPC and web services. I just haven't found it to be the case that developers have a very hard time learning it, but we haven't grown to the point where that would maybe be the case. We also lean heavily into microservices so "oh there's no library in Rust but t…

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.

Absolutely agree. I've wasted hours trying to deduce the data types being passed around in Python when this takes milliseconds in other languages. My steadfast rule: if a team is using Python, I don't join that team.
Post reply on HN