[HN Gopher] `async: false` is the worst
___________________________________________________________________
`async: false` is the worst
Author : lobo_tuerto
Score : 20 points
Date : 2024-03-26 17:52 UTC (1 days ago)
(HTM) web link (saltycrackers.dev)
(TXT) w3m dump (saltycrackers.dev)
| jbm wrote:
| > async: false is the worst
|
| I suppose the reason is because it takes more time? (The article
| doesn't mention, and just takes it as a given)
| scythmic_waves wrote:
| > I suppose the reason is because it takes more time?
|
| I assume so. I didn't even notice that the article didn't
| motivate that `async: false` is bad. I always avoid it if I can
| since you might as well perform independent tests concurrently.
|
| From the docs [1]:
|
| * `:async` - configures tests in this module to run
| concurrently with tests in other modules. Tests in the same
| module never run concurrently. It should be enabled only if
| tests do not change any global state. Defaults to `false`.
|
| [1]: https://hexdocs.pm/ex_unit/main/ExUnit.Case.html#module-
| tags
| kevingadd wrote:
| I wouldn't have expected this much dependence on global state in
| erlang software. I thought erlang was all about encapsulation,
| but I guess some problems are basically universal to production
| software no matter what language you use, and global state is one
| of them
| jerf wrote:
| You have to be careful about your definition of "global state".
| We kind of have this definition based on C programs from the
| 1970s, but it doesn't always trivially translate into more
| modern architectures. BEAM programs (Erlang/Elixir) are
| basically microservice architectures by default. They lack
| global state in the sense that there is no way for process (in
| the BEAM sense, not the OS sense) A to reach into process B and
| directly manipulate the values. That is the form of isolation
| that BEAM and its accompanying languages offer. But for any
| network architecture to function, there's always going to be
| unique identifiers for the actors within the network, and that
| is intrinsically at a higher level than a single process. It
| doesn't have to be "global", in that two processes may have a
| different idea what it reaches if it asks for "leader", but
| it's certainly bigger than the single process. And yeah,
| there's not a lot that can be done about the fact that's going
| to be somewhat global, and if the identified network targets
| are not in the local OS process, intrinsically mutable in the
| sense that the state of those services can at the very least go
| down without notice.
|
| In the modern world there are many useful definitions of
| "global state", some of which as I suggested may not even be
| "global" but may be in some scope that lives between "global"
| and "local", and depending on which definition you choose,
| various languages may have different "globalnesses" in their
| state.
|
| (Another common example is, "does the language have global
| variables?" Many languages have the concept of "packages", that
| you can import once into the system, and everyone will see the
| same "print" package. That package may have variables, like for
| example maybe "print.default_format". Is that a _global_
| variable? Well, in the old C sense, maybe not.
| "default_format" can not be reached simply with
| "default_format" from all locations in the program, such that
| is globally defined. It can't be reached at all from places
| that did not import "print". But if what you're concerned about
| is whether changes made by one module are witnessed by all,
| they are, so from that sense it is a modern global variable,
| even if more nicely organized than traditional ones. There
| isn't a right or wrong answer here, it depends on the
| definition you choose which answer you get.)
|
| In general, immutability at the value level does not
| automatically make things encapsulated. It more easily affords
| it, but it doesn't just happen.
| Quekid5 wrote:
| I think a slightly more succinct way of thinking about
| mutability in actor systems is this: (I _think_ it 's from
| Erik Meijer, but not quite sure.)
|
| Ultimately, any actor system has global mutable state via
| message queues. You can perfectly emulate a shared mutable
| variable by just sending it back and forth between message
| queues. (At least it's only atomically modifiable, I
| suppose.)
|
| It's very different from _abient_ authority to modify a
| mutable variable, but still...
| madsbuch wrote:
| this can be using a test database for integration tests, etc.
|
| at least it is in these situations I have had to consider the
| async setting.
| loeg wrote:
| (Elixir)
___________________________________________________________________
(page generated 2024-03-27 23:02 UTC)