quaunaut

Go's type system is inferior to Typescript's in every possible way. About the only saving grace it has is that it didn't start out in a non-typesafe ecosystem, but most of those issues have been alleviated in Typescript for years.

At this point, folks are seeing how far they can push the Typescript type system because it's capable of expressing so, so much more with its types than is seen typically(including in most other languages).

No. Maybe functions aren't the result of simply returning different results. It's doing or not doing something, abstracted into a function.

Parsing is determining whether you should do it or not- it's about setting up a boundary from which you never attempt something that would be a maybe.

Yeah, that's literally what I'm talking about being broken. It hasn't worked for me for over 2 years.

Taking a look at it now, and how it interacts with Enhancer for Youtube.

The one thing I'm absolutely desperate for, is a fix to Youtube's Watch Later playlist issues.

If you ever hit maximum on it, it seems permanently broken afterward to not delete watched videos- which means the only way to delete videos is manually, behind a 3-dot menu per video. Since the playlist max size is 5000, that'd be a minimum 10,000 clicks, and since the 3 dot menu only shows up once you're over a video, a certain level of hunting too.

I tried to make an extension for this once, but bungled it pretty bad so it'll take another effort sometime. Youtube's my primary content source outside of games, so for me it hurts pretty bad.

SQL's nonsensical handling of null is reason enough to learn other query languages.

Look, I like static type systems, but not all type systems are created equal, and some(with the easiest example being Go) are downright awful for helping encode business logic, forcing you to write immense amounts of code just to work around their awful type system decisions, code that often introduces bugs because of those issues.

And that helps in financial analysis how?

You'd almost certainly just use a library dedicated to mitigating this problem though, of which there are many.

Why? What inherent advantage do those languages have with financial logic?

Except we could just treat them the same, and we could have a type system that makes that possible. Multiple languages before Go had a solution to this, that could've been used. Or, it could've written said sufficiently advanced compiler itself.

Instead, they didn't. And we all suffer for it.

> Would you put your code in production if there was a way to ignore compiler failure?

What compiler failure? Go literally does not warn you until it hits the error at runtime for these exceptions.

Yes, I understand, I do distributed systems for a living, after all. But if you keep adding stipulations without actually describing the problem you're not actually looking for an answer, you're looking to be contrarian.

> If customers think this is a feature and not a bug, then I have a very different understanding about what serverless/FaaS is meant to be used for. My division is pretty much only looking at edge networking scenarios. Can I redirect you to a CDN asset in Boston instead of going clear across the country to us-west-1? We would definitely NOT run Lamba out of us-west-1 for this work.

I'm not sure how you're misunderstanding, but why would it go across the country when it's guaranteed to run from the same parent? Just deploy the app in the region you want, and now its Flame pools will be deployed in the same region.

If you want to switch the region it runs in, you can also easily just contact the other cluster to tell it to pick up the work.

That's just standard erlang/elixir- because all values are immutable, when a new anonymous function is defined it copies the current value of the external variables into it.

You can do it right now even without Flame, just by opening two Elixir nodes, then it's as simple as

```elixir

iex(first_node@localhost)> name = "Santa"

iex(first_node@localhost)> Node.spawn_link(:other_node@localhost, fn -> IO.puts "Hello #{name}" end)

Hello Santa

#PID<1337.42.0>

```

Note that while the string interpolation and `IO.puts` was run on `other_node@localhost`, it still did stdout from the first node- this is because it was the one that called `Node.spawn_link`, making it the 'group leader'. Outside of which stdout it went to, all the work was done in the other node.

While Nix is cool and I think the model of the future, it doesn't obviate the need for elastic workloads on demand without wanting to dedicate a ton of time.

Yes and no: Maybe the rest of your workloads don't require much CPU- you only need this kind of power for one or two workloads, and you don't want them getting crowded out by other work potentially.

Or they require a GPU.

Or your core service only needs 1-2 servers, but you need to scale up to dozens/hundreds/thousands on demand, for work that only happens maybe once a day.

All true, but you've got a few issues:

- Flame still assumes you have a server somewhere- this is purely for elastic workloads.

- Dynamically scaling horizontally is not something "linux" can do for you: It's a legitimately hard problem because of all the usual distributed systems difficulties.

- Often, there are workloads that are only needed occasionally but also have very different resource needs than the rest of the system. Being forced to not only create a new version of your application, but additionally a bespoke server setup and dedicated VM/Container image for that case takes something that could be trivial in the Flame model, and makes it take hours even for someone experienced.

Basically, you really should've read the article first.

I imagine state should be managed via GenServers[1][2], since that's the general BEAM way of doing that.

1. https://www.erlang.org/doc/man/gen_server.html 2. https://hexdocs.pm/elixir/1.12/GenServer.html

> suggest how this may be fixed

Only allow composition. Allow composition techniques to add state, detect the presence of other composition types, etc.

The number of languages that only support Inheritance and have no version of Composition(or severely compromised versions) is long. What's funny is how many of them make it easier to perform composition as long as you avoid the `class` keyword.

I can't agree enough. What other paradigm is so regularly implemented in a way that makes doing it poorly easy(Inheritance), doing it well hard(Composition), and requires a list of caveats so large that it effectively draws down to "only use it in these specific places"?

How does a paradigm like that survive? I might be a fan of functional, but I'm not even saying go that way- stay procedural! Learn your abstractions over time and only build them when necessary.

Yeah, this complaint is nonsense. It mechanically nullifies the damage and we colloquially call it a 'miss' because it applies whether someone has armor or not, but how to interpret that depends on the situation.

For example, an Arcane Trickster throwing up a reaction 'shield' spell doesn't cause the hit to miss either, it just was blocked(as it added 5 to AC).

That's only if you don't design your language to be easily inferred. While I don't know the case for SBCL, a language like Elm has very heavy type inference that you can rely on better than most type systems.

This is not nor has not ever been true.

Now, you've got `dbg()` and running whatever you're running via `iex -S <whateveryouweredoinghere>`.

Prior to `dbg()` you had `IEx.pry()`.

Not about the article, but: OpenFaaS' Pricing Page[1] has no pricing on it whatsoever.

You could guess that since the Community edition is MIT licensed that it's free, but then again the language right above it says "non-production or experimental use", where Standard says "production and business use". Now, MIT I know basically means "It's on you, so if you wanna go prod go prod", but that wording just isn't friendly.

Looking over the Community Edition further, I'd honestly be stunned who would ever use this, and thus, what, if anything, about this is "Open":

- Only 5 replicas per function, ie, hope any given function doesn't have more than 5 invocations at once.

- No "scale to zero", (which is the usual cost benefit of serverless)

- There is an in-mem queue, except it's being End-of-Life'd in June, which is... a week from now.

- It does separately support cron triggers! This is great.

- It does not support any other triggers except direct call.

- Can't integrate it with any other K8s deployment tool

I honestly cannot fathom why someone would use this.

1. https://www.openfaas.com/pricing/

No, you don't require those things. If you're using the proper primitives, they literally can't hog 100% of the server CPU. In fact, the default concurrency primitives in the BEAM/Go do not hog 100% of the CPU, meaning you literally have to go out of your way to fuck it up.

This makes a difference, and means you do not require queues for properly silo'd background tasks.

> Our goal with Dioxus is to eat Electron, React Native, Flutter, Phoenix, Gatsby, and NextJS with one stack.

What of Phoenix are you looking to tackle?

PureScript has what I'd call some stark issues.

1. Its maintenance/activity appear sporadic at best. 2. It's inscrutable. Whenever I've had issues, I don't have any idea even how to approach solving them. Half the time they reference in-depth mathematical terms that just are not relevant to anyone who isn't implementing the language 95% of the time. 3. The tooling often just... doesn't work. I'll go to run a commend given in the official tutorial, and it fails in a way that is just beyond me, as an experienced engineer.

TBH, I'd really love to use it. I've been finding myself using `fp-ts` on many of my projects for just such a reason, and have even set up `unplugin-auto-import` to automatically detect and import those modules, so it's like I have more in my stdlib. I've even thought of making a true language out of these primitives.

Undeniably it's not going to be as convenient, but the divide isn't what it used to be. BEAM apps can be compiled to a binary, and as long as that binary was compiled for the platform, that should be good enough.

I'm doubtful I'll see it used much outside the BEAM community, but then again it's been a "successful despite a lack of mass usage" community for awhile.

ATM I use Todoist, but I'm wildly unhappy in using it. The only reason I do is that since it's a web-based UI, I can use it from my Windows box. Most of the halfway good GTD tools are Mac-only.

I've had a project going to build my own but admittedly have been somewhat dumb/lazy about it.