Actually that seems exactly wrong. unless you set temperature 0, converting logits to tokens is a random pull. so in principle it should be possible for an llm to recognize that it's being asked for a random number and pull tokens exactly randomly. in practice it won't be exact, but you should be able to rl it to arbitrary closeness to exact

the point of all this io stuff is that you'll be able to start playing with zig before async comes and when async comes it will be either drop in if you choose an async io for main() or it will be a line or two of code if you pick an event loop manually.

i mean it might be a medical emergency but not a reactor emergency?

sel4 ships with memory safety on by default.

1:100 is very countable using automated techniques.

yeah, colony on this plate is likely aspergillus spp.

Why would it be mold if the OP was culturing bakers yeast?

look at the 1:10 plate. there's colonies that isn't yeast there. luckily, it got diluted out, or, maybe that plating was a bit more careless than the others.

i didnt mean to imply that all of the colonies aren't yeast.

The culture was contaminated with fungal spores.

sometimes people think they know better and want to reinvent the wheel

Avoiding exactly that is why erlang gives you genserver.

gleam's 1/0 = 0 is crazy just because the author doesn't want there to be any raises anywhere. problem is, in many real world scenarios 0 is used as a sentinel value that doesn't "just" mean 0. iirc reading somewhere (in a non gleam system where 1/0 = 0) there was a system where everyone woke up to having zero shares because a 0 share tx was posted to everyone's trading endpoint, and a zero share tx means "zero the account".

I think that's less likely to happen in Gleam because using 0 as a sentinel value would be unidiomatic, but I agree that's a very dangerous design choice.

luckily no gleam software ever has to interact with outside systems (software or otherwuse) that might make a choice unidiomatic to gleam.

in case it wasnt clear: a zero share tx being a tombstone is a stock accounting convention, not a choice of that particular software project.

You'd just do the same thing you do in any language, you parse the incoming data into a format that's more idiomatic, e.g. in Gleam

    type Record {
      NShares(n: Int)
      ZeroTheAccount()
    }
    
    fn parse_record(n: Int) -> Record {
      case n {
        0 -> ZeroTheAccount()
        _ -> NShares(n)
      }
    }

Then you don't have to worry about mixing up the two :)

no. you're mistaken. the error came about because the code calculated shares to give out as an average over certain set of values but in the particular business cycle there were no entries to average. a divide by zero error would have crashed and either triggered review or nothing would have happened. instead, dividing by zero was happily calculated as zero and everyone got a zero share disbursement, which meant "zero all the accounts". this is not an inbound data problem. this is a scenario where if someone had programmed it in gleam, gleam would have happily calculated an (incorrect) average of zero and everyone would have lost all their shares.

to wit: anything that calculates an average over non-fixed data cardinality for business logic is potentially at risk for a seroious logic error in gleam.

what's worse is this is a nonobvious error. llms will likely make it a lot. a code review is likely to miss it.

what's even worse is that the author refuses to acknowledge this and digs deeper in (because, well, its a "principled" choice that got made and now to change is breaking and it breaks a core "feature" of the language). 1/0 = 0 is fine for a language like idris which is used for theorem proving but never used for real world things. It's inappropriate for deploying when, for example, real money might be at stake.

Ah, I see my mistake. Yeah that's definitely the kind of thing that could happen in Gleam.

the reasons to not use macros have to do with hygeinicity? -- macros can do things like introduce code that is hard to understand, perhaps a dynamically named function, or a difficult to chase dependency or import... moreover these can make grepping harder.