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

I love building a startup in Rust but wouldn't pick it again

propelauth.com

Post reply on HN
Print view View original

471–480 of 496 posts

Re: I love building a startup in Rust but wouldn't pick it again

#471

Post by ReflectedImage »

tcfhgj wrote: post #469
ReflectedImage wrote: post #446

Earlier quoted context omitted.

Leaving joke languages aside, it is very much true. If you use less lines of code to implement a software feature, the software feature will on average have less bugs. Programmers write bugs per line, something like Python which only uses 33% of the lines and thus contains only around 33% of the bugs. On the other hand, if you go down the prove things are correct at compile time you will eliminate around 5% of the bu…

> Programmers write bugs per line Source? Hack more code into one line -> less bugs for the overall program? doubt Use Typescript instead of JS (thus add a few loc) -> more bugs? certainly doubt

That's really a question for Google or Stack Overflow.

One source would be: https://www.oreilly.com/library/view/code-complete-2nd/07356...

Re: I love building a startup in Rust but wouldn't pick it again

#473

Post by pyuser583 »

Animats wrote: post #237
zeroxfe wrote: post #37

If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…

> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess o…

Oooh Rust gaming engines. Hadn’t thought of that. One of my favorite games is coincidentally named “Rust.”

Re: I love building a startup in Rust but wouldn't pick it again

#474

Post by kcartlidge »

physPop wrote: post #458
kcartlidge wrote: post #268

Earlier quoted context omitted.

> I’d love to use C# without having to deal with distributing the runtime, so I’d like to hear more! In the later versions of DotNet there are a couple of common ways to distribute (I'd suggest either DotNet 6 [LTS] or preferably DotNet 7 [current]). You'd usually use the dotnet publish command, which ideally produces one of three things, all of which are self-contained and can be deployed to a clean server without a…

There are many features commonly used in C# libraries that preclude AOT as I understand it -- mostly heavy use of reflection.

Indeed (I mentioned reflection above). It only affects the trimming though - you still get (larger) standalone builds that need no framework installed.

Re: I love building a startup in Rust but wouldn't pick it again

#475

Post by ReflectedImage »

dcow wrote: post #466
ReflectedImage wrote: post #446

Earlier quoted context omitted.

Leaving joke languages aside, it is very much true. If you use less lines of code to implement a software feature, the software feature will on average have less bugs. Programmers write bugs per line, something like Python which only uses 33% of the lines and thus contains only around 33% of the bugs. On the other hand, if you go down the prove things are correct at compile time you will eliminate around 5% of the bu…

Has someone done this analysis with Rust? I highly doubt it holds for Rust programs. Seriously.

Just finished my learning Rust project (very basic version of minecraft). It's great for writing highly parallel high performance code.

At no point was the memory of my program ever replaced with the number 53 nor did memory become corrupt due to multiple threads accessing the same areas at the same time. Much better than C++.

Did my Rust project suddenly contain no errors or did it never crash? Well no. How did it crash?

Array indexing (called default instead of new which created an invalid version of the struct)

Infinite loop (logic error causing it to add the result each loop to the input vector rather than the output vector).

That said Rust is almost certainly going to kill C++. It's a lot better.

Re: I love building a startup in Rust but wouldn't pick it again

#476

Post by d-z-m »

legerdemain wrote: post #293
zozbot234 wrote: post #266

Earlier quoted context omitted.

> want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.

> You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and…

> How is this relevant? Serving a JS application to a client is not like serving a JSON API.

In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want.

> not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.

Can you elaborate on this? How is it limited in comparison to say, Rust.

Re: I love building a startup in Rust but wouldn't pick it again

#477

Post by codethief »

pclmulqdq wrote: post #34
codethief wrote: post #24

Earlier quoted context omitted.

> Exceptions have very high performance costs (equivalent to a longjmp which is very slow) Could you elaborate on why they are so slow, compared to passing around/returning error objects explicitly?

They are slow because you need to restore context from an unknown/unpredictable place in the code, you have a table lookup (from a very cold table) to get the next program counter value, and you have to save and restore register values, while the callstack and the calling convention handle all of that complexity for you if you don't break the natural flow of the program.

But couldn't one implement exceptions internally by returning error codes? Yes, this would change the ABI but as long as we're not talking about the interface of a library, i.e. are not leaving the realms of our source code, this should be ok, shouldn't it?

In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs.

EDIT: I just realized my suggestion wouldn't exactly be equivalent to exceptions, in the sense that it wouldn't give stack traces but error return traces, like in Zig:

https://ziglang.org/documentation/master/#Error-Return-Trace...

Re: I love building a startup in Rust but wouldn't pick it again

#478

Post by tcfhgj »

ReflectedImage wrote: post #475
dcow wrote: post #466

Earlier quoted context omitted.

Has someone done this analysis with Rust? I highly doubt it holds for Rust programs. Seriously.

Just finished my learning Rust project (very basic version of minecraft). It's great for writing highly parallel high performance code. At no point was the memory of my program ever replaced with the number 53 nor did memory become corrupt due to multiple threads accessing the same areas at the same time. Much better than C++. Did my Rust project suddenly contain no errors or did it never crash? Well no. How did it c…

Nobody claims that Rust code contains no errors, but less.

Rust removes types of errors that can happen. Logic errors don't belong to the types of errors Rust 'removes'

Re: I love building a startup in Rust but wouldn't pick it again

#479

Post by codethief »

gpderetta wrote: post #449
flohofwoe wrote: post #448

Earlier quoted context omitted.

I was actually wondering (in Zig, which has a per-statement "try" which is essentially the same as the ? in Rust) whether it also makes sense for whole blocks, which would look a lot like traditional try-catch block in languages with exceptions, e.g. instead of: try may_fail_1(); try may_fail_2(); try may_fail_3(); ...this could be grouped into: try { may_fail_1(); may_fail_2(); may_fail_3(); } ...but would behave ex…

Sure, but we have now (almost) gone full circle:). When writing exception safe code, for me is more important to know which functions are guaranteed not to fail as they will be called in the commit path. Currently I just comment which operations are no-throw and otherwise assume that everything else can fail, but it would be nice to have the compiler tell me.

> for me is more important to know which functions are guaranteed not to fail as they will be called in the commit path

But Zig allows you to see immediately which functions are guaranteed not to fail because those functions's return types won't include an error type.

Re: I love building a startup in Rust but wouldn't pick it again

#480

Post by codethief »

codethief wrote: post #477
pclmulqdq wrote: post #34

Earlier quoted context omitted.

They are slow because you need to restore context from an unknown/unpredictable place in the code, you have a table lookup (from a very cold table) to get the next program counter value, and you have to save and restore register values, while the callstack and the calling convention handle all of that complexity for you if you don't break the natural flow of the program.

But couldn't one implement exceptions internally by returning error codes? Yes, this would change the ABI but as long as we're not talking about the interface of a library, i.e. are not leaving the realms of our source code, this should be ok, shouldn't it? In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just hand…

> In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs.

Here someone else had the same idea: https://news.ycombinator.com/item?id=34846550

Post reply on HN