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.
To be honest, not most of them. It took until GBA era to get some decent mainline games, and the series probably peaked around DS era, both mainline and spin offs. Gen 1 and 2 have so many flaws that make them age really badly
To be honest I think the opinion was always generally divided. In my personal experience in the community, gen III and IV seemed to be the most popular, with significant but smaller sections of the community enjoying Gen I, V and II. I haven't met many people whose favourite is post Gen V though. (Mine is Gen IV, closely followed by Gen III and V)
(Something a lot of people don't know is that Mew's data actually exists in the generation 1 games and that it's technically possible to have it in the game on original hardware, sprite and all. The technical means by which one can obtain it is actually the same as the means by which one encounters the famous Missingno. I've personally done it in an emulator.)
I also see some gameplay flaws but they're mostly opinion (I'm not who you replied to, FWIW):
- Gen 1 had a single "Special" stat which was used as both Defense and Attack; this was split in Gen 2 to be Special Defense and Special Attack. This actually makes it a little fun to go back and play those games because some mons are just broken, e.g., Chansey so maybe it's not a great example. I believe this was a consequence of the memory size of the game flash cards being too small to support more numbers.
- Competitive teams from Gen 1 are determined by the 3 mons (of 6) which aren't on every single competitive team for the generation[1]. Normal is generally considered to be the best defensive type in the game for two reasons: 1) its only natural weakness is fighting, which doesn't have any good offensive moves in Gen 1, and 2) it's immune to the paralyze chance from the move Body Slam because Body Slam is a Normal-type move. The 3 mons which don't change per team are all single-type Normal.
I'm not exactly sure about the gen 2 games but I don't generally find myself drawn back to them. But I also don't find myself drawn to gen 3, for example. I do love myself a good gen 3 hack, though.
Gold and silver also had celebi hidden in the game files and it could be hacked in with a gameshark!
TBH, I don't consider the glitch list that you shared to be a list of flaws. I played the original pokemon games a lot, and heard all of the rumours about the game. Very rarely if ever did I encounter a glitch without seeking it out. Honestly the existence of missingno and the rare candy duplication glitch were enhancements to the experience when I had already played the game exhaustively.
> This actually makes it a little fun to go back and play those games because some mons are just broken
I agree! I really don't consider lack of competitive balance to be a significant flaw for the first games, since the game design was based around the single player experience. If all of the pokemon were balanced, I would consider it a detriment to the game. Half of the joy of finding new pokemon and discovering evolutions was to find these imbalances and use them to destroy the elite four, or show off to your friends.
As far as flaws, I was mostly asking from a game design or implementation perspective, because hard to replicate glitches that reveal hidden secrets and 150 monsters to uncover with some being ultra powerful was literally exactly what I wanted as a kid. It's also good game design, even if not 100% of it was intentional.
- gen 1 pokemon are very basic and probably some of the worst in the series (subjective)
- the games are extremely unbalanced, and many types have only one evolution line while others have a lot, there's no uniformity (gen 1 has only 1 dragon and 1 ghost line)
- the lack of physical special split hits many types insanely hard and they never balanced for it (i.e.: Ghastly line is a special attacker but is the only ghost type, ghost type is physical for some reason)
- gen2 is basically non linear for most of Johto, which completely destroys the levels on the gym leaders and the wild pokemon. The Kanto section has similar issues. And red is only difficult because it's insanely overlevelled compared to everything else
- gen 2 gym leaders don't have Johto pokemon (lol)
- trainer AI, especially in some instances, is very weirdly programmed (Blaine for example uses healing items on full HP pokemon for no reason)
- lack of moves means even late game, trainers have start-of-game moves ( blue has a rhydon with tail whip and leer, but no ground or rock moves. And an Exeggutor with no grass or psychic damaging moves. And he's the final boss)
