sizediterable

This seems to be for the `async-task` crate. My question was about `async_std::task` in particular since it doesn't have cancel-on-drop behavior.

In the first `async_std::task` example, we see that `JoinHandle::cancel` is an async function. I'm curious what would you do if you didn't care whether or not the cancellation succeeded and didn't want to await the cancellation. Would you wrap the cancellation in a task?

Non-template-based code generation. So many tools depend on interpolation and concatenating strings together resulting in terrible-looking and error-prone code. What you want is an API for building and manipulating a concrete syntax tree-like structure. Bonus points if the nodes have type information, which would make things like codemods even more powerful.

HHAST and LibCST are notable examples in the right direction.

I also wonder how this might relate to "viewpoint adaptation" as defined in Pony https://tutorial.ponylang.io/reference-capabilities/arrow-ty...

This kind of reminded me of how in Rust you can split a slice type into sub-slices, except in that case you are actually allocating space for those sub-slices. This leads me to wonder if this is possible in a zero-cost way using const generics, where you only need to store the pointer to the backing data, and the index range/length is known at compile time, e.g. Slice<T, Start, Length>.

Sorry if it's a bit sensationalized. I wanted to give some color as to why this release might be interesting and took this tweet I saw at face value https://twitter.com/rbranson/status/1455923426359578631

Also: https://github.com/microsoft/TypeScript/pull/46429. Anders is on a roll!

I'm less familiar with OCaml and don't know off the top of my head. Doing a quick search I was only able to find references to type declaration variance [0], though I learned that Java also supports use-site variance too [1]

[0] https://blog.janestreet.com/a-and-a/

[1] https://blog.jooq.org/tag/use-site-variance/

I think most languages define variance at type definition level, notable exceptions being Kotlin which supports both [0][1] and Flow. But yeah, TS doesn't support (variable-)declaration-site variance which I didn't realize you were asking in my previous answer.

[0] https://kotlinlang.org/docs/generics.html#variance

[1] https://kotlinlang.org/docs/generics.html#declaration-site-v...

I think variance can be simulated by typing the private field as an existing covariant/contravariant/invariant type

  class CovariantFoo<T> {
    private phantom!: T
  }

  class ContravariantFoo<T> {
    private phantom!: (_: T) => void
  }

  class InvariantFoo<T> {
    private phantom!: (_: T) => T
  }

(inspired by Rust [0])

[0] https://doc.rust-lang.org/nomicon/phantom-data.html

I forgot about OCaml (since I normally associate it with the more sophisticated typing stuff). I don't know if I'd completely count Go since interfaces only apply to methods, not fields

Oh cool, hadn't realized this. Also thanks for your great work! I'm rooting for some of your exploratory PRs!

From https://luau-lang.org/typecheck

> Luau’s type system is structural by default

I think that makes it the second (production-ready) language to have a primarily-structural type system, after TypeScript/Flow(/and Closure to some extent) for JS. I wonder if it will follow in their impressive footsteps or if it will tread new territory.

One of the things that Flow gets right that TypeScript doesn't yet support is switching to nominal type-checking between class instances. In TypeScript you can assign an instance of one class to an instance of another as long as they have compatible fields. Compare:

Flow: https://bit.ly/3jZx4rB

TS: https://tsplay.dev/mZaL1N

TypeScript doesn't have any understanding of prototypes or prototypal inheritance, which is a big gap considering that it's a fundamental aspect of JS.

I'm really hoping Luau will come to do the right thing with tables and prototypes. Perhaps it already does, but unfortunately there doesn't seem to be a Luau playground to try in the browser.

Given the URL I was thinking that this would be hosted on a service that could run Github gists as single-page-apps. Unsurprisingly something like that actually kind of exists:

https://gist.run

> Beartype brings Rust- and C++-inspired zero-cost abstractions

> Thanks to aggressive memoization and dynamic code generation at decoration time, beartype guarantees O(1) non-amortized worst-case runtime complexity with negligible constant factors.

I don't think the author(s) understands what "zero-cost abstraction means". O(1) is not O(0). Also let's not forget that memoization incurs a memory cost.

I think it's not discussed enough how things like language features shape how library APIs are formed. People usually seem to only consider the question "how would I use this feature?" and not "how would the standard library look like with this feature?", which is surprising given how much builtin libraries affect the pleasantness of a language (OK not that surprising since people usually talk about features added to existing languages that already have a standard library.)

One of the things I'm excited to see is the cap-std project for Rust [0] given what Pony [1] has demonstrated is possible with capabilities. I'm also hoping that languages like Koka [2] and multicore OCaml [3] will demonstrate interesting ways to design APIs around algebraic effects.

[0] https://github.com/bytecodealliance/cap-std

[1] https://www.ponylang.io/discover

[2] https://koka-lang.github.io

[3] https://github.com/ocaml-multicore/effects-examples

Fixed, my apologies

An algebraic effects library: https://github.com/digital-fabric/affect

He has great taste!

Does anyone know of if the issues brought up by njs in this thread still apply? https://trio.discourse.group/t/structured-concurrency-in-rub...

> the last time I did html we were still using tables

I know the OP probably meant using tables for things like centering elements and doing page layouts (no longer needed since we have flexbox and grid respectively). But for those reading this that don't know any better, you should still use tables for content that is semantically tabular like displaying data. This makes the content more accessible to people using screenreaders.

Speaking of which, Flexbox Froggy and Grid Garden are fun and addicting ways to learn:

https://flexboxfroggy.com

https://cssgridgarden.com

And the Axe extension is a great way to learn about modern accessibility best practices:

https://chrome.google.com/webstore/detail/axe-devtools-web-a...

Preferably you'd preserve the best aspect of StackOverflow; others being able to learn from others questions. I don't know what the best way to achieve that would be. Recording the sessions and making them public would probably be uncomfortable on both sides. Perhaps incentivize the expert to do a short write-up on the problem and solution in some way.

I'm optimistic that this will be less painful as more of the Python ecosystem becomes async-friendly. We have `aiohttp` as a suitable replacement for `requests`, and major libraries like Django (not ORM yet), Flask, FastAPI, SQLAlchemy now have async support as well.

Yeah, it's unclear to me whether you'd have to "join" to get the result from an operation, or if you can have some form of "await" expression

> any blocking operation (a method where Ruby interpreter waits) is compatible with Async and will work asynchronously within Async code block with Ruby 3.0 and later.

That's pretty magical. Does this mean it would be possible to implement structured concurrency [0], but without the function coloring problem?

Regardless, I think I prefer how this looks from a code read/writeability perspective compared to Zig's or Swift's (and potentially future Rust's [2]) approaches.

[0] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

[1] https://kristoff.it/blog/zig-colorblind-async-await/

[2] https://blog.yoshuawuyts.com/async-overloading/

Ah, that clears things up. That's sounds huge!

> There's also this very nice Ent framework, written by ex-FB engineer: https://ent.dev/

Awesome, hope it succeeds!

I didn't leave due to the realization that the company was unethical, but there is a correlation there. I left because I got burnt out by the culture built around performance incentives. I didn't encounter anyone at the company who had inherently malicious or exploitative intent, but the culture drives the individual behaviors that in aggregate leads to all the harm caused by the company. That being said, everyone there, including myself should feel somewhat accountable, but it's really mostly on the leadership for having the power to change the culture but neglecting to do so.

> is entGo actually worth implementing as an ORM for Go

I can't speak to how valuable it would be when judged on its own. I just think that it currently does not and probably will not come close to delivering the same level of value as the FB Ent framework.

Oh cool, I didn't know about this. I guess they tend to publish more infrastructure-oriented papers, which is understandable, but I wish there was more in general about the developer APIs that they enable and how they benefit productivity from a product engineer's point of view.

It is an ORM, but I wouldn't call it just an ORM. I don't have experience with NHibernate, but most ORMs I have experience with feel like just a way progammatically build queries. I found EntMutator to provide nice abstractions to couple data changes with business logic like mutation triggers and observers. Again, all the additional tooling built around the Ent framework adds to the value.

Right, I wasn't trying to imply a relationship. I only meant to say that if they're willing to write about old news for one piece of tech, then maybe they'd do it for another.

Unethical companies get rewarded for their unethical behavior instead of being held accountable in any meaningful way. They then use their vast resources to grow their engineering force at an incredible rate. Moving fast means they are also accruing technical debt at an astounding rate, which then leads to throwing more of their resources at people to focus solely on solving these scaling problems.