bitwalker

9 ms·

31.
by bitwalker 3y ago
I worked on F-16 avionics (in aircraft maintenance, on the flightline), there are a lot of little nooks/holes/slots/gaps where small bits of FOD can fall and be incredibly difficult to extract, and the fear of that FOD causin
32.
by bitwalker 3y ago
> If we pretend the Supreme Court is partisan, which it is not but let's entertain that thought here.. I mean, that’s laughable, I don’t know how anyone can call the current Court non-partisan with a straight face. That doesn’t mea
33.
by bitwalker 3y ago
What are you talking about? I’ve been on the same dosage for over 12 years, and it is just as effective for me today as it was on day 1. Still waiting for those consequences I guess..
34.
by bitwalker 4y ago
The BEAM is so much more than just a green thread runtime - and it is not straightforward at all to just "bring it over" to another virtual machine, the entire BEAM VM is designed around the scheduler, and core features such as si
35.
by bitwalker 4y ago
I mean, the BEAM doesn't have global GC pauses either, as each process has its own heap - but I would expect Pony can take things a step further as a result of its strong type system, which IIRC is why it can support zero-copy messagin
36.
by bitwalker 4y ago
I really strongly doubt that GC is a bottleneck for Erlang programs on either the BEAM or the JVM - the sophistication of the scheduler, and the way various language primitives interact with it, is where the BEAM is almost certainly gaining
37.
by bitwalker 4y ago
Erlang only uses reference counting for binaries larger than 64 bytes, everything else is allocated on the process heap (or in heap fragments) and copied. Just that is enough to have a beneficial effect though, since large binaries are rela
38.
by bitwalker 4y ago
I think that's largely an implementation detail, so not a requirement as far as I know. That said, delimited continuations certainly make them easier to implement, as I understand it.
39.
by bitwalker 4y ago
If you are handwriting the function in assembly, you'll know what registers hold the function parameters, what types of values they are supposed to be, and with care, you can produce debug information and CFI directives to allow for st
40.
by bitwalker 4y ago
Erlang checks for overflow after arithmetic ops are performed internally (IIRC), so you are generally only penalized when overflow actually occurs and requires promotion, which probably isn’t much different in performance from a language th
41.
by bitwalker 4y ago
Erlang binaries on the other hand are awesome, and the use of lists in what Erlang refers to as chardata/iodata is really nice when generating data that will be written to some kind of output device, since no preprocessing is needed to
42.
by bitwalker 4y ago
This is one of the things I'm personally excited about using Firefly for, since I first started working professionally with Erlang/Elixir, I wanted the ability to use it for CLIs. You can be sure it will be a use case well support
43.
by bitwalker 4y ago
The goal is to support all libraries, but because there are some out there that dynamically compile/load code at runtime, despite it being a bad idea, there will necessarily be some libraries that are not supported, at least in the nea
44.
by bitwalker 4y ago
> How do you plan on ensuring your compiler tracks updates introduced by major Erlang releases? Will there be features introduced in the Erlang runtime (I'm thinking things like Erlang 21's `atomics`) that won't be immedia
45.
by bitwalker 4y ago
Smaller code size was the goal; and BEAM bytecode adds up quick, even compressed. For example, the BEAM files for _just_ Ecto come out to about 1.2M in an uncompressed tarball, but in a gzipped tarball at maximum compression is still 799K.
46.
by bitwalker 4y ago
When I say hot code loading, I’m really specifically referring to how that works in the BEAM, which is a more sophisticated mechanism than simply compiling/generating code on the fly. The biggest problem though is that it prevents most
47.
by bitwalker 4y ago
Thanks! I’ll put some together in the next couple days just to make sure it gets done, so even though running those apps may not work (depending on what’s used), at least it’ll be easy to play with it.
48.
by bitwalker 4y ago
Speaking as the lead on the project, this is partially due to this weekend being ElixirConf, so things are hectic, but you can also blame me, as I probably should have written this post, but didn’t make the time as I was pretty heads down o
49.
by bitwalker 4y ago
It's not quite ready for that level of experimentation yet, we only recently got the compiler implemented, and there is much remaining in the runtime to finish up. There will be more announcements in the future related to the project,
50.
by bitwalker 4y ago
> Only AOT compiled native code, except targeting WASI. More precisely, a number of targets are supported, WASI would be just one. > Generally BEAM is understood to be slower of the big runtimes (compared against Java, CLR, Go and oft
51.
by bitwalker 4y ago
> What does this mean? Erlang/Elixir are AOT-compiled languages.. With the BEAM compiler today (and by BEAM compiler, they are referring to the compiler provided as part of the standard library shipped with the BEAM, it is just a wa
52.
by bitwalker 4y ago
It doesn't currently, but you are correct that the goal is to maintain feature parity with the BEAM (with explicit caveats to that, namely hot code loading). There actually is support for NIFs, just not via the erl_nif interface that N
53.
by bitwalker 4y ago
Correct, the BEAM is just one implementation of the runtime, there can (and have) been others. Firefly aims to be as close to the BEAM semantics as possible, but there will naturally be some differences as we're taking a different appr
54.
by bitwalker 4y ago
You don't lose OTP, because OTP is a library, written almost entirely in Erlang (not counting the set of NIFs/BIFs which provide intrinsic functionality), which we absolutely aim to compile with Firefly just like any other Erlang
55.
by bitwalker 4y ago
One example would be in a parser, as various parsing functions would be invoked recursively until end of input, or until some non-matching input is encountered. In pretty much any scenario where you would use recursive functions, it is quit
56.
by bitwalker 4y ago
Fred's blog, and Learn You Some Erlang for Great Good are invaluable, but on the topic of production systems, his ebook Erlang In Anger ( https://www.erlang-in-anger.com/ ) is excellent as well - honestly it's hard
57.
by bitwalker 4y ago
The Erlang Manual does a pretty good job of describing the system limits and how to configure them, as well as the failure modes of various components. By default, a mailbox will continue to fill up until process reaches its configured max
58.
by bitwalker 4y ago
I mean, if it doesn't count as an implementation of an actor system, then I'm not sure what does, regardless of whether it was incidental to the design goals of Erlang as a language. It certainly walks and quacks like an actor sys
59.
by bitwalker 5y ago
This isn't really an issue with threads though, the exact same issue is present in green thread/fiber implementations; it just so happens that in Async Ruby the GIL saves you from this specific problem due to making variable acces
60.
by bitwalker 5y ago
Just like in Erlang, you would handle that at the transport level, and it appears Swift supports providing your own transports. They didn't mention (or I didn't see) whether the transport they are shipping has any specific auth wr

More ›