You would likely be interested in Jamie Brandon's work on the Zest language [1] which has planned "lax", "strict", and "kernel" modes for varying levels of performance/safety
Adding a font is just `#set text(font: "besley")` or you can use a list for fallback like `#set text(font: ("jost", "noto sans")`. Then you can select weight, italic/bold, opentype features, ligatures, etc. as options on `text` with the same syntax.
The command line comes with a few defaults such as the open source Libertinus for text or New CMM for math, but may fall back to your System fonts for characters like emoji (and there are flags to disable system fonts). You can also set a specific path to look up font files.
And then the web app has plenty of fonts in an extensive dropdown, and supports dropping in custom font files that will be automatically recognized.
I believe one current limitation is bitmap fonts not working properly, but that is being actively developed by a contributor.
I'm optimistic that Typst won't run into the issues you mention. I see it as doing well at incorporating the knowledge of the past into simpler, better interfaces.
I'm actually currently doing some research on operator precedence and syntax, so it's fun to see such a relevant post! One of my favorite syntaxes for custom operators comes from Agda and allows for easy definition of mixfix operators. Agda uses underscores to stand-in for operands in the name of arbirtrary functions (i.e. `_+_` as the sum). But when fully qualified with all underscores, this will act like a normal function (`_+_ 3 4 == 7`). But, uniquely among languages I've seen, it allows for partial application of arguments with operands in place, making it much easier to create new curried functions.
Here's an `if_then_else` example, modified from [0]:
-- declare an operator function with underscores:
if_then_else_ : {A : Set} -> Bool -> A -> A -> A
-- define the function:
if true then x else y = x
if false then x else y = y
-- call it:
if_then_else_ cond first second
-- or use it infix:
if cond then first else second
-- or partially apply "sections" of the operator:
-- this is really cool
(if_then first else second) cond
(if cond then_else second) first
if cond then first else_ second
if cond then_else_ first second
if_then first else_ cond second
(if_then_else second) cond first
Of course, the paper by Agda authors Danielsson and Norell, Parsing Mixfix Operators [1], is a classic discussion at the theory of mixfix operators in expression grammars (they take a stance of precedence as a DAG). But I do not often see cited the earlier and similarly titled dissertation by Jacob Wieland, Parsing Mixfix Expressions [2], which goes further into defining classes of ambiguity in both operator expressions and overloaded operators, expresses these in an Earley style parser, and in my view is far more practical for real language designers.
I haven't seen a mention of the Oil Shell (https://oilshell.org) project's OSH/YSH yet and I'm quite surprised.
Oils goal is that OSH is just a new Bash implementation (although not bug-for-bug) but with an upgrade-path to the more modern YSH for real programming with type safety etc, but still as a shell language. One of their exciting ideas is using code as data in a somewhat lisp-like manner to allow function introspection in YSH etc.
Based on other comments it seems like Oil Shell is much more principled in working to actually understand Bash as it exists and presenting an alternative language. I would be interested in what differentiates Amber and whether they have a response to Oils?
Osh is stricter than bash. Anything written to osh should run in bash with no issues whatsoever.
Ysh implements new, non-compatible syntax and semantics.
Osh and ysh are two different shell languages from the Oils for UNIX project. The release build generates a single binary, oils-for-unix, and installation creates two symlinks for the two different shell personalities, similar to how the bash binary will behave in its POSIX-compliant mode when it is invoked as sh.
There is no "Oil shell" now, at least not without ambiguity.
It's an entirely different problem; the problem being solved here is not "use a better shell than bash". It's targeting bash as a universal runtime because it's (kinda sorta) ubiquitous.
What’s the use case for that though? Nobody writes shell because they want a shell language. It’s written purely out of necessity because that’s the lowest common denominator installed on all systems. Something that Amber here provides a potential exit path out of.
Oil would have to reach a really critical mass before it can compete, which is sort of a catch 22 situation.
oil's idea is that you do want a shell language (e.g. if a lot of what your code is doing is job control and manipulating unix pipelines I can see shell being the best language to express that neatly in). you just want a better shell language than bash. but there is a ton of existing investment in bash itself and things like nushell their that away to start from scratch, and oil says what if we build a better bash instead.
I liked a quote from a No Boilerplate video [0] noting how some of the most commonly used Rust libraries hadn't had any git commits in multiple years: "They're not abandoned, they're done."
I agree with other commenters that paper and pencil are the way to go for true learning, but the other week I left my notebook at home for a lecture, and was able to keep good notes with Typst, although my typing speed isn't excellent. Curious what other people think about Typst vs Latex for notes?
Edit: reading a bit further, it seems like Typst has the ability to do a lot of the snippets as-is ($->$ is \to, $in$ is \in, etc.), and since variables in Typst are usable by mere mortals, it's easier to hack in the language you already use. For example, I use `#let la = $lambda$` as a shortcut.
It's probably not going to be all that different - similar to switching between programming languages. Typst markup feels more modern and intuitive. That may give it a slight advantage while note taking. But LaTeX has an elaborate layout algorithm that plays a big part in why its output is so good looking. I'm curious about how Typst's layout compares with that.
[1]: https://www.scattered-thoughts.net/writing/zest-dialects-and...