3 ms·

> > It's always well worth your time to learn the rules for commonly-used, bedrock parts of a language, major libraries, and runtime systems that you intend to

by xlii 2y ago

> > It's always well worth your time to learn the rules for commonly-used, bedrock parts of a language, major libraries, and runtime systems that you intend to use. I disagree. I've been long enough around to see languages sunsetted, libraries sunsetted. Big systems are standing on shamefully old versions. If your job is to work on one language - I agree, but when working with 100s of systems that go over multiple OTP versions, multiple Elixir versions, sprinkled with JavaScript, TypeScript, Ruby 1.0, Elm, Java, "oh my dear is it Python 2 running CoffeeScript?!", then memorizing anything is pointless, because chance is that thing that you memorized is: - not yet in this project - no longer in this project - that tech isn't in the project - project is written in Malboge, everything you know is irrelevant - is explicitly forbidden by code owner (for more or less sensible reason) > Bedrock parts don't substantially change, because if they did, they would invalidate every program ever written against those parts. Been there, done that, bought a t-shirt. I dislike TypeScript for exact that reason [0], but in Elixir the same is true if you rely on --warnings-as-errors flag due to (in my opinion) broken deprecation mechanism. Software is full of leaky abstractions. Do you know that it's not guaranteed that your system clock is monotonic? [1] [0]: https://github.com/microsoft/TypeScript/wiki/Breaking-Changes https://github.com/microsoft/TypeScript/wiki/Breaking-Change... [1]: https://github.com/rust-lang/rust/blob/e2223c94bf433fc38234d1303e88cbaf14755863/src/libstd/time.rs#L205-L232 https://github.com/rust-lang/rust/blob/e2223c94bf433fc38234d...

simoncion 2y ago
> Do you know that it's not guaranteed that your system clock is monotonic? Yes. Wall-clock time is adjustable. That's why there's a monotonic clock function on any serious OS that's running on hardware that makes such a function possible. > ...but when working with 100s of systems that go over multiple OTP versions [it's not worth understanding how anything that's bedrock works]... Welp, let's go back to the behavior of 'supervisor' in 2007... the earliest version of that page of the docs that the Wayback Machine has: <https://web.archive.org/web/20070707071556/http://www.erlang.org/doc/man/supervisor.html https://web.archive.org/web/20070707071556/http://www.erlang...> Hey, look at this description and warning in 'terminate_child/2' > Tells the supervisor SupRef to terminate the child process corresponding to the child specification identified by Id. The process, if there is one, is terminated but the child specification is kept by the supervisor. This means that the child process may be later be restarted by the supervisor. The child process can also be restarted explicitly by calling restart_child/2. Use delete_child/2 to remove the child specification. Hell, read the rest of that document... notice that the behavior described from nearly twenty years in the past is the same as now. (And I bet you One American Nickel that the behavior described in 1997 is also the same.) If you don't consider that to be bedrock functionality and worth familiarizing yourself with, I don't know what to tell you.

by xlii 2y ago

simoncion 2y ago

> Do you know that it's not guaranteed that your system clock is monotonic? Yes. Wall-clock time is adjustable. That's why there's a monotonic clock function on any serious OS that's running on hardware that makes such a function possible. > ...but when working with 100s of systems that go over multiple OTP versions [it's not worth understanding how anything that's bedrock works]... Welp, let's go back to the behavior of 'supervisor' in 2007... the earliest version of that page of the docs that the Wayback Machine has: <https://web.archive.org/web/20070707071556/http://www.erlang.org/doc/man/supervisor.html https://web.archive.org/web/20070707071556/http://www.erlang...> Hey, look at this description and warning in 'terminate_child/2' > Tells the supervisor SupRef to terminate the child process corresponding to the child specification identified by Id. The process, if there is one, is terminated but the child specification is kept by the supervisor. This means that the child process may be later be restarted by the supervisor. The child process can also be restarted explicitly by calling restart_child/2. Use delete_child/2 to remove the child specification. Hell, read the rest of that document... notice that the behavior described from nearly twenty years in the past is the same as now. (And I bet you One American Nickel that the behavior described in 1997 is also the same.) If you don't consider that to be bedrock functionality and worth familiarizing yourself with, I don't know what to tell you.