this post was submitted on 23 Jan 2024
14 points (100.0% liked)
Fediverse
28396 readers
424 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to [email protected]!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Predictable in what sense?
If you say the function should only recieve one argument and returns always boolean. It is predictable to only allow the wanted args and forces you to return a boolean.
For example in a less predictable programming language e.g. Python: I can do all above but python does not stop anyone to put more or less arguments to a function, or a developer not adding typehints or not complying to them and return a string instead of a boolean.
But i had it wrong rust is similar to java on that part.
But still it is a lot more popular and easier to start with. So there will be a lot more contributor to sublinks than lemmy ever had.
Well in that sense Rust is even more predictable than Java. In Java you can always get back exception that bubbled up the stack. Rust function would in that case return Result that you need to handle somehow before getting the value.
That i dont understand? How can it be a result that i need to handle? If its not correct than java will throw an error. ( As expected, shit in shit out )
It's a great and probably the best error system I've seen, instead of just throwing errors and having bulky try catch statements and such there's just a result type.
Say you have a function that returns a boolean in which something could error, the function would return a Result<bool, Error> and that's it. Calling the function you can choose to do anything you want with that possible Error, including ignoring it or logging or anything you could want.
It's extremely simple.
If I except a boolean, there is an error and get a Result, is Result an object? How do I know if I get a bool or error?
You always get a Result. On that result you can call
result.unwrap()(give me the bool or crash) orresult.unwrap_or_default()(give me bool orfalseif there was error) or any other way you can think of. The point is that Rust won't let you get value out of that Result until you somehow didn't handle possible failure. If function does not return Result and returns just value directly, you (as a function caller) are guaranteed to always get a value, you can rely on there not being a failure that the function didn't handle internally.That's a kinda terrible way to do it compared to letting it bubble up to the global error handler.
You can also use optional in java if you want a similar pattern but that only makes sense for stuff where it's not guaranteed that you get back the data you want such as db or web fetch