> its actor implementation is not built upon Erlang/OTP
This seems to be the opposite of pragmatic.
The most pragmatic approach to actors when you're building a BEAM language would be to write bindings for OTP and be done with it. This sounds kind of like building a JVM language with no intention of providing interop with the JVM ecosystem—yeah, the VM is good, but the ecosystem is what we're actually there for.
If you're building a BEAM language, why would you attempt to reimplement OTP?
Because of type safety. The OTP lib is already great, but there are still some things missing, most requested being named processes. But there is work being done to figure out how to best make it work for gleam.
The question of type safety has come up so often here that I guess it's worth replying:
That's exactly what I mean by this not seeming pragmatic. Pragmatic would be making do with partial type safety in order to be fully compatible with OTP. That's the much-maligned TypeScript approach, and it worked for TypeScript because it was pragmatic.
Now, maybe Gleam feels the need to take this approach because Elixir is already planning on filling the pragmatic gradually-typed BEAM language niche. That's fine if so!
Type safety is one of the goals of the language I don't see a reason to throw it out of the window now. I see what you mean, but the type system is one of the things that makes gleam pragmatic. If you really need some missing OTP feature you can super easily step into Erlang using FFI and get it. That's one of the reasons the article doesn't call gleam pure.
And what has this approach gotten them? A language as complex as c++ and haskell combined, but that still has runtime type errors. A typescript backlash is coming.
It uses the same primitives as Erlang, the difference is that it exposes type safe APIs instead of untyped ones which you would get from using the Erlang abstractions.
It implements the same protocols and does not have any interop shortcomings.
I agree with the part about reusing OTP but some of the server syntax of Erlang and Elixir is not good IMHO. I never liked using those handle_* functions. Give them proper names and you cover nearly all the normal usage, which is mutating the internal state of a process (an object in other families of languages.) That would be the pragmatic choice, to lure Java, C++ programmers.
Elixir gives you Agent, which is what you want, but for reasons, Agent is a bad choice.
What you're not seeing with the handle_* functions is all the extra stuff in there that deals with, for example, "what if the thing you want to access is unavailable?". That's not really something that for example go is able to handle so easily.
defmodule Robot do
def handle_call(:get_state, _from, state) do
something()
end
def get_state() do
GenServer.call(__MODULE__, :get_state)
end
end
robot = Robot.start_link()
robot.get_state()
just let me write (note the new flavor of def)
defstatefulmodule Robot do
def get_state() do
something()
end
end
robot = Robot.new()
robot.get_state()
Possibly add a defsync / defasync flavor of function definition to declare when the caller has to wait for the result of the function.
The idea is that I don't have to do the job of the compiler. It should add the boilerplate during the compilation to BEAM bytecode.
I know that there are a number of other possible cases that the handle_* functions can accommodate and this code does not, but this object-oriented-style state management is the purpose of almost all the occurrences of GenServers in the code bases I saw. Unfortunately it's littered by handle_* boilerplate that hides the purpose of the code and as all code, adds bugs by itself.
So: add handle_* to BEAM languages for maximum control but also add a dumbed down version that's all we need almost anytime.
Ok, I kind of see what you're saying, but IMHO, you're trying to hide the central, enabling abstraction of BEAM environments, which is sending messages to other processes.
If you really don't like the get_state above, I think it'd make more sense to just ditch it, and use GenServer.call(robot, :get_state) in places where you'd call robot.get_state(). Those three lines of definition don't seem to be doing you much good, and calling GenServer directly isn't too hard; I probably wouldn't write the underlying make_ref / monitor / send / receive / demonitor myself in the general case, but it can be useful sometimes.
In my experience with distributed Erlang, we'd have the server in one file, and the client in another; the exports for the client were the public api, and the handle_calls where the implementation. We'd often have a smidge of logic in the client, to pick the right pg to send messages to or whatever, so it useful to have that instead of just a gen_server:call in the calling code.
In the early days of Elixir what you are proposing here was popular[1], but over time the community largely decided it wasn't beneficial and I rarely see it any more.
It is production ready and has been used for numerous non-trivial projects. Experimental in this context means there is expected to be API changes and feature additions in future.
Glad someone else already posted it. I understand if Nix is too much for folks, but it repeatedly is absolutely end-game for stuff like this. I have centralized, unified dotfiles, with all of the power of Nix to have one-off config flexed in. No extra templating or hacky interpolation.
well doesn't the argument suggest the only thing you can be certain of is I, or at least some 'experiencing agent' exist, otherwise there would be no subject to do the experiencing
Yeah the first-person subjectivity has to arise before second and third persons can arise. But with some further investigation, one can find that the things they take to be their subject are in fact object to them, too.
I've not tried this for any adobe products, but you could try running them in a locked down environment (container, vm, whatever) and don't allow network access.
Adobe Creative Cloud apps stop working after a while if they can’t phone home. Adobe Creative Suite apps do not.
“After Adobe Systems' acquisition of Macromedia in December 2005, Dreamweaver 8 was added to Adobe Creative Suite 2.3 and was later succeeded by Adobe Dreamweaver CS3.“ [1] (Replacing Adobe GoLive, good riddance)
So you could use up to Dreamweaver CS6 with just a serial number (usually requiring one-time internet activation), but anything newer requires regular internet access.
Guaranteeing a singleton process is a very difficult problem which horde definitely does not solve perfectly mind you.
All is well and good until it isn't. We opted for leveraging different mix release permutations deployed on k8s as needed instead.
Definitely takes more effort than what you describe, and has its own issues... But imo definitely better understood than fighting weird state with horde
You are technically 100% correct, however the bultin object system in Javascript is so bad that a reasonable argument can be made that it's not particularly accessible or ergonomic to many of the folks who actually write it for a living.
I know lots of folks here on HN are super highly competent, and this contrasts with my IRL experience with colleagues who are less passionate about programming and just want to do their job- these folks aren't going to be teaching lessons in proper usage of objects in JS.
It’s hard to tell, but are you referring to prototypical object inheritance here? If so, JavaScript has long since implemented more traditional class definition ergonomics, such that explicit prototyping is almost largely unused in modern codebases.
In truth, even classes are becoming increasingly uncommon in JavaScript codebases, and most object usage in JS these days is struct-like, where the ergonomics are pretty similar (or identical) to other languages.
You mean install docker in the WSL2 installed distribution directly ?
I run a Ubuntu 20.04 WSL2 vm. It does not seem very easy to install it directly in the vm, for instance there is no systemd. There is the reddit post about it and most recommend to install docker desktop.
It doesn't come with any styling OOTB. The idea is that you're just building a frontend (all the markup, styling etc) around some provided state management
`react-table` is headless. I am forced to create my own html structure and am in control of the markup from the start. `headless-ui` provides those components which doesn't give me full control over markup, does it?
