I used my homemade shell language last year, called elk shell. It worked surprisingly well, better than other languages I've tried, because unlike other shell languages it is just a regular general purpose scripting language with a standard library that can also run programs with the same syntax as function calls.

Native AOT compiled code is not necessarily faster than JIT compiled code. The Java JIT engine can do a lot of optimisations that would not be possible with AOT compilation. In the end it's compiled down to machine code anyway.

You don't have to implement some big new feature. I found a layout rendering problem when I tested it on my own website and could quite easily go and fix it without having any prior experience with browser development.

Well that's why they're going to rewrite parts of the code where those things are more likely in Swift

What? No one is expecting Ladybird to be fast at this stage. No one is claiming that it is. Ladybird is competitive because of the speed of which it is improving.

Well Andreas Kling has worked on Safari and WebKit and (obviously) has talked to a lot of browser people. He knows what he is doing, and he frequently says that no one that has actually worked on a browser thinks it's impossible to create a new one, even with a small team (...of highly motivated and skilled people).

What? Accused of only being done in academic environments? Never heard that. Academics seem to spend 99% of their time talking about parser generators and LR parsing for some reason while most production compilers have handwritten recursive descent parsers...

Same here, recursive descent is what I have run into in the real world.

I'm just happy when parsing isn't being done with some absurdly long regex with no documentation.

This is such a strange mindset. First of all, unsafe Rust is not comparable to C. It still has a lot of checks and balanced that C does not have. The author is also planning to make it more safe. And what do you mean "the primary reason"? The primary reason for this was to have fun. Let the man have fun.

> but nothing that I will install on any box of mine any time soon

Well, no one asked? I will never understand you chronically negative people that have to come in and whine about things that don't matter every time someone posts their fun little personal project that they made for fun. Have you tried being a little more positive? It makes life more enjoyable.

The only difference is that you have to specify the type of the list when you declare it though... That's not really a big deal.

List<string> names = ["Peter", "Julia", "Xi"]; names.Select(name => $"Hello, {name}").ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#"))

or

new List<string> { "Peter", "Julia", "Xi" }.Select(name => $"Hello, {name}").ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#"))

Nothing is that much a big deal on a small selected sample, on the one hand on the other. That is, maybe some will prefer mandatory explicit type for every single variable, and some other will prefer type inference whenever possible, and both have pros and cons.

To jump in a REPL (or any debug breakpoint observation facility), having optional type inference is a great plus to my mind.

Note that Crystal does allow to make type explicit, and keep the fluent interface on track doing so:

    Array(String).new.push("Peter", "Julia", "Xi").map{|name| "Hello, #{name}"}.each{|greeting| puts "#{greeting}! Enjoy your Crystal"}

Let’s remark by the way that, like with C# lambda parameters, block parameters are not explicitly typed in that case.

$100/g? You can buy it for less than 1/10 of that in Europe at least

I was just quoting the article. Apparently 'bespoke' saffron gets a premium?