[HN Gopher] Why use Rust on the back end?
___________________________________________________________________
Why use Rust on the back end?
Author : steveklabnik
Score : 106 points
Date : 2023-03-20 20:06 UTC (2 hours ago)
(HTM) web link (blog.adamchalmers.com)
(TXT) w3m dump (blog.adamchalmers.com)
| mgomez wrote:
| What's everyone using when it comes to data validation these
| days? Maintenance for one of the most popular crates for this
| seems to have slowed[1] and options for JSON Schema validators
| still seem immature[2] (but the ones I've tried work well so
| far).
|
| [1] https://github.com/Keats/validator/issues/201
|
| [2] https://json-schema.org/implementations.html#validator-rust
| dijit wrote:
| > I really like using Diesel because it generates all your SQL
| queries for you, from a typed SQL schema that it generates from
| your SQL migrations.
|
| Fair that the author says that this is their opinion, however...
| I can't agree.
|
| Maybe I'm too stupid, but for me SQLx is the real killer crate
| when it comes to databases.
|
| Everything, from the migrate macro, to the way it validates at
| compile-time the types in the DB, feels (to me) very ergonomic.
|
| Diesel, by contrast, I spent so long trying to set up and I never
| really understood the three different files that need to somehow
| be in sync and generated. I just never really grokked the _split_
| of these files and when to run the diesel-cli commands...
|
| but SQLx is great, I often lament that there isn't anything
| comparable in Golang.
| Pepe1vo wrote:
| Maybe I'm holding it wrong, but my experience with sqlx is a
| bit more lukewarm. It's really great that compilation success
| means that you didn't fuck up any queries, but... there's just
| SO much boilerplate. I find that due to Rust's extremely strict
| type system, I have to create dedicated record structs for all
| of my domain models representing how a model is stored in the
| database. So once everything's up and running it almost always
| implies there's essentially no bugs, but man is getting there a
| drag.
|
| Also, testing is quite annoying too. If you're using sqlite,
| you can use in-memory mode and that's quite nice. But for other
| databases you basically have only two options: 1. setup and
| teardown an actual testing db 2. wrap your sqlx interfacing
| code in something vaguely resembling the repository pattern and
| create an in-memory implementation for testing. I'd call both
| of these options less than ideal.
| zamnos wrote:
| The question is what's the cost of a bug? Lost hours for
| customer support to collect user reports (which take some
| time and usually multiple reports before being believed),
| time spend by CSRs to individually, time by the dev or ops
| team to fix the affected accounts en-masse, more time by the
| CSRs to manually fix up affected accounts and give them
| individual credits where credits are due (which may be manual
| and thus error-prone process), and finally time spent by the
| dev team to identify and fix the bug for future users, which
| is time spent not adding new features or paying down other
| tech-debt. That's not to say using scripting languages isn't
| necessarily worth it for increased speed of development, but
| the time spent above may be impossible to quantify in
| aggregate. If you're in a low stakes environment, where a bug
| costs you single digit basis points/bips, not a problem. If
| you're somewhere like crypto where a bug that an attacker
| discovered ends up costing the exchange, your employer,
| 9-figures, or worse, the medical or aerospace industry where
| bug(s) literally costs people's lives, then avoiding bugs is
| of paramount importance.
|
| The other option is avoid such a high stakes environment, but
| _someones_ got to be in those fields.
| nightpool wrote:
| > But for other databases you basically have only two
| options: 1. setup and teardown an actual testing db 2. wrap
| your sqlx interfacing code in something vaguely resembling
| the repository pattern and create an in-memory implementation
| for testing. I'd call both of these options less than ideal.
|
| Why not just BEGIN a transaction and then ROLLBACK it after
| every test case? That's what every other significant backend
| codebase (using SQL) that I've worked on does. Maybe that's
| what you meant by #1? Not sure why you'd want to avoid it
| then--it will help significantly in testing out any piece of
| code you have that's even slightly outside of the CRUD norms.
| What does Diesel do, reimplement a completely separate
| "testing" version for all of its SQL queries?
| adamch wrote:
| Hello, author here. My coworker Olivia (of
| https://losslessbits.com/) really likes SQLx, I haven't
| personally used it though. I'd love to try it for a future
| project, as long as it can help typecheck my SQL queries.
| Thaxll wrote:
| Why don't you use sqlc + pgx? What's missing from the two?
|
| https://github.com/kyleconroy/sqlc
|
| https://github.com/jackc/pgx
| necubi wrote:
| We originally used SQLx but eventually moved away for a couple
| of reasons:
|
| * The sqlx::query! macro is a neat hack, but the fact that it
| calls out to a database in a proc macro is pretty insane. It
| significantly slows down compilation with a lot of queries, and
| doesn't work reliably with rust-analyzer.
|
| * Inconsistent handling of nullability that would regularly
| break compilation
|
| We now use Cornucopia (https://cornucopia-rs.netlify.app/)
| which I think is a much better approach. You write your queries
| in a separate SQL file, alongside annotations that let you
| specify nullability. A standard build.rs integration performs
| codegen from that, which means compilation itself doesn't
| require a DB and IDE features work well. It also lets you share
| data types between queries which reduces boilerplate
| significantly.
| biorach wrote:
| > * The sqlx::query! macro is a neat hack, but the fact that
| it calls out to a database in a proc macro is pretty insane.
|
| wait... proc macros are run at compile time, right? so db
| queries at compile time?!
|
| but.. but.. why?
| Klonoar wrote:
| It's not running the _queries_ , just sanity checking them
| against table structures/etc. It's actually quite nice and
| worth checking out.
|
| The real issue is that in performance benchmarks Diesel
| beats SQLx, at least last I checked. I'm hopeful the
| rewrite/upgrades to SQLx that are coming shorten this gap.
| chatmasta wrote:
| Doesn't it need to run introspection queries to check the
| table structures? This is still a significant overhead
| compared to code-only compilation, and it also requires
| an additional component (the database) in your build
| stack, which also needs to have a schema in sync with
| other developers and whatever deployment target to which
| you intend to push the compiled program. That also means
| that if you're building with a local copy of the DB, and
| deploying to a remote with its own DB, you have another
| source of risk for disparity between compile and runtime
| (I assume such an error would be caught quickly, so maybe
| it's not so much about additional "risk" as it is
| increased operational complexity).
| lars_francke wrote:
| So compilation can fail if your SQL query doesn't match
| what's actually in the database.
|
| The idea is kinda neat but....
| imron wrote:
| > but.. but.. why?
|
| Compile time verification that you haven't made a typo in
| your SQL, and that if you have updated your db schema that
| your code also reflects these changes.
|
| Turning runtime errors in to compile time errors is one of
| Rust's superpowers.
| shashashasha___ wrote:
| at the end, in his usecase, everyone in his team knows and loves
| rust. all the rest are secondary reasons
| imron wrote:
| All the rest are the reasons they love Rust.
| yutijke wrote:
| I have seen this perspective thrown around quite a bit. I see
| where they are coming from, but I can't empathize with it.
|
| Rust's ecosystem does an admirable job in making it less painful
| to use, but I am still waiting for the day when just chuck any
| type into Gc<T>. Rc<T> or Arc<T> is not an alternative here. A
| garbage collector seriously makes business logic way easier to
| write. And none of rust's other advantages can offset this for
| Web development.
|
| I know there have been attempts at general purpose garbage
| collectors for rust but as far as I've seen none of them seem to
| work seamlessly. Some justifications I've read about it go along
| the lines of LLVM not having native support for stackmaps?
|
| And given how you have unmanaged native pointers lying around
| everywhere, I don't know if you could even have a general purpose
| GC without putting heavy restrictions on code that uses it
| effectively creating a split dialect.
| hardwaregeek wrote:
| Yeah what a lot of people don't understand is that if there was a
| garbage collected version of Rust that kept the same guarantees
| around mutable data, with the same good type system, good
| ecosystem, and good tooling, I'd still write a lot of it. Those
| benefits are way more important to me than the borrow checker.
|
| Basically, Rust fulfills the dream of a functional language with
| pragmatic semantics, syntax, and developer experience. That's why
| I write it.
| cardanome wrote:
| The borrow checker is Rust's unique selling point, if you don't
| care much about it, there are many alternatives that do the
| things Rust does but better. (Well and the error messages:
| other than Elm there are really no other languages with such
| excellent messages as Rust has.)
|
| You might want to explore the space of statically typed
| functional programming languages a bit more. OCaml and F# are
| both very pragmatic functional programming language that will
| give you everything you want and even more.
| hardwaregeek wrote:
| I would emphatically disagree here. The ergonomics of Rust
| blow any functional language out of the water. The
| combination of cargo, rust-analyzer, and rustfmt is far
| better than anything OCaml can offer. Likewise, the choice of
| modules instead of traits, while probably a "better" design
| from a language design aesthetic perspective (more
| compositional, less global), make simple things like printing
| or checking equality rather difficult. And that's not even
| getting into compiler errors, package ecosystem, or
| documentation.
|
| And really, you can see the priorities in how the people
| driving the language talk about it. In Rust there's a focus
| on ergonomics. How can we make this easier to use? How can we
| make the tooling nicer? In OCaml and other languages the
| focus is almost always on semantics. We have unboxed types
| like Rust. We have multicore with green threads. We have
| effects. This is missing the point. I don't care about the
| features of the language if the language itself is annoying
| to use. It's like wondering why Slack or Discord won versus
| IRC. Ergonomics is the answer.
| momentoftop wrote:
| OCaml has dune/opam, OCamlfmt and Merlin. I don't know how
| Rust can blow these out of the water, but would be
| interested in comparing killer features.
|
| I mean, OCaml's autoformatter just autoformats arbitrary
| Ocaml files. How do you blow that out of the water?
| pharmakom wrote:
| Interesting you came to that conclusion. I liked Rust when
| I tried it, but it is definitely less productive and
| ergonomic than F#. Of course the memory overhead in Rust is
| much more predictable and generally lower, which might be
| an important factor for you.
| TylerE wrote:
| This I buy. I've never quite gotten why the rust crowd thinks
| manual memory management and zero cost abstractions are the
| only bullet points that matter. Many of us would happily switch
| to a language that didn't have either, if it made our day to
| day work not feel like rocket science and the sharp edge of the
| "never write code as cleverly as you can, because you won't be
| able to debug it" adage.
| steveklabnik wrote:
| > why the rust crowd thinks manual memory management and zero
| cost abstractions are the only bullet points that matter.
|
| I don't think that's an accurate characterization of "the
| Rust crowd," but even if we do take it at face value, it
| would make sense: Rust was intended for the layer of the
| stack where these things _do_ matter. Even though Rust has
| broken out of that initial layer, as the post demonstrates,
| culturally these things are likely to hold a bit more value
| than they may otherwise.
| cmrdporcupine wrote:
| Well, because as others have pointed out, languages like that
| have existed for at least a couple decades. Most of the 'nice
| parts' of Rust are really borrowings from the ML family of
| languages: Hindley-Milner type inference, algebraic data
| types, and pattern matching.
|
| OCaml or StandardML, (or Haskell if you want to get funky ...
| I don't), F#, Scala, etc.
|
| Hell, these days even Swift, or Kotlin, have these features.
| Which I'd call: modern static type systems.
|
| And I understand even Java is getting some of them. Even
| TypeScript is a reasonable-ish solution with a pretty nifty
| type system, if you don't mind the (non-existent) threading
| model.
|
| I like Rust, but its niche is: the above nice things and a
| clean syntax, but without the latency&pause costs of GC. And
| that's what I use it for, when I need that kind of thing, for
| systems programming. And for that, the killer feature is the
| borrow checker which makes using the above features
| relatively painless, despite having no GC.
|
| (Now one other advantage of the borrow checker is its
| application to concurrency -- making ownership of locks, and
| mutable state generally, easier to reason about. That's
| perhaps a killer feature that the other languages I mentioned
| don't really have)
| smolder wrote:
| Memory management/performance are just among the most obvious
| points of comparison when looking at Rust versus other
| languages. Ergonomics come up too, though less often, and
| with less agreement on how good they are, since it's a pretty
| subjective judgement on a mixed bag of features and syntax.
| TylerE wrote:
| If they frequently come up I think that says exactly how
| good they are.
| arch-ninja wrote:
| Guarantees about those things are impossible to add after a
| language/community abandons them, and you can
| Arc::<RWLock<T>> your way to writing Java pretty fast. I hold
| that keeping the strongest-possible abstractions is the best
| decision, even if that means your average developer needs to
| learn borrow checking. I've started a career writing Java,
| spent a year with Rust, and when I came back to Java my data
| structures were 5x as useful. I could spit out features
| _WITHOUT_NULLPOINTER_ISSUES_ in hours where previously it
| would have taken a week.
|
| Yes there is a skill gradient, but everyone who doesn't climb
| that hill is a fool and a weaker team member for it in my
| opinion.
| paxys wrote:
| Wanted to point out one potential side effect of their primary
| point. If you have a team of system developers fully proficient
| in Rust, and the next task is to build some middleware web API,
| Rust could seem like an obvious choice, because everyone on the
| team already knows it and loves it. However, unless you plan on
| having these developers work on web APIs forever, there is now a
| huge barrier for future hiring because none of the millions of
| developers out there with experience in C#, JS, Java, Go, Python
| and the like are qualified to work on this simple backend. You
| have narrowed down your hiring pool to expert Rust developers
| even though all you need is a new college grad who can start a
| Flask server.
| JohnFen wrote:
| > You have narrowed down your hiring pool to expert Rust
| developers
|
| I don't think that's really that big of a deal. Any above-
| average developer should be able to become useful in a new
| language in a pretty short period of time. They don't have to
| know the language on day 1, they only have to know how to
| develop software.
| zeroxfe wrote:
| That sounds reasonable in theory, but doesn't work out in
| practice.
| re-thc wrote:
| In practice we already have our hands full learning the
| domain unless it's a completely greenfield project. Working
| out the language and its frameworks makes it exponentially
| harder when coming into a project.
| JohnFen wrote:
| I've seen it work in practice plenty of times. It does take
| a particular sort of dev, though.
| hot_gril wrote:
| It's not about learning the language itself, it's about
| learning the tooling and libs associated with it, and that
| takes time.
| fnordpiglet wrote:
| Why can't candidates learn rust? I've never hired people based
| on specific language skill set. Any skilled developer should be
| able to learn any language.
| nivenkos wrote:
| Rust isn't magic, you can become reasonably proficient in a
| couple of weeks just as with any other language.
| [deleted]
| Klonoar wrote:
| You do not need an expert-level Rust developer for a backend
| web server. The hiring pool isn't really a big deal here.
| steveklabnik wrote:
| At Oxide, we do "web API layer" stuff in Rust. We also don't
| require that candidates be Rust experts, though obviously
| experience helps. Many of those people who are "proficient in
| C#, JS, Java, Go, Python and the like" can absolutely write
| Rust, even if there is some slowness at first.
|
| You have to be willing to believe that and consider it when
| hiring, of course, which some organizations may reasonably not
| be willing to.
| tiffanyh wrote:
| Off-topic: has Oxide shipped anything yet?
|
| Geniunely curious since the company was found 3+ years ago
| (2019).
|
| https://oxide.computer/blog/introducing-the-oxide-
| computer-c...
| steveklabnik wrote:
| Server racks? Not just yet! Soon though. As we get closer,
| we've talked about it more and more, see this recent Oxide
| and Friends, for example:
| https://oxide.computer/podcasts/oxide-and-friends/1200412
|
| We also have a ton of projects on our GitHub, including the
| web framework we developed for our API that I'm alluding to
| above. Of course, that's not the core product, but you can
| see what we've got going on.
| dsincl12 wrote:
| Would that be dropshot you're referring to?
| steveklabnik wrote:
| Dropshot is the framework, omicron is the control plane
| implementation, which uses dropshot.
| makestuff wrote:
| Not sure if rust is significantly harder to learn than Go,
| but as a Java dev I was able to pickup go and make
| contributions in around a week or so. Yeah I was slower, but
| we had some really good Go devs who had all of the tooling
| and packages laid out with best practices. This made it easy
| for new devs to jump into it.
|
| I think the issue happens when you have a new
| rust/go/javascript/etc. dev trying to setup a project for the
| first time.
| moonchrome wrote:
| Yes Rust is significantly harder than go. It's
| diametrically opposite if there was a circle of complexity.
|
| I honestly have no clue how someone without low level
| experience (eg. never did systems level programming) even
| approaches Rust.
|
| The ownership model makes sense to me but if I had to grok
| manual memory management and rust abstractions on top of it
| at the same time I think I would be unable to contribute
| even trivial stuff for a month.
|
| Oh and coming from a dynamic language background at that ?
|
| Not saying can't be done just saying time till contributing
| is probably weeks-months.
|
| With go it's probably days.
| nicoburns wrote:
| > I honestly have no clue how someone without low level
| experience (eg. never did systems level programming) even
| approaches Rust.
|
| I started by reading the Rust Book. It explains most of
| the low-level concepts. It took me about a week of mostly
| just learning and experimenting, and another ~3 weeks
| until I had an MVP of my system. But from there it was
| just another 2 months until I had a full system written
| and in production, which it would probably have taken in
| another language anyway (as the project involved a lot of
| trial and error reversing a (simple but) only partially
| documented format).
|
| Perhaps it helps that I came from JavaScript where a lot
| of the abstractions are similar.
| iudqnolq wrote:
| > I honestly have no clue how someone without low level
| experience (eg. never did systems level programming) even
| approaches Rust.
|
| In my personal experience you do this by writing your
| programs in such a way as not to require complex
| ownership. I had an easy time writing web services where
| the only cross-request shared state was a database
| handle. I had a hard time when I had to write a websocket
| document sync serverwhere I needed per-document global
| state shared between all the handlers, and I eventually
| gave up and moved to a model where a language with an
| easier concurrency story called rust code.
| whitepoplar wrote:
| How long would you say it takes your average, competent
| developer to become proficient in Rust? In your experience,
| what's the best path to learn Rust in 2023?
| eYrKEC2 wrote:
| My current employer has a web backend and CLI in Rust. I
| joined the company having only dabbled in Rust, but having
| a background in C++, python, javascript, and verilog. It
| took me a month to feel able to do things and 3 months to
| feel reasonably comfortable. Still haven't mastered it
| after 1.5 years. Certain pieces of the rust ecosystem have
| their own learning curve such as diesel orm.
| arch-ninja wrote:
| 6 months if you're a college-sophmore-level student doing
| it part-time (my own experience + numbers), I'd estimate
| 3-4 weeks if you were spending more than 3hrs/day on it and
| knew 2 other languages.
| oneplane wrote:
| That would be my estimate as well. I've seem some porting
| between Go and Rust (both ways) where either way an
| experienced developer with some multi-language knowledge
| got up and running in a day, writing useful code in a
| week and being proficient enough to do normal sprint work
| in about another week.
|
| It mostly depends on what you have in you brain, what you
| see when you look at code, and if you understand why you
| do what you do rather than repeating a trick and hoping
| it works, and I suppose that is a combination of theory
| and experience.
| steveklabnik wrote:
| > How long would you say it takes your average, competent
| developer to become proficient in Rust?
|
| I think it's exceedingly difficult to make such a broad
| generalization. There's a number of factors here at play,
| but for example, I think the struggles of a Rubyist
| learning Rust are very different than a C developer
| learning Rust, and are very different than someone who's
| proficient with both who is learning Rust.
|
| It's also hard because there's also just other random
| factors. There's a semi-common experience where people try
| Rust, think it's too hard, quit, and then come back 3 or 6
| months later, try again, and are completely unstuck.
| Sometimes it takes coming back two or three times. Do you
| count all of that dead time? Something in there helped, but
| it's unclear what, or why this affects some people.
|
| Another theme of stories I've heard is a sort of Golidlocks
| situation about how "right" you think the compiler is. Some
| folks have the attitude that the compiler is to be seen,
| not heard, and should stop nagging them about things. Those
| folks tend to _really_ struggle with Rust, even if they
| have lots of relevant experience previously. Likewise, some
| folks trust the compiler _so completely_ that they will
| lose a bunch of time when a compiler suggestion leads them
| down the wrong path. Luckily, that problem is easier to fix
| than the former one, and is rarer and rarer every day. But
| these sorts of attributes are completely separate than what
| we think of when we talk "competency" of devs.
|
| > In your experience, what's the best path to learn Rust in
| 2023?
|
| This sounds tautological, but bear with me: it's whatever
| path gets you to learn Rust. That sounds trite but what I
| mean is that different people have different needs (see
| above) and so need different things. There is no one best
| way. For some people, the book works really, really well.
| For others, they either hate the writing style, or the
| pace, or just something ineffable. I wouldn't say that
| they're wrong for that, just that they'd be served by
| different strategies.
|
| What I will say is that "I know other languages, I can just
| kinda start coding and pick it up" tends to not work for
| almost anyone. You either need to be quick to ask questions
| from the community, or be willing to do some reading, or
| you may run into some struggles that will take you longer
| to overcome than if you were willing to get some help.
| Folks who take advantage of community resources, broadly
| speaking, tend to do better than folks that think they can
| write some code and learn solely through errors, as Rust's
| semantics are just unique enough that some background and
| explanation can be extremely helpful.
| gonzo41 wrote:
| This is a very good point on thinking about engineering
| sustainability
| mrits wrote:
| If a recent college grad can't learn rust quickly the rest of
| us have no hope.
| imron wrote:
| > You have narrowed down your hiring pool to expert Rust
| developers even though all you need is a new college grad who
| can start a Flask server
|
| On the plus side, if you hire someone who isn't an expert Rust
| developer and they mess things up, it will break at compile
| time instead of at runtime.
|
| Assuming you still have _some_ Rust developers at your
| workplace, and assuming the new developer is not completely
| incompetent, they should be able to get up to speed before too
| long.
| BFLpL0QNek wrote:
| This argument gets posted for nearly every [insert language
| name] that isn't JS/Java/Python.
|
| It's not to hard to learn. The Rust web stack is fairly simple
| and easy to get going with in a few days. Good developers use
| many languages and enjoy using many languages. If you drop the
| usual requires ten years experience you have just increased
| your hiring pool to a bunch of people who are excited to learn
| so will often put in the hard work to learn.
|
| It's a bit disrespectful to think a new grad can't use a
| language other than JS/Python and they'll be more productive in
| JS/Python. How little do you think of grads?
| hot_gril wrote:
| I think highly of the new generation and would consider a
| good new grad about as good as me (a senior-level SWE age
| 26). My experience with fully learning and using Rust is that
| it's a constant burden for high-level work no matter how well
| you know it. Similarly with C++, except that is even worse.
|
| Rust has its place for things that need to be especially
| optimized. It's far too pedantic for the kind of things you
| can do in NodeJS or Flask. New grad would be annoyed, and so
| would I.
| AA-BA-94-2A-56 wrote:
| I don't know a whole lot about Rust, but if the pedantism
| is related to syntax, wouldn't current AI-assisted
| programming tools be able to help with that?
|
| I've had GPT-4 explain to me weird niches in Django that I
| don't understand, because I'm coming from a Javascript
| background. It'll pick up what I'm trying to do, give me
| the code I'm trying to write, and tell me where I went
| wrong.
|
| In the process I learn a lot, and waste a lot less time
| trawling Stack Overflow and parsing other people's code and
| closed threads.
|
| It's a lot like having a more experienced developer over my
| shoulder.
| hot_gril wrote:
| To answer your question, yes. This is also what I try to
| hint people at work who refuse to move past the "real
| programmer" languages, most of their talent is very soon
| replaceable by GPT.
|
| Idk if you'd call it syntax or what, but what makes Rust
| pedantic is that you're always worrying about lifetimes,
| types, explicit errors (as opposed to exceptions), and
| other things you mostly don't think about in JS or Py.
| It's like C++ only nicer and safer. People aren't using
| JS/Py because they're unskilled, it's because they don't
| want to waste time. Of course Rust or C++ makes plenty of
| sense for lower-level stuff or anything that needs to be
| especially optimized.
| [deleted]
| [deleted]
| notyourday wrote:
| Because it is Resume Driven Development.
|
| Luckily, the layoffs are good at curing the RDD virus.
| sealeck wrote:
| I think this is a really cruel thing to say.
| goodpoint wrote:
| Don't you know that HN is rust fanboy paradise?
| tetraodonpuffer wrote:
| I would have been interested if the author had expanded on how
| they planned to use the borrow checker to avoid multiple
| listeners using the same IP address. I haven't used rust much
| outside of some self learning but in other language I'd simply
| mutex/lock, how can the borrow checker at compile time validate
| that each listener cannot get the same value of a hash set?
| jamincan wrote:
| He does explain it in the article:
|
| - use `&mut` references to allow the borrow checker to
| statically enforce only one reference to the IP exists at a
| time (the major unique feature of Rust is the borrow checker
| which basically only allows one mutable reference at a time
|
| - use an `UncloneableIp` new type that doesn't implement
| `Clone` to prevent the IP from being copied
| tetraodonpuffer wrote:
| I might be dense, but I still don't get how it works: I put
| the 10 addresses in a HashSet, and I have some function that
| I want to be able to exclusively use one of them, how do I
| write the constraints to make the borrow checker be able to
| enforce this at compile time?
|
| I understand the two statements above in the article, just
| not how they can be made to work in this case. Apologies
| again if this is an obvious question, as I was saying I am
| definitely just starting out in rust.
| jdjb wrote:
| The HashSet would be the owner of the IP address type. Your
| function would call the "take" method of the HashSet to
| take ownership of the IP address. Now the IP address cannot
| go back into the HashSet unless you give ownership back and
| no other thread/caller can take ownership.
| justincredible wrote:
| [dead]
| agentultra wrote:
| A lot of these bullet points apply equally well in Haskell.
| Automatically derived JSON serialization from records, typed (and
| compose-able) SQL queries, whole-program feedback from the
| compiler; etc.
|
| Especially the all-important advice: use Haskell when everyone on
| your team uses and wants to learn Haskell! Can't stress that
| enough. From experience, even when a language has all of the
| technical features to merit consideration for a project, what
| your developers are _already_ familiar with will trump them all.
|
| I wish it were a purely technical decision what language to use
| for a project but it's not. "Use the right tool for the job," is
| not the right advice for choosing a language. It's a
| social/network-effects type of decision.
| bitL wrote:
| Haskell is cute until somebody in the team starts using the
| most advanced parts in some common task, destroying team's
| ability to understand what's going on and make changes; in a
| few years the author of such code will have the same problem
| (one's brain won't keep PhD-level capabilities the whole life).
| The same issue hit Scala development and led to complete
| rewrites back to Java or similar.
| dboreham wrote:
| Rust is cute until you notice your project build creates 50GB
| of ... something.
| spion wrote:
| Haskell doesn't have the documentation / doctest / code
| examples culture of Rust, cargo is arguably a better experience
| than any of the Haskell package management options (at least
| last time I checked) and I don't believe rust-analyzer is
| matched by anything in Haskell as a language server.
| mercurial wrote:
| The culture and ecosystem should definitely be a huge part of
| selecting a language.
| ijlx wrote:
| I haven't written more than a few pet projects in Haskell,
| but in my experience haskell-language-server is quite
| fantastic. I agree though that cargo has been a better
| experience for me, and while the documentation for Haskell is
| better than I would have expected, it certainly doesn't match
| up to rust.
| BWStearns wrote:
| 1000% this. Having worked in Haskell and having learned rust
| the past couple years. I love Haskell, but Rust really
| married a ton of the good parts of Haskell with a lot of
| "soft skill" elements that allowed it to graduate beyond
| being mostly a research language. It matters that in Rust I
| don't need to go read some blog posts about type theory if I
| want to make an API endpoint. It's not even that Haskell the
| language requires that, Haskell the culture requires that
| because there aren't (or at least weren't a few years ago)
| that many people promoting practical Haskell.
| TylerE wrote:
| And oh boy if you thought rustc was slow...
| noelwelsh wrote:
| Yes. About 2/3rds of the points rely on underlying language
| features of algebraic data types, type driven metaprogramming,
| and linear / affine types. Haskell has all of those, although
| linear types are still experimental. Scala has all of them
| apart from linear types (which have been explored at various
| times but are not officially part of the language.)
| imachine1980_ wrote:
| Social/network-effecst are critical part of the rigth tool, I
| read a blog about a companies who regret using rust becouse was
| impossible gey people whit experience in rust like the
| founders.
| mastax wrote:
| I heartily agree with the conclusion. It's not worth learning
| Rust to write your REST API (with the possible exception of code
| that needs to be very reliably fast, like starting a new HFT firm
| from scratch). But if you already know it the strengths balance
| out the weaknesses.
| falcolas wrote:
| To me, the answer will always boil down to "because we want to"
| for varying definitions of "we".
|
| This choice is almost always more about the team than the
| technology, regardless of the specific language or framework or
| widget.
| alex_lav wrote:
| I wish this was less of a contentious conversation. Liking a
| piece of technology and being able to derive maximal value from
| it is like 90% of the battle. If your team dislikes a tool,
| they'll use it suboptimally. All of the song and dance around
| why some language or framework is better than all the others is
| usually irrelevant - a team that hates Rust but tries to use it
| will derive less value from their tooling than a team that
| loves PHP. It's not rocket science, and preference isn't a bad
| thing.
| falcolas wrote:
| Catering to a teams preference also gives you a free morale
| boost.
|
| And in the current economy of random mass layoffs, any morale
| boosters you can find will matter more.
| RaiyanYahya wrote:
| I picked up Go quite fast but its quite different with Rust. The
| learning curve i feel is steeper.
| Pepe1vo wrote:
| > Building a model of the SQL type system within the Rust type
| system is very impressive work. It also leads to really annoying
| problems, because the Diesel types are so complex.
|
| Oh man have I felt this pain, trying to do anything mildly
| complex with Diesel's types is so ridiculously difficult. I once
| (foolishly) tried to write a generic repository implementation
| for database entities which could either have sqlite or postgres
| as a backend. I thought this would be very convenient for
| testing, being able to just keep all of the code the same safe
| for using a sqlite backed repository instead of a Postgres one.
|
| I gave up after about ~10 hours of battling incomprehensible
| error messages.
| hot_gril wrote:
| I've given up on trying to wrap SQL in any way. Too many bad
| experiences. I just use it as-is with fully dynamic types. My
| go-to stack is Postgres + NodeJS, no Typescript. No query
| builders, no ORMs especially. Postgres is meant to be used on
| its own with a minimal client lib. It works beautifully.
|
| And my system is safer in the end because I take that time I
| would've spent fighting the type system / tooling and instead
| spend it writing integration tests. I get to do full TDD often.
| And the bugs I catch are never due to mishandled types.
| thallada wrote:
| It really sucks when you are the only one on your team that knows
| Rust. I whole-heartedly think that I'd be more productive and
| write better backend code in Rust than
| JavaScript/TypeScript/Python/Ruby from my experiences of using
| Rust in side-projects. But I have to suffer because I cannot make
| the case of rewriting our backend and teaching all the devs Rust.
|
| So my only choice if I want to use Rust is to leave the company,
| but it's really hard to find other companies that primarily use
| Rust. The majority of the ones that do are crypto/blockchain
| related or doing something extremely low-level or out of my
| wheelhouse since they assume you're also comfortable with writing
| C++. I'm primarily a web developer and I hardly see any web
| startups choosing Rust.
| [deleted]
| hot_gril wrote:
| We need to do that movie thing where two people switch places
| and pretend to be each other, that way we swap jobs. Cause
| where I work, we write web backends in C++ purely because
| people there want to use a "real language." Not only do I hate
| it, but they have a hard time hiring people cause all those
| kinds of candidates want to do lower-level stuff.
| [deleted]
| paulgb wrote:
| Glad to see serde mentioned as a top-level item here. It's a huge
| timesaver for anything that sends data over the network or
| persists it to disk.
| Reitet00 wrote:
| Very nice post even though they're always in this form of "here
| is my 10 favorite Rust features". Another one along the same
| lines: https://cloak.software/blog/i-built-startup-in-rust/
|
| > 95% of the unwraps in our codebase are in unit tests.
|
| There's a crate for that: https://crates.io/crates/testresult
| malkia wrote:
| This works until you have to integrate with third party solution
| to exchange data, then you end up needing to "externalize" the
| data, and why not from there start with
| protobuf/flatbuffers/capnproto/etc. For each of these one can
| rewrite a more optimal (perf sensitive) writer, but missing some
| functionality (e.g. append/write only protobuf with zero
| overhead).
|
| Granted, for their task this was over complication, but if they
| were doing ads (or something similar) it always needs ways to
| structure your data, and then you end up needing something
| hierarchical, typed, extensible with backward and forward
| compatibility (e.g. in protobuf for example, never reuse already
| used index field, etc.)
___________________________________________________________________
(page generated 2023-03-20 23:01 UTC)