Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp.
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.
Same here, I've only been using it for a bit and have 100% been ignoring the JS part and the only time where I felt I needed to think about it for a moment was when I was writing a patch for someone else's code that did not ignore it, so basically when contributing to a library you might have to do extra work.
Of course I can't say if anyone ever made any decisions based on the other target that would have repercussions for me only using the BEAM.
og:description is exactly the meta tag to use for link descriptions in embeds. Not all meta tags are only for search engines. The app acted correctly here.
It's basically what Phoenix LiveView specifically is. That's only one way to do it, and Phoenix is completely capable of traditional server rendering and SPA style development as well.
LiveView does provide the tools to simulate latency and move some interactions to be purely client side, but it's the developers' responsibility to take advantage of those and we know how that usually goes...
This is essentially what a ground source heat pump system is. Except instead of a sealed water tank you just make a tall hole that fills with water and the sun will warm it for you during the summer automatically.
1800 kWh is very little. We use around 12000 kWh and our neighbours' new house uses around 8000 kWh annually and most of that is heating. I'm not sure how many houses can hit 1800.
A ground source heat pump (also geothermal heat pump) is a heating/cooling system for buildings that use a type of heat pump to transfer heat to or from the ground, taking advantage of the relative constancy of temperatures of the earth through the seasons.
You can also recharge your geothermal well or ground heat collection field by heating the outgoing thermal collection liquid with either cheap electricity (rooftop solar?) or direct solar heat collection. I think this will be a growing thing as the earliest mainstream ground source heat wells start to be a few decades old. Many of them are sized so that they don't fully recover during the summer, so the heat output slowly drops.
A modern house in Finland needs around 15-24kWh a year of heat energy if it's well insulated. On the higher end for big + northern houses, and less if you're smaller and further south.
Some get this energy by burning wood, others with heat pumps, and some with direct electricity.
My 90sqm bungalow in the U.K. uses about 15MWh a year for heating - 1500 litres of oil, almost all in winter. Peak load is about 2.5kW over a day (60kWh)
I think you are off by about 3 orders of magnitude as my Austrian flat need about 7MWh a year for heating and 3MWh of electricity. I could generate 24kWh per year on an indoor bicycle.
Made me laugh though, when in the first level that it completely blocks, the director tells you to get close to a pickup, but the car you're chasing smashes the pickup to the sky like Team Rocket.
Last I heard there was a feature branch for testing a software implementation of floating point that would fix these issues, but naturally it would be a lot slower. I haven't tried it myself.
En and em dashes are easily accessible on both my laptop's and phone's keyboard layouts and I like using them, just like putting the ö in coöperate. It's sad if this now makes me look like a robot and I have to use the wrong dashes to be more "human".
As a Swedish native it really breaks my reading of an English word, but apparently it's supposed to indicate that you should pronounce each "o" separately. Language is fun.
As a native English speaker, it also breaks my reading of "cooperate". Never seen it before. I think parent is just annoyingly eccentric for the sake of it.
I admit that latter part is just for whimsy, because I think it looks fun. The dashes I like for their aesthetics and if that makes me eccentric then so be it. They shouldn't distract anyone's reading, or at least they didn't use to before LLMs.
It's just confusing for us poor Swedes since "ö" in Swedish is a separate letter with its own pronunciation, and not a somehow-modified "o". Always takes an extra couple of seconds to remember how "Motörhead" is supposed to be said. :)
Note that you linked to the 0.1.1 version of the gleam_otp documentation. The latest version resides at https://hexdocs.pm/gleam_otp/index.html and both gleam_erlang and gleam_otp have hit 1.0.0 already. It doesn't contain every feature yet (like dynamic supervisors) but it's usable (and I've rolled my own dynamic supervisor in the meantime).
I knew there were some ¨'s sprinkled in, but felt it was safer my way than to botch it up even more, heh. (Could've googled it, but that's less fun).
I've visited Finland a lot the later years due to my company starting a fulfillment center there. It was quite interesting how well I could get by with my Norwegian most places. Either because signage also was in Swedish, words often similar enough (except those that are very very far off, lol), or I even could speak Norwegian to some coworkers that then replied in Swedish (and not all of them even being Finns with Swedish as their native language).
I thought you meant they were 404, but no, it seems there's no markup to even attempt to link them. What's strange is that all the copies in Wayback that I spot checked all the way back to 2022 also didn't have any markup, so I suspect it never(?) did
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.