Janet looks really interesting. Especially with how easy to embed it is.

If I understand it correctly creating DSLs in it should also be very easy with its macro and PEG feature?

Writing DSLs is very easy, and fun! The PEG grammars are very elegant to build up. I wrote a language for programmatic recipes (think scaling, unit conversion, etc) with it and it was a delight. I'd provide an example but I haven't taken the time to write a README so I haven't published it publicly yet.

Hey that's cool. Are you willing to instead share an example snippet of what the DSL itself looks like?

Here's an excerpt (which is in a map passed to peg/compile) for numeric parsing:

    :nonzero-int (* (range "19") (any (range "09")))
    :int (+ "0" :nonzero-int)
    :decimal (cmt (* (? (<- :int)) "." (<- (some (range "09")))) ,parse-decimal)
    :fraction (cmt (\* (? (\* (number :nonzero-int) :s+)) (number :nonzero-int)
 "/" (number :nonzero-int)) ,parse-fraction)
    :integer (cmt (number :nonzero-int) ,parse-integer)
    :num (+ :decimal :fraction :integer)

It's an incredible lua replacement for embedding. A lot of the time for an embedded scripting language you're defining a DSL which bare lua is fairly poorly suited to. And you lose the tininess and simplicity of the embedding if you're having to cram PCRE and shit in there too.

Janet basically just copies lua's C interop because it's the best part of lua. And then with PEGs and a solid macro system you're in a much better position for scripting, or defining a scripting environment, or a configuration DSL, or whatever you wanted a non-C language for.

I'm pretty new to it, but from what I've seen the answer is yes. And while I haven't wrote any macros yet I think PEGs are fantastic, and sooo readable. Their website has an example PEG to read Janet source - https://janet-lang.org/docs/syntax.html#Grammar

Embedding is really easy, as is writing c modules. You can link shared, or use an amalgamated c file. Check out https://janet-lang.org/capi/embedding.html

Honestly I'm having just as much fun learning Janet as I am writing C modules and embeddings; Janet all the things!

Congratulations! Genuinely impressive achievement. I don't plan to use Hyprland but the amount of work Vaxry and the Hyprland contributors put into the project is pretty inspiring.

> if you go searching for ladybird on Mastodon you will find that there’s quite a bit of ill will

I followed your suggestion and took a look at this.

Let's call the situation what it is: Someone with a few followers on Mastodon saw a reason to harass an individual, with the reason itself being secondary in nature. What happened there is called brigading, which is rightfully a bannable offense in many moderated online communities, even those many would (rightfully) consider very toxic in nature.

Pretending that this 3 year old pull request with a one (!) word change was actually of deep interest to the people involved seems pretty dishonest.

The fact that this absolutely trivial PR is enough to gain so much traction in certain circles that they gather to sling hurtful tirades at someone and call them names in order to hurt them....why would anyone want such a community interacting with a project?

Why would anyone want such a toxic crowd near a project?

Since for now this is supposed to force the messenger developers a way to circumvent would be to directly download and install APKs of messengers that refuse to implement this and/or left the EU market.

This is obviously merely a short term solution since it should be clear that targeting hosts and developers of non complying solutions would likely be the next step.

Technical countermeasures have been doing a pretty good job at combating insane copyright rules for a while now. It's often said that technical solutions don't solve political problems, but I think it's important to retain our freedom to run whatever code we like on our computers because that does seem effective at enabling freedom of communication regardless of laws made to quash it.

I don't know, mobile phones and messengers in particular are a very small target compared to general personal computing.

There are very few relevant messengers and adoption rate is king, because at the end of the day we want to use these messenger to communicate with people.

Getting people to try out new/different messengers is already a pain. And here every blow against an uncompromised messenger to make them harder to get will lower its usercount and push more people towards the compromised software they can easily get on the store.

Sure I'd say some way of circumventing this will probably remain available for a while, but I'd say it is extremely easy to make this very inconvenient.

After all this isn't about having some way to communicate safely, this is about being able to communicate safely in our daily lives is what I'd say.

Britain is already terrible when it comes to matters of privacy and/or encryption

Yep - or world leading depending on which side of the fence you sit :-)

This is from 1981.....

https://www.duncancampbell.org/content/big-brother-listening...

They are just lazy and occupied with other means of pretend right now, that's the only reason they did not pull a more drastic version of this just yet. It will come eventually.

> [...] we arranged to have five servers shipped to Amsterdam. However, all five servers were lost in the mail.

> These parcels were insured with the shipping provider, but we have been unable to reach the provider for any information regarding the status of the parcels or any resources for filing an insurance claim.

> After several months of attempts, we have ultimately had to write these servers off.

I obviously do not know the details here and it might be perfectly understandable given the full picture, but this chain of events sounds weird and could have used some further explanation.

Because this makes it sound like several thousand dollars worth of important equipment (and possibly important data) went missing and the issue was completely dropped because emails remained unanswered?

There was no lost data, and it wasn't just unanswered emails -- several hours on the phone, juggling between subsidiaries on either side of the pond, with no clear responsible party on their end. The customer service for this shipping provider is totally opaque and automated with AI crap throughout. We did eventually get in touch with some humans but they were not ultimately very helpful.

We do have general business insurance and will probably file a claim, but we have two overworked and exhausted staff members, a lot of other priorities, and a budget which is already pretty deeply cut from all of these events, and we just don't have the time and energy to duke it out with an opaque megacorporation right now.

If a shipping provider loses shipment and refuses to respect the insurance agreement, it sounds like they should be sued for damages. The damages are much more than the cost of the shipment, as the loss itself also undermines operations and causes a lot of financial downside.

Lawyers are not free, and the team already has very few CPU cycles to spare.

In some jurisdictions, the losing side will have to cover the cost. In some jurisdictions there are also small claims courts, which do not need legal representation.

It’s clear that it caused financial distress whereas as happy paying customer I want SourceHut to continue existing.

The reality is that actually getting your rights is often an enormous hassle, in terms of time, money, and/or stress.

If you're BigCorp™® with a Lawyer Department then that's not really a problem: you just send it off to the lawyers and continue with your day. If you're a private individual and/or small business: it very quickly becomes a trade-off.

So imagine SourceHut sues. And they win. And losing shipping company has to pay all of sourcehut's fees. There is a very real non-zero chance they will just say "lol nope, fuck you". And then what? Basically nothing you can do about it. Even in domestic cases this is true, international cases even more so.

In reality a lot of the world runs on goodwill and voluntary adherence to the rules, with not all that much little stopping bad actors from abusing things.

I part agree, but that goodwill and adherence also exist thanks to people who are willing to exercise their rights. A shipping company that suddenly can’t operate in a profitable country because they are in violation of court order will lose a lot of money; chances are, they like money.

Yes, I agree; see e.g Alan Bates for a famous example. But I don't think anyone could be faulted for not being Alan Bates and just moving on with their life.

Does “no lost data” mean that all drives were wiped or simply that there were backups?

Both. We restored from backups and touched up the diff out of band. We then had the drives removed and destroyed.

I see, thanks for elaborating!

> could have used some further explanation

They are not obligated to explain what happened in more detail. Your comment sounds like someone speculating about why a celebrity couple broke up when they release a brief public message announcing their separation.

You were not obligated to comment on GP's take either, and you also sound like you don't like what a celebrity said about their partner.

SourceHut are not obligated to post this blog post, but since they did, we are reading it.

And this part you quote comes right after a description of how their primary data center failed so badly that they had to completely evacuate it... It does give the impression that they just use cheap unreliable providers across the board.

Not necessarily a bad thing, it might be a calculated risk so they can pass on savings to customers. Still, a strong signal there.

In retrospect, our datacenter partner in the old datacenter was unreliable. But, we had been there from the start, since I was just hosting a personal server there pre-SourceHut, and during the incident they egregiously violated their SLA with us -- we had reason to expect better from them.

We're much more confident in our AMS partner, though.

> Languages either snowball or fizzle out.

This is not true and a naive statement. There are quite few languages which are not popular across the board but have a very firm niche in which they thrive and fulfill critical roles.

> while so much time goes into code reviews to verify internal changes at most companies

Very easy claim to make. Difficult to verify.

Yes, this is anecdotal, but I think there’s a fair share invested into it (from my experience)

Does Lean have something similar to Haskell's List comprehension [1] or some kind of set builder notation for functional programming purposes?

[1]: Example: `[x*2 | x <- [1..10]]`

It has the following which means the same as what you wrote:

    do let x ← List.range' 1 10; return x^2

The syntax is flexible enough that you could build your own:

    macro "[" r:term "|" preamble:doElem "]" : term => `(do 
    $preamble; return $r)

    #eval [x^2 | let x ← List.range' 1 10]

Here's an extensible one I wrote a while back for just List, but I haven't tested it in a while:

    declare_syntax_cat compClause
    syntax "for " term " in " term : compClause
    syntax "if " term : compClause
    
    syntax "[" term " | " compClause,* "]" : term
    
    macro_rules
      | `([$t:term |]) => `([$t])
      | `([$t:term | for $x in $xs]) => `(List.map (λ $x => $t) $xs)
      | `([$t:term | if $x]) => `(if $x then [$t] else [])
      | `([$t:term | $c, $cs,*]) => `(List.join [[$t | $cs,*] | $c])
    
    #eval [x+1| for x in [1,2,3]]
    -- [2, 3, 4]
    #eval [4 | if 1 < 0]
    -- []
    #eval [4 | if 1 < 3]
    -- [4]
    #eval [(x, y) | for x in List.range 5, for y in List.range 5, if x + y <= 3]
    -- [(0, 0), (0, 1), (0, 2), (0, 3), (1, 0), (1, 1), (1, 2), (2, 0), (2, 1), (3, 0)]

(Your doElem idea is a good one though)

Huh that is really cool! Thanks for the example!

Surely you can define such notation, but why? The following is just as clear and concise, and does not rely on any extensions:

    (. * 2) <$> [1,2,3]

For example:

    def byTwo (inputList : List Nat) :=
      (. * 2) <$> inputList

    #eval byTwo [1, 2, 3]
    -- [2, 4, 6]

> but why?

Why not? I was curious, Haskell is the functional language I know. Lean is the language I do not know.

Since Lean leans even heavier towards mathematics, set builder style notation seems like a natural fit. Now whether or not such notation is actually needed or worth it, that is a whole different question.

That's not exactly clear to mathematicians, who tend to complain about the "ascii art operators".

I think you'll usually see

    def byTwo (inputList : List.Nat) := inputList.map (. \* 2)

rather than using `<$>`. There's also `inputList |>.map (. * 2)`, but I haven't seen it in any mathlib theory code yet, just Lean core or in metaprogramming.

never understood the appeal of this syntax over standard do notation or just fmap.

List comprehensions read like math which we know from school. Do notation reads like Haskell which is fine but less accessible to non-Haskellers. Fmap is somewhat less convenient for slightly more complex examples such as

  [x*y | x <- [1..10], y <- [2,3,5]]

For that you'd use Applicative

  (*) <$> [1..10] <*> [2,3,5]
  -- or
  liftA2 (*) [1..10] [2,3,5]

Admittedly also not accessible to non-haskellers. But on the other hand, if you're going to learn a language, you ought to learn its idioms at some point.

That being said, nequo's request is not unreasonable; given Lean's advanced metaprogramming facilities, their request should be easy to implement.

The nice thing nequo's example illustrates is rank polymorphism: list comprehensions work with lists, products of two, three, four,... lists with the same easy notation : `[n-ary function | x_1 <- List_1, ..., x_n <- List_n]`. It is quite nice to have this, especially for complex numerical operations.

Note also that unlike Lean 3, in Lean 4 `List` does not inherently implement `Applicative` or `Monad`, so your code cannot work as is.

Mathlib4 provides a `Monad List` instance, which you can see at https://leanprover-community.github.io/mathlib4_docs/Mathlib...

Haskell has always been a language where there are many ways to skin any particular cat, for reasons from ergonomics to expressiveness to theoretical niceness or practicality. "Learn the idioms" has nothing to do with it. Why didn't you just use do-notation instead, for example, than write some applicative mess where it isn't needed?

It's not rocket science why someone would ask this. I don't always use list comprehensions. But sometimes I do. They have open arity and the syntax doesn't as often require things like parenthesis to handle fixity conflicts between other (non-applicative) operators. They are asking about list comprehensions, just because they think it's nice. It is a very simple question and talking about applicative is irrelevant.

That's perfectly fine Haskell, but I wouldn't say that using Applicative is much of a Lean idiom. Especially in the mathlib, people prefer using custom notation that looks like math notation or using the underlying functions directly rather than by using generic point-free notations. For example, you'll see `⨆ i, s i` for a supremum across the values of `s`, vs a point-free version.

The solution would be easy: at least offer an alternative. I would gladly give you a few cents or a dollar so you leave me alone with the dishonest bullshit. Probably one of the easiest and most effective ways you could use to fight spammers, but it is obvious why nobody does it or offers the option, because they want numbers. Would be nice to at least stop the charade.

In short, no, the alternative is not "being overrun by spam".