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

441–450 of 496 posts

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

#441

Post by EVa5I7bHFq9mnYK »

dcow wrote: post #349
EVa5I7bHFq9mnYK wrote: post #310

Earlier quoted context omitted.

Backend code is simpler because is has two limited well defined surfaces (API for the frontend on one side and database on the other side). Frontend is harder because it has to interface with those impolite hairy meat creatures ...

Frontend code has two as well: the input methods (mouse, keyboard, screen) and the API surface. > Backend code is simpler I hear this every once in awhile and think it's mostly a front end happy hour misrepresentation that makes everyone feel good so it gets repeated. The service layer of an application is very often far more complicated than, or to be fair, at least as complicated as, the user interface. Front end d…

>> Frontend code has two as well: the input methods (mouse, keyboard, screen) and the API surface.

If you compare these two surfaces, the sequence of mouse and keyboard events is very much unpredictable and the number of possible states you should think of is much larger. It's not by chance you spend more time with hairier things, it's because they are harder. In fact, it's a definition of "harder".

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

#442

Post by jeremycarter »

pjmlp wrote: post #69
RcouF1uZ4gsC wrote: post #38

Question for HN, all things being equal (you are not more familiar with one language/framework) what language would you choose to build a startup in?

Java or .NET platforms, hardly anything else comes close in languages, tooling and libraries.

This is the correct answer. Not the cool answer.

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

#443

Post by pjmlp »

jeremycarter wrote: post #442
pjmlp wrote: post #69

Earlier quoted context omitted.

Java or .NET platforms, hardly anything else comes close in languages, tooling and libraries.

This is the correct answer. Not the cool answer.

Making a business is not about being cool, unless we are talking about fashion industry.

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

#444

Post by adastra22 »

galangalalgol wrote: post #358
adastra22 wrote: post #347

Earlier quoted context omitted.

30 years of C++ can inoculate you to the idea of hideous amounts of boilerplate, or worrying about memory allocation timelines and such. I'm a 25 year C++ veteran myself. I recently wrote an asynchronous microservice in C++, because it needed to use a C++ library I'd already written. Took about two weeks of effort, and clocked in at 1500 loc, not counting tests or the half-dozen external dependencies. I rewrote it in…

Go was designed from the ground up for that sort of thing, so that makes sense. And anecdotally asymc/await is a pain in rust. I've only used rust async through other libraries, and not that very often. I usually use plain threads.

Yeah Rust supports the same concurrency primitives as Go, but man are they a pain to use by comparison. With Go it is as trivial as using built-in keywords to spawn and merge lightweight threads, and the lightweight thread is the default mode of execution when main is invoked. Structs automatically serialize to JSON. The standard library’s HTTP server is fast, concurrent, and safe for use in production. Summed together that makes use case like mine a breeze to implement in Go.

But yeah, if I was writing an embedded firmware or something I would absolutely prefer Rust.

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

#445

Post by nazka »

gls2ro wrote: post #432
nazka wrote: post #377

Earlier quoted context omitted.

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

I agree like I said the last version of Rails is great. I have been doing Rails for almost a decade now so I’m quite familiar with all its new things. But there are also a lot of issues right now if you are planning to start a company.

The total number of job offers in Rails have been going down for quite a long time now.

If you look at the Stackoverflow surveys and compare the professional respondents for Ruby and RoR between 2021 and then 2022. It’s a 20% decrease. It’s a lot.

Critical contributors of Rails and its ecosystem left for Rust, Elixir, etc. For instance the guy that was behind Active Record went to Rust. Or the creator of Elixir itself and many other followed. On the other hand I don’t see prohiminent open source contributors coming to Ruby to at least replace them… I have been doing Rails myself for almost a decade now and I can tell you that many Rails devs want or already switched to Phoenix or other languages. It’s not going up.

Many gems are mature for sure and don’t really need anymore commits. But also many are abandoned with PRs and issues stacking up. The ecosystem is not really increasing anymore even more vibrant.

Now with all that said: is it impossible to find a job in Rails today? No. Is it impossible to find some devs? No. Is it going to disappear in 4 years? No. Are you going to make a big mistake using it today? No. But there are now so many other options out there without any of these cons and some other pros that it starts to be more and more difficult to chose Rails as a solution today to start a company. Unless you want to use Rails for a side project you can’t ignore these issues and all the other options we now have out there.

About rewrites. It’s not just about the technical part. It’s also the human part. Let’s say I hire you and we grow and there is also 3-10 more Rail devs. But a rewrite has to happen. Are you going to be so exited to jeopardize all your experience in Rails to switch to something new? Even if you are the other 2-9 devs may not. And let’s say more or less everybody agrees that a rewrite has to happen, now you still have to agree on which language and which framework you are going to use! Some may really want to do Go, some Elxir, some other TS…

Whatever the solution that will be chosen there will be a lot of frustrations. Plus there will be frustrations on the tech part of the rewrite and they have to start to be slowly getting more and more productive to the new tech where something that could have taken 1 day can take 5 now. All this, particularly the frustrations from switching to a tech where some won’t really like, will slow down a lot the company. When you check postmortems of startups that failed, so many times in the reasons why they failed there will be this “and we decided to do a rewrite…”. But I never saw a company failed and they will still say that the rewrite was a great idea.

With all that said: better pick the right solution today and look at all the options. Not the Google one, not the one that decrease but one that is at least solid to vibrant, not the last hyped one either, but the best one.

I truly love Rails. But I can’t just chose it because I love it. There are now better options out there for the long term future.

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

#446

Post by ReflectedImage »

itishappy wrote: post #381
ReflectedImage wrote: post #367

Earlier quoted context omitted.

It won't because the number #1 factor in bugs is the number of lines. The Python code will be significantly shorter and thus contain less bugs.

That feels a bit overly reductive. I have a hard time believing GolfScript and APL are among the least error prone languages, for example.

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

So you can choice between eliminating 67% of the bugs by making the language simpler to use or 5% of the bugs by doing formal checking.

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

#447

Post by WJW »

steveklabnik wrote: post #398
WJW wrote: post #297

Earlier quoted context omitted.

Not really, the connection won't close until you are done sending it all and have received the relevant TCP ACK messages from the other sides. Being on autoscaling FAAS or not does not matter for that. In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost…

So here's a real-world case of where this actually does matter: https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w... two minor follow-ups on that as well: * https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r... * https://andre.arko.net/2022/03/13/parsing-logs-faster-with-r...

I appreciate that there might be use cases where performance absolutely does matter, and log parsing is indeed one of the sweet spots for that. But offline analytics is something quite different than HTTP request generation, even if you sometimes do both in an AWS lambda.

Additionally for the case mentioned, the log parsing apparently already fit quite comfortably in the free tier of AWS lambda. Rubygems.org seems to get its developer time for free, so Andre can keep tuning this log parser as a hobby experiment (in the best sense of the word, nothing wrong with having fun). But TFA was about building a startup and most of those definitely don't manage to get their devs to work for free.

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

#448

Post by flohofwoe »

gpderetta wrote: post #117
flohofwoe wrote: post #49

Earlier quoted context omitted.

The problem with exceptions isn't the syntax, but the hidden control flow (they are essentially a goto in disguise). Error union return values make a lot more sense, the rest is just syntax sugar details (and that's where opinions differ I guess).

Exceptions are not a form of gotos, they are both less powerful as they are structured and more powerful (as they are nonlocal). They desugar to continuations, but so does rust option type handling and ?. In fact they are pretty much equivalent. I'm not terribly familiar with either language, but I don't see any particular difference between swift and rust error handling for example, swift will also mark fallible fun…

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 exactly the same as the indiviual trys, if any function in the block returns with an error, that same error is passed up to the caller. But I guess that forcing individual trys makes you think harder about handling individual errors than just pushing the responsibility for error handling up the callstack.

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

#449

Post by gpderetta »

flohofwoe wrote: post #448
gpderetta wrote: post #117

Earlier quoted context omitted.

Exceptions are not a form of gotos, they are both less powerful as they are structured and more powerful (as they are nonlocal). They desugar to continuations, but so does rust option type handling and ?. In fact they are pretty much equivalent. I'm not terribly familiar with either language, but I don't see any particular difference between swift and rust error handling for example, swift will also mark fallible fun…

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.

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

#450

Post by nazka »

ccll wrote: post #402
nazka wrote: post #377

Earlier quoted context omitted.

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…

> But unfortunately it has been slowly declining for a long time… That could be a sign of “stability”. I’m personally using Django since two years ago and have the same feeling as yours, there are nothing exciting happening in this area, but after two years of use I came to the conclusion that it’s features are too stable, so nothing new need to happen in the first place. It’s a common myth that software should be al…

Thank you for your feedbacks on Django. I agree Django is maybe a boring but solid framework. I never used it so I can’t speak about it’s dev experience but it looks great. I see Python kind of like Java but for dynamic languages. It’s not shiny it’s not the hype. But what can’t you do with it? Usually when a new tool comes out you have Java and Python as clients. Before you used to have Ruby too. Now not so much.

For Rails the thing is that it’s not just one lib among a huge ecosystem like Python but more or less Ruby = Ruby on Rails. Sure you have Sinatra which is the Flask of Ruby but that’s it. While in Python you can do so many other things from devops to ML to eBPF…

Post reply on HN