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

461–470 of 496 posts

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

#461

Post by pdntspa »

nawgz wrote: post #299
pdntspa wrote: post #189

Earlier quoted context omitted.

And the IDEs which practically write your code for you. I mean yeah Java is so verbose but most of that word vomit is me just tabbing through autocomplete I went back and prototyped a slightly similar app in Python w/ a gui toolkit and I felt like I was driving through exception city. I have made my career writing in dynamic languages so I forgot just how pleasant it was to write in a static one!

> Python w/ a gui toolkit Sorry, this is always the wrong choice, which is why it felt so bad. Writing a UI in TypeScript with any of the major frontend frameworks will not require you to wade through run-time exceptions Java native GUI toolkits are also far more mature Python and TKinter and similar stuff is always just awful, I've never seen someone put together anything half decent with that stack

Calibre, the ebook client, is a python GUI app. wxWidgets I think?

Theres another app that I use for renaming downloaded video files that uses a GUI toolkit.

I've written GUIs in pyGTK for industrial apps and it was a wonderful experience. The only reason I couldn't get it to work now because I can't get pygobject to compile on Windows (the offered solution of MSYS2... wasnt)

Unfortunately this project was working with Stable Diffusion, so I had to use something in Python

In any case I don't like this idea of a right or wrong answer here. LIke way too many people think Electron is a right answer and I think that's just dumb

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

#462

Post by bsder »

Night_Thastus wrote: post #270
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…

I think it's dismissive and overly simplistic to say that Rust is almost always a better option than C or C++. They're different languages with different strengths. One strength of C++ is that it is far more established than rust - and that comes with a lot of advantages: * It has a larger number of people who know how to work with it * It has a huge catalog of established, fully functional libraries for everything y…

> That will improve with time, but it's a huge advantage to C++ right now.

Sadly, it's not really an advantage anywhere that hasn't already eaten the grief and doesn't already use C++.

Both C and C++ infrastructure are so horribly terrible that Zig is gaining traction simply by creating a better compiling infastructure totally indepdent of whether the language is better or not.

That's one hell of a downvote.

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

#463

Post by jjnoakes »

Zababa wrote: post #399
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…

OCaml with tooling and an ecosystem from the size of Go would be an ideal. Java and C# can more and more be written like MLs too.

I think I would love an ML-like language built on the go runtime and standard library and ecosystem.

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

#464

Post by dcow »

steveklabnik wrote: post #401
dcow wrote: post #396

Earlier quoted context omitted.

Not since I’ve use it either. I may be missing something since I’ve only used async Rust, in what way does Rust say “you need a lock here”? If it does that then I stand corrected and I may just have to drop async Rust altogether and checkout crossbeam + rayon that everyone raves about.

Rust has two traits, Send and Sync. Send means "this can be transferred to another thread," and Sync means "this can be accessed via a reference in another thread. Here's some (contrived!) example code (for one thing I'm using thread::scope because I don't want to deal with joining the threads): use std::thread; use std::rc::Rc; fn main() { let v = Rc::new(vec![1, 2, 3]); thread::scope(|s| { s.spawn(|| { do_work(v.cl…

I understand send and sync. I see what you’re saying. Though note, even if you pass around Arcs the inner value still has to be Mutex or RwLock. But I do see how Rust makes this more structured. Honestly with async it’s usually enough to just make sure your types are Send and Sync and clone them so that’s really the extent of what I normally have to deal with.

Re deadlocking: With async runtimes, since you have a fixed threadpool, if you use the normal locks from the stdlib you can deadlock or more accurately stall your program because all available executor threads are blocked waiting on a lock. If the executor is starved the task that would unlock the stalled threads never gets scheduled. It’s a problem unique to the task executor paradigm (the thread per task version of the program would be logically correct and never deadlock or a version that used yielding locks). Not sure if thats exactly what you’re talking about, but, it’s a part of the language/experience I think could use some work. Would be nice if the structure that exists around data races could also exist around blocking vs yielding calls from async tasks.

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

#465

Post by dcow »

EVa5I7bHFq9mnYK wrote: post #441
dcow wrote: post #349

Earlier quoted context omitted.

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

Yeah but your UI framework turns all that stuff into events so you’re not dealing with raw mouse data. I personally think the complexity is similar and have done FE for 10 years and more backend/security/networking side of things the last 5.

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

#466

Post by dcow »

ReflectedImage wrote: post #446
itishappy wrote: post #381

Earlier quoted context omitted.

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

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

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

#467

Post by dcow »

justinclift wrote: post #440
MrJohz wrote: post #431

Earlier quoted context omitted.

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

I believe the project is called Interface Types.

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

#468

Post by nasmorn »

legerdemain wrote: post #257
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…

This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in…

I could understand this reasoning but it is not the typical node backend I am seeing in the wild.

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

#469

Post by tcfhgj »

ReflectedImage wrote: post #446
itishappy wrote: post #381

Earlier quoted context omitted.

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

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

#470

Post by galangalalgol »

adastra22 wrote: post #444
galangalalgol wrote: post #358

Earlier quoted context omitted.

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

I use it for numeric heavy stuff and I'm going through tonic for any service connections. That abstracts me from any async wierdness and for the dsp code I don't care about lightweight threads. I don't want many/any more threads than I will have cores.
Post reply on HN