At least half of those languages (Elixir and OCaml) have some sort of mechanism for ad hoc polymorphism (elixir has behaviors and protocols, OCaml has higher order modules) so I feel like the comparison doesn't work that well personally
OCaml's modules are not implicitly instantiated, so they provide the same DX and APIs as you would get in Gleam.
Elixir does have protocols, but they are extremely limited compared to type classes, traits, etc, and they're uncommonly used compared to writing concrete code.
From how you describe it, it sounds like it's taken the same approach as Haskell's async exceptions + mask/uninterruptibleMask, which to me seems like one of the best solutions around, so props to them
Haskell also has something like this in Debug.Trace.trace: even though it's _technically_ impure (cause it outputs to stdout), it's typed as a pure function because it's just for debugging (I think internally it uses an escape hatch to just hide the IO)
Is there a way to emit WebAssembly with Uniffi? I looked for it before, but I couldn't find it (I'm using it in a project to share login between the backend and Kotlin/Swift apps. I wanted to share it with JS for a web frontend, but didn't find any docs mentioning it)
I think, from having it used recently, that supabase's TS library does this. I had to write a wrapper around it a few months ago at $dayjob and was really surprised when select/from parts of a "query" (not really a SQL query, because it's just a postgrest query) actually got parsed at compile time and spit out the right types. And since our code is pretty type heavy, I was gonna have to do that anyway, so I really appreciated it
I have no idea where you get that acceptance of same sex marriage arises from Christian ideas. Because in my personal experience it really doesn't. I live in Italy and a lot of discrimination against gay people (me included), and a big part of the reason why we don't get actual marriage, is catholic rhetoric. Most of the homophobia I've experienced in my life, anecdotally, has been from devout christians: the more devout, the worse the discriminantion. So although I have no data on hand, I have a very strong suspicion that Christianity has nothing to do with it. If anything, it seems like at least in Europe, the more secular countries tend to get better rights for queer people and they get them faster (I think the first European country to get gay marriage was the Netherlands, back in 2001. And they're one of the least religious countries in Europe)
It’s hard to see if you limit your view to Europe, because Christian morality is just “in the water” there. I’m from Asia, where same-sex marriage is not accepted anywhere except Taiwan. It’s not accepted in Buddhist Thailand, Hindu India, Muslim Pakistan, atheist China, or Shinto/Buddhist Japan. It’s hard not to notice that the places where same-sex marriage is accepted have something in common: they were Christian for more than a thousand years.
It’s not just “secularism”—the absence of belief in God or absence of organized religion. Japan and China are extremely secular countries, more so than anywhere in Europe. The notable thing about the Netherlands seems to be not that they’re secular, but that they also were a hotbed of the Protestant reformation. Until the 20th century, the majority of the Dutch population was Calvinist. A few years after the Netherlands legalized same sex marriage—and long before most of the rest of Europe did so—Massachusetts became the first state to legalize same sex marriage. Massachusetts was founded by fundamentalist Calvinists (the Puritans). Even though American Calvinists and European Calvinists split (geographically) 300-400 years ago, their version of “secularism” evolved in a very similar direction, and quite differently than the “secularism” of Asian countries. It’s really hard to say that’s just a coincidence.
Does it? I haven't used much ocaml and I haven't used Haskell in a while, but as I remember it all IO is already non blocking in Haskell, and the async library gives you the most painless async experience I've ever seen in any ecosystem. And for OCaml, you have explicit binds but recover neat do notation with let*?
You may be right. I haven't used OCaml or Haskell in a while, either. Last time I did concurrency in OCaml, there was no such thing as `let*` (you had to use Camlp4 to achieve anything like this), so it's entirely possible that the user experience has improved. As for Haskell, I mostly remember the complexity of getting anything like a reasonable error handling through the IO monad.
At $dayjob right now I'm using remix+supabase (although the supabase part is going away, but we're keeping postgrest). I have to say I quite enjoy it. DevEx seems good (although we've added quite a bit of our own logic on top). Performance is too early for me to tell. For my personal stuff I tend to do more app-like things, so SSR/SSG is not that useful to me, and I tend to go with pure react+redux. But I might try svelte when the new version comes out, it solves a lot of my issues with it.
I've had many cases in the past (not in go) where I've had to make use of that exact same function (in typescript, in F#, and in C#). it is actually quite useful when doing any amount of data manipulation (map/filter/reduce chain that often ends up into a list of key-value pairs, which then get turned into a map/dictionary of sorts).
At least in my job(s over the years), turning a flat list of db records into a more complex, nested (potentially on multiple levels) data structure before handing it off to the front-end is a very common. I've seen it done with "simple, fast code" (although not in go specifically, but in other languages), but it very quickly turned into huge messes of of long nested for loops and was very difficult to read. LINQ, Lodash, java's streams... I sincerely can't understand how go developers live without them. They make me a lot more productive both at reading and writing the code.
Part of the issue is that Go has a variety of design choices / limitations that conspire to produce different design patterns in this area than what you might see with e.g. Java.
For example: let's say we want to implement something akin to Java's Comparator interface.
Java allows interfaces to be extended with default implementations. It also allows methods to specify their own generics separate from the entire interface / class.
Thus the "comparing()" method can take in a Function<T, U> that extracts a value of type U from T that is used for comparison purposes. The return type is Comparator<T>.
(Generics simplified a bit, there are other overloads, etc.)
There's also thenComparing(), which allows chaining Comparator instances and / or chaining Function<T, U>.
As a consequence, one can use .thenComparing() to build up a Comparator from the fields on a class pretty quickly. Especially with lambda syntax.
Go doesn't support methods having different type parameters than the overall interface / struct.
Go also doesn't have default implementations. It doesn't allow function or method overloading.
Go does have first class functions, however.
To build the equivalent capability, you'd most likely build everything around a comparison function (func[T any](a, b T) int) and write a bunch of functions to glue them together / handle useful operations.
That impacts the readability of a long chain of calls, especially since Go doesn't have a lambda syntax to make things a bit tighter.
Getting rid of the limitation on method-level generics would make this _significantly_ more ergonomic.
reply