looking at recently closed issues, it definitely doesn't seem like a project in decline. I really should find some time to test drive it.

The main reason union types are unpopular is that they interact weirdly with generic constraints. But I also see that constraints are implicit? Again, really interesting stuff.

Really interesting ideas on the website, very active development, probably won't get around to trying it for a while but I wonder if they have a breakdown of the type system somewhere because I like the booleans and would like to see if and how they combined generics with them.

why would you copy a list like that? did they have differences?

I think if I ever manage to sell my team on an ecosystem change, it will be because dotnet caches a lot, mostly incorrectly, so every dev day includes 1-2 dev hours of fighting with the toolchain to acknowledge our progress.

@retoor what you're describing is known to most as recreational programming. It is important and it's how new ecosystems emerge and small ones grow, but I don't think it's the topic of this post because very few lucky people get to do it full-time, and because recreational programmers will write whatever they like, since even if their choice to execute regex directly from source is completely insane it's not like anyone is negatively impacted by it :)

when delivering best value in shortest time to customers performance is very rarely a factor, but there are still other ways to compare languages. A non-exhaustive, unordered list:

- how easy it is to fuck up, how quickly you find out, what happens if you don't until production (safety & error handling)
- how many APIs already have bindings or are implemented natively (ecosystem)
- how easy it is to write new bindings (interoperability)
- how easy it is to get all those third party libraries and tools to play ball with each other, how rarely the build system or package manager breaks for no conceivable reason
- how trustworthy those bindings and tools vendors are
- how common your use case is in the language, how many forum posts already exist for every question you will ever think of

@kiki yeah

but even then, an Alaskan and a Texan mean qualitatively different things obscured by language when they say that 100F is "really hot"

also, the notion that 100F is "really hot" and 0F is "really cold" per human experience is simultaneously completely useless and false, because depending on who you ask around the globe, either of those temperatures may be cozy or unimaginably extreme. Celsius is at least useful for cooking and dealing with ice (both in the kitchen and outside), and since both of those are universal experiences, everyone on Earth (except in Nepal) will have the same intuition for it.

I don't think there's an obvious distinction between making and doing. Filling whatever containers you have on hand with water and gasoline for a really long trip isn't a complex task, yet calculating how much of either you have becomes enormously complicated with imperial.

@lorentz lmao now no one will know

@retoor that's the idea, there's nothing objectionable and it doesn't really leave room to continue the conversation, but it mentions every reason why tagging the company was stupid. It looks like a reply so I can claim that I replied to all by accident, but it''s actually written for the unwilling audience.

Passive-agression is an art

<- Reply all

"Dear X,

Thanks for pointing this out! This seems like a really old issue, it's been around for N months, longer than I've been here, and you're the first to notice. Feel free to e-mail me directly about these in the future, with your help we're sure to catch any other hiding bugs before they could have any impact on the business as well. :)

Best,"

@jestdotty Vec has pop_if which removes the last element if a predicate succeeds, and VecDeque has pop_front_if and pop_back_if, so I guess the rationale was that removing the first element is a relatively uncommon operation anyway because of how expensive it is.

@jestdotty I see what you mean with remove,. I guess it would be reasonable for it to return a Result. Either way, none of these safe micro-functions are terribly important, since they're trivial to implement for yourself.

@jestdotty You can't peek at the first index and then choose whether to take it because you can't mutate the vector while holding a ref to an element. If vector specifically supported this use case, it would be implemented the same way you would implement it externally, except the function that does it would need a closure argument and like 4 generic parameters (two distinct lifetimes, I think one might be implicit). If it's any consolation, the second unwrap will definitely be optimized out

@jestdotty vec.remove(index) is absolutely a thing.

https://doc.rust-lang.org/std/vec/...

Keep in mind that since you can't have a hole in a vector, this will shift the end of the vector down an index. If you want holes in your vector, consider a Vec<Option<T>> and vec[index].take()

@Demolishun Pattern matching like in Haskell, Rust, C#, Java, etc. Most modern languages more-or-less agree on the meaning of the word, afaik python doesn't have it at all.

Passing a function by name is far less ergonomic for the purpose of Option. Why would I want to name a block that isn't any more special than the body of an if statement?

@retoor they can't contain statements, just one expression.

@retoor I guess since Python fully supports neither lambdas nor pattern matching, you actually can't make an implementation of optional as ergonomic as it is in other languages, so this may be the closest Python can get to that.

@retoor for a single operation it doesn't really cause problems I guess because the source of the error is unambiguous, but I don't see the benefit either. It just looks to me like a clumsy substitute for optional/maybe.

@retoor I checked upfront of course, the exception is a null reference in this case, but even if it was a custom empty collection error, it would be difficult to assert that I'm not associating my handler with other error conditions from other collection operations for which it's incorrect.

I think the only case when handling an exception is preferable to preventing it is if the enclosing scope and the exception type fully specify the handler's duties. If the handler would need to assume anything about the line that raised the exception, checking first is better.

Obviously not considering APIs that abuse exceptions to represent non-exceptional, fairly likely outcomes, such as a missing file or network failure.

@antigermanist it isn't input, it's from a database previously populated by earlier versions of the same software, with all sorts of constraints ranging from high level business rules (eg. "a product is usually built from at least one part") to low level implementation guarantees (eg. "BOM nodes store the ID of their parent", "exactly one parent ID in a given BOM is null", "The child-parent graph is loop-free")

Both are subject to change.

it's still a matter of perspective. Who''s to say that reality is described by a concrete set of axioms and not something entirely more complicated that subsumes the relation between sets of axioms and their corresponding sets of true statements, which we are discovering right now?

I think that with our understanding of mathematics based entirely on set theory, it's essential to avoid the implication that the axioms of set theory are special in any way and not an arbitrary choice that generates a useful set of true statements.

well seeing as parallel writes tend to tank write performance, I''d say it's a good idea either way, even on a modern FS that manages fragmentation.

Unless you can rely on the disk being an SSD which has goofy magic firmware tricks I don't plan to ever learn.

which cve?

now that you mention it, an 8 hour flight + 3 hours commute once per year, both ways, still only equals about two weeks on-prem, or equivalently about 1 day per month on-prem. It also excludes people who can't afford any on-prem. Food for thought.

The real reason is that Apple is deliberately breaking basic web functionality constantly specifically to force developers into the app store while making a potential antitrust lawsuit as complicated and unpredictable as possible.

@Lensflare That was never needed for webapps. The legacy solution is HTTP caching headers with a really long TTL, the modern* solution is a caching service worker.

*13 years old