If you want to set e-bikes folks' hair on fire, show how many shoes the government could buy for the cost of an e-bike distribution program. Then, apply that number to the population that would be served by those e-bikes.
I've recently installed (a maintained fork of) Krohnkite[0], a tiling WM for Plasma 6, and I'm happy with it so far after tweaking the key bindings.
Things I miss:
- a scratchpad;
- toggling back and forth between desktops/workspaces with super+number (e.g. super+3 goes to desktop 3, but if I'm already on 3 I want to go back to the previous desktop);
- I also miss a bit the "manual" tiling from i3/sway (where you can choose where the next split will be). Krohnkite is DWM-style with predefined layouts (two columns, spiral, monocle...).
Maybe some of this can be done on Plasma/Krohnkite too (for the third I doubt but it's low priority), I haven't really looked into that.
I've started using TW in the past days with the goal of setting up a cookbook + meal planner with nutritional values computes from the ingredients.
It feels very malleable/hackable, I'm happy with my progress so far, the biggest annoyance is that as far as I can tell the JavaScript API is not documented anywhere.
Initially I looked at Decker and LÖVE, but the former is not suitable for a phone screen and the latter isn't meant for UIs. I would have preferres a non-web solution but TW is a solid choice nonetheless.
Changes to Zig can still be very significant. I found myself stuck between a rock and an hard place when I found out that:
- Zig v0.11 doesn't have async/await, which I needed, because they haven't implemented it yet on the self-hosted compiler;
- I couldn't use v0.10 due to some bugs with comptime in the old compiler, which are solved in v0.11.
Still, while bold, I don't think it's totally unwarranted to tag Bun 1.0. They may have to put some extra effort here and there to work around the language's instability.
This is not a critique of the Zig team, they make it very clear that the language is not ready for production use yet.
1. The chance of getting popular support for a protest like this diminishes with the number of people you piss off. You may be able to earn some sympathy by targeting SUVs only, but doing the same with all cars wouldn't be a good strategy.
2. There are good reasons to own a car, and in some places a significant number of people may be justified in using one. Blanket targeting everyone would be unfair to those who really need it. By contrast, SUVs don't have any (significant?) utility over a regular car (other than ego boosting maybe...).
There's also the new Body Weight Strength Foundations (BWSF) Routine [0]. BWSF is the routine they now recommend, not to be confused with the Recommended Routine ;)
Are hare's tagged unions and pattern matching comparable to ADTs found in functional languages? I really miss them in C and would like a "better C" that offers them. Rust does, but of course it's a much bigger language.
Hare doesn't care much about mathematical purity, and the features it does have were chosen on the basis of what is useful in systems programming.
There are sum types (tagged unions), but product types (tuples) were a late addition and we still don't have support for tuple unpacking or pattern matching on them.
Tuple unpacking is something that's been put off for very long but looks like it is going to finally happen soon. Pattern matching on types other than tagged unions hasn't been completely ruled out yet, but is also not guaranteed to happen.
I'm not sure what you mean by "select by type". I can say that you can define new types:
type a = int;
type b = int;
type c = (a | b);
Which seems to be what you're angling for here? I also suspect that you're approaching this from a Rust- or Zig-like background where enums and tagged unions are closely related; this is not so in Hare.
I do know those languages, but this is more the ADT way from ML.
The example you linked did not really make it clear from my point of view because one of the points is that it will collapse if there are multiples of a specific type. But your way seems to make it possible.
Tagged unions of free-floating types (polymorphic variants, C++ std::variant) and enum holding cases namespaced within themselves (Rust/Haskell) are two alternative designs. I personally prefer having both in a language. But if only one is available in a language, I prefer free-floating types, since it's more flexible and allows using the same type in multiple tagged unions, and you can somewhat emulate enums using tagged unions and namespaces (like I've done in C++ at https://gitlab.com/exotracker/exotracker-cpp/-/blob/eb8458b2...). If you take that approach, to prevent collapsing in the generic case when two type parameters are the same, you'd have to define newtypes for each type stored in a union.
Thank you, from the other replies it seems like they would be enough for my needs.
> Would be curious to hear your thoughts on how they compare given your (presumed) background in functional programming.
I'm just a student with an interest in programming languages and very little knowledge and experience, so I don't think I'll be able to provide any significant insight ;)
If you want to set e-bikes folks' hair on fire, show how many shoes the government could buy for the cost of an e-bike distribution program. Then, apply that number to the population that would be served by those e-bikes.