The author equates C++, Go, Python, Java as languages. I think there might have been some other things wrong than the language here.
Using Rust at a startup: A cautionary tale
71–80 of 134 posts
Re: Using Rust at a startup: A cautionary tale
#72Very unsurprising. Rust is a bad choice to use when building a typical CRUD app especially when you are not making any money. So when I saw this about immature libraries:
> Rust, by comparison, has long felt like a work in progress. The docs for a lot of popular libraries are pretty sparse, and one often needs to read the source code of a given library to understand how to use it. This is bad.
I just couldn't help but say that someone has finally cut through the hype, and experienced the reality of the immature state of the library ecosystem in Rust rather than pretending that it is fine; especially for a startup which can result in the failure of feature delivery and of itself.
This cargo culting of programming languages promised by a fan club or hype squad of any new language needs to stop.
Re: Using Rust at a startup: A cautionary tale
#73Earlier quoted context omitted.
I'm not sure that it's that cut and dry. Rust provides good tools for building high level abstractions and the developer tooling is comparable to something like typescript. Depending on the team, rust can be a perfectly reasonable choice for a CRUD application. I have a lot of experience writing microservices and batch jobs using C++. At first this seems outrageous, but with a reasonable set of high level utility lib…
Doesn’t Kotlin or Swift offer those things? I agree Rust is a great language (and has many great things besides its safety protections) but I do think that putting it everywhere when it isn’t necessary is dangerous. If one doesn’t exist already, someone should make a rust-like language with garbage collection. EDIT: Thanks to reading other comments, I remembered Elixir, which offers a lot of the concurrency safety of…
Re: Using Rust at a startup: A cautionary tale
#74> Because we had chosen an “esoteric” programming language for this service, the other engineers in the company who might have otherwise been helpful in building features, debugging production issues, and so forth were largely unable to help because they couldn’t make heads or tails of the Rust codebase. Then they are bad engineers and should be fired. Maybe it's just my general rage at so-called developers being inc…
Re: Using Rust at a startup: A cautionary tale
#75Re: Using Rust at a startup: A cautionary tale
#76Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…
Re: Using Rust at a startup: A cautionary tale
#77> [...] most modern, procedural languages (C++, Go, Python, Java, etc.) all very similar in terms of their basic concepts. [...] With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, [...] Maybe an oversight, C++ is misplaced in that list. C++ without knowing about ownership and lifetimes is a recipe for disaster.
There's so much code in Go that is documented like "while this object takes a file handle, it does not close it itself even though there is a close function, you will need to close it" that in Rust is just a lifetime annotation.
Re: Using Rust at a startup: A cautionary tale
#7811 days ago - https://news.ycombinator.com/item?id=33714007
19 hours ago - https://news.ycombinator.com/item?id=33837803
Re: Using Rust at a startup: A cautionary tale
#79Re: Using Rust at a startup: A cautionary tale
#80Startups spend innovation tokens very poorly. Progamming languages, hosting platforms and non-standard databases aren't ideal places to spend such tokens. For most apps what you want is JVM or .NET, PostgreSQL or MySQL or SQL Server, k8s or vanilla VMs/containers. You almost never want different programming languages to these mature stacks, you might think you do, but you don't. Node.js/Python/Ruby etc all promise a…
Expressive GC languages within the major ecosystems exist, no need to reach for a systems language for a web app just because you want the modern, high level features.