I love building a startup in Rust but wouldn't pick it again • Hacker News Board

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

#431

Post by MrJohz » Sat, Feb 18, 2023, 6:47 AM UTC

justinclift wrote: post #230

throw14082020 wrote: post #216

Earlier quoted context omitted.

I should've been clearer, sorry. The verbosity and complexity of `wasm_bindgen`/serialization between JS and Wasm (written in Rust) is primarily the thing I am frustrated at here when I see hundreds and thousands of Rust code. A concrete example: creating a Websocket client in Javascript/Typescript vs in Rust/Wasm. In general though (outside of Wasm), Rust is less readable. And with regards to Rust errors, I've found…

Isn't this due to wasm having to access browser things mostly through browser JS interfaces? eg Browsers provide JS functions that are intended for JS, which are not directly exposed to Wasm. So when your Wasm wants to access DOM things, access DOM functions, (etc) it needs to go through a JS shim layer instead of being able to call them directly. If the browser dev's (or some W3C type of body?) introduced those same…

Expanding WASM to the DOM is definitely part of the roadmap. The problem at the moment, as I understand it, is that the DOM was designed with Javascript in mind, and figuring out how to translate that into something that works well for lower-level access is difficult, particularly in regards to getting garbage collection to work properly between WASM-land and JS-land. There are some alternative solutions that are being explored, but none of this has anything to do with security risks.

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

#432

Post by gls2ro » Sat, Feb 18, 2023, 7:13 AM UTC

nazka wrote: post #377

ye-olde-sysrq wrote: post #200

Earlier quoted context omitted.

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right c…

I love Rails and if it was continuing to grow even so slightly it will be my go to for sure. But unfortunately it has been slowly declining for a long time… Many moving to Go, Elixir, Rust, and elsewhere. It was by far the best dev experience with a framework I ever had. The last version still looks great. But realistically unless if you plan to do a rewrite, which is never a good idea, it may not be the best option…

Ruby is growing (you can say "growing back") starting at least from 2020/2021 with a lot of things happening in 2022 and looking at a very exciting 2023.

Hotwire is an exciting technology coming out of Ruby/Rails ecosystem. Rails 7 was an important release bringing a lot of great features and Rails 7.1 looks even better.

Ruby has a lot of nice advances as language starting with 2.7 and continuing to the recent release of 3.2. Check the recent changes at https://rubyreferences.github.io

IMHO Ruby and its eco-system is the perfect mix of tech that works while trying to get right some of the most important modern approaches.

Specifically regarding the

> But realistically unless if you plan to do a rewrite, which is never a good idea, it may not be the best option out there

This is not directed to you but more a general rant :)

I hate with passion (and yes I am biased) this line of thinking because it is not true in maybe 90% of the cases. And it is not true when one says that about almost any established language that should be used where it fits (or where it is used the most).

What I write below applies to an average company mostly doing Saas/CRUD/web apps. If you are working at FAANG or FAANG-like companies maybe this does not apply to you.

Be sincere:

- Say that you want to pick something that will increase your hiring skills if you are a developer, or that you want to brag to your friends that you are using what Amazon/Google is using or that you want to speak to conferences about the latest big tech

- Or say that you don't like Ruby and just want to choose something else. That is fine.

- Or if you are a director of engineering/leader/manager say that you can hire JS developers cheaper or that offering a cool/hype technology is the only way to attract new people or that you want to feel safe in front of board members/GM/CEO by saying we failed to solve this even if we use everything that FAANG uses.

But please don't say that you don't choose Rails because you might grow so much that you will need to rewrite.

I don't know one single example where a company died because they choose Rails. Just the decision to rewrite a product on its own is a high risk of failing. It does not matter the from:, to: parameters.

And again I need to say to anyone thinking to start a project in Ruby/Rails but thinking they need to choose otherwise: You are not Google, nor Netflix, Amazon, .... You (probably) don't need anything from their tools or architecture that makes them offer concurrent services to hundred of millions of users.

Try to have 10k users first and then I think you will probably have the mindset + management experience to hire Ruby devs or to help a new hire to learn Ruby.

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

#433

Post by kcartlidge » Sat, Feb 18, 2023, 7:57 AM UTC

schemescape wrote: post #422

schemescape wrote: post #352

Earlier quoted context omitted.

Yes, "dotnet publish" is what I was thinking of. Wow, I didn't realize it could cross-compile! I can't quite tell from the .NET SDK repository -- any idea if this stuff works on Linux (i.e. building on Linux, perhaps for Windows)? I see mention of MSBuild, so I'm guessing maybe not. I love C#, but I abandoned it a while ago because I wanted to only rely on open source tools (just to ensure my code is usable in the fu…

Actually, it does work from Linux! I just tried it and "dotnet publish --os win" cross-compiled from Linux to Windows. Nice!

> Actually, it does work from Linux ... cross-compiled from Linux to Windows.

Here's a link to the commands I use to generate my cross-platform builds [1]. They are easy enough to stick in a shell script or batch file so you get all the builds with one command. These produce single executables, trimmed for size.

[1] https://github.com/kcartlidge/Newt#generating-stand-alone-bu...

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

#434

Post by jmaker » Sat, Feb 18, 2023, 7:59 AM UTC

WJW wrote: post #261

Animats wrote: post #237

Earlier quoted context omitted.

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

There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.

Rust has been around for so long these domains should have long since been covered. Quite telling they aren’t yet, particularly considering the momentum in publicity. I wonder why.

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

#435

Post by jmaker » Sat, Feb 18, 2023, 8:10 AM UTC

jmmv wrote: post #428

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…

On the contrary. I’ve been recently writing a web service in Go… and omg what a terrible experience. Sure, I could prototype something very quickly, but now it’s almost impossible to refactor any of it without introducing subtle breakage. And it’s sooooo verbose and redundant and fragile. I’m currently rewriting what I wrote in Rust to see how the prototypes compare and… I just feel so much at peace knowing that the…

Quite the opposite here. Go is very easy to refactor if need be. What kind “breakages” are you talking about? Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go.

In Go you have a garbage collector, no need for the borrow checker or reference counting on your side. What unexpected nil pointers or zeros? It’s all easy and straightforward in Go. If you’re referring to the handling of materialized interfaces, which one may encounter in form of concrete error types, and which is one of Go’s idiosyncrasies, then it might help to look deeper into learning how to handle Go’s interfaces.

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

#436

Post by jmaker » Sat, Feb 18, 2023, 8:23 AM UTC

12345hn6789 wrote: post #371

jjnoakes wrote: post #276

Earlier quoted context omitted.

I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe a…

If you don't need bare metal something like Scala or koitlin will fit. Scala is extremely expressful and does CRUD very well

Scala is amazing but the community has been shrinking for the past few years, ever so fewer libraries maintained.

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

#437

Post by Nevin1901 » Sat, Feb 18, 2023, 8:44 AM UTC

For apps where performance is key, I found you can get by using go for an MVP. Apart from the spikes in cou usage because of the garbage collector, go is fast and allows you to iterate quickly.

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

#438

Post by winrid » Sat, Feb 18, 2023, 9:07 AM UTC

dcow wrote: post #182

I don't agree. I think the author is conflating two things: 1. learning Rust, and 2. using Rust. If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early. The iteration time issue with Rust is solved by experience. We use Rust and…

You can write your REST API with Rust using axum and it can generate your OpenAPI docs. You can even generate a typescript client.

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

#439

Post by zozbot234 » Sat, Feb 18, 2023, 9:09 AM UTC

jmaker wrote: post #434

WJW wrote: post #261

Earlier quoted context omitted.

There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.

Rust has been around for so long these domains should have long since been covered. Quite telling they aren’t yet, particularly considering the momentum in publicity. I wonder why.

> Rust has been around for so long

Rust async support was only released in late 2018. Not very long at all, especially if compared to Golang.

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

#440

Post by justinclift » Sat, Feb 18, 2023, 9:10 AM UTC

MrJohz wrote: post #431

justinclift wrote: post #230

Earlier quoted context omitted.

Isn't this due to wasm having to access browser things mostly through browser JS interfaces? eg Browsers provide JS functions that are intended for JS, which are not directly exposed to Wasm. So when your Wasm wants to access DOM things, access DOM functions, (etc) it needs to go through a JS shim layer instead of being able to call them directly. If the browser dev's (or some W3C type of body?) introduced those same…

Expanding WASM to the DOM is definitely part of the roadmap. The problem at the moment, as I understand it, is that the DOM was designed with Javascript in mind, and figuring out how to translate that into something that works well for lower-level access is difficult, particularly in regards to getting garbage collection to work properly between WASM-land and JS-land. There are some alternative solutions that are bei…

I hope you're right, and it does end up happening. That would very much enable many languages (LLVM based ones anyway) to become practical alternatives to JS for web dev, whereas now they're more like "can be sorta done with significant effort". ;)

Btw, my impression that it would be blocked by JS people involved in the process, was from a conversation some time ago with one of the JS people themselves.

They said (from their point of view) there's no need for WASM to directly access things instead of going through JS, and they'd block it themselves if things went that direction. Security was the lever they mentioned they'd probably be able to use.