Yes! Came to comments to see if that was discussed/commented on above with link: https://protobuf.dev/programming-guides/json/

Sure... https://protobuf.dev/programming-guides/json/

I was pushing at one point for us to have some code in our protobuf parsers that would essentially allow reading messages in either JSON or binary format, though to be fair there's some overhead that way by doing some kind of try/catch, but, for some use cases I think it's worth it...

We can't know how much is about the prompt though and how much is just stochastic randomness in the behavior of that model on that prompt, right? I mean, even given identical prompts, even at temp 0, models don't always behave identically.... at least, as far as I know? Some of the reasons why are I think still a research question, but I think its a fact nonetheless.

If you want OOP than, yes, Elixir isn't it... maybe Pony? Curious what else you don't like about Elixir though besides not being OOP... it's definitely got messaging!

A robust static type system is what was missing for me, at least last time I looked.

Static typing and messaging (OOP) don’t exactly fit together. If you want OOP, you are fundamentally beholden to dynamic typing.

I don’t want OOP. I just want the language to include a system for imposing constraints that prevent entire categories of bugs and make it easier to safely do large scale refactoring.

It’s really hard to go back to living without this once you’re used to it.

Coq, Idris, et. al. are over there if that's what you really want, but there is probably good reason why no "real world" programs are written in languages with proper type systems.

For one, there's little ability to avoid message passing in our modern world. You can take it out of the language, but that just means pushing it to another abstraction (e.g. sockets), and all the same lack of type safety comes right back.

Nice! There’s also this[0] project run by community /elixir-school[1] maintainers [0]https://elixir-companies.com/en [1]https://elixirschool.com/en

Erlang handles heavy load VERY well, between work stealing schedulers and soft realtime via reduction counting (any program can be interrupted and stopped after any instruction and resumed transparently)

That is good. Then actual propper benchmarks will be remarkable.

However BEAM is not the only factor in this process. the entire hardware platform as well.

This is after all a lot about that nice and huge cpu.

I mean when you have all 5000 started why not let the do some work? Stress test it with a few real life scenarios for 48h and let us see some number.

I will consider it :)

Yes, but in Erlang, everything on every process is immutable and nothing is ever trying to write anywhere besides locally. Every variable assignment leaves the previous memory unchanged and fully accessible to anything directly referencing it.

It looks like it's Python, so it might be possible to use via https://github.com/livebook-dev/pythonx ? But the parallel huggingface/bumblebee idea was also good, hadn't seen or thought of, that definitely works for a lot of other models, curious if you get working! Some chance I'll play with this myself in a few months, so feel free to report back here or DM me!

I just decided to try this quickly and hit some issues on my Mac FYI, it might work better on Linux but I hit a compilation issue with `curated-tokenizers`, possibly from a typo in setup.py or pyproject.toml in curated-tokenizers, spotted by AI: -Wno-sign-compare-Wno-strict-prototypes should be -Wno-sign-compare -Wno-strict-prototypes so could perhaps fix with a PR to curated-tokenizers or by forking it...

Might well be other issues behind that, and unclear if need any other dependencies that kitten doesn't rely on directly like torch or torchaudio? but... not 5 mins easy, but looks like issues might be able to be worked through...

For reference this is all I was trying basically:

  Mix.install([:pythonx])

  Pythonx.uv_init("""
  [project]
  name = "project"
  version = "0.0.0"
  requires-python = ">=3.8"
  dependencies = [
    "kittentts @ https://github.com/KittenML/KittenTTS/releases/download/0.1/kittentts-0.1.0-py3-none-any.whl"
  ]
  """)

to get the above error.

So, OK, yes some specific assets are zero sum when defined narrowly…. But take Picassos. Well, ok, he’s been dead for 52 years, so sure, he’s not painting any more, but… he did… his paintings weren’t zero sum while he was alive, he created them and increased supply steadily during his life.

Real estate is the classic example, true, but precious metals? They’re zero sum in one sense, but what do you think mining does? It increases the supply and effectively amount of precious metals in the world. Same for drilling for oil I guess, though I don’t really want to defend of encourage that, but, it’s still not exactly zero sum, even if I don’t like it, because you can’t just count wealth that’s inaccessible as equivalent to wealth that is accessible. So 3 of your 4 examples are perfect examples that wealth is NOT really zero sum at all. And you can’t eat those. So what about food? Food production has been increased… what, 500x maybe in the last 100 years via agricultural technology investment and science. That’s a lot fewer people starving or going hungry… admittedly we now have the opposite problem via obesity epidemic, but, now here comes GLP-1 innovation which… also increases wealth? Wealth is a pretty tricky thing to define but if people are paying money for it voluntarily it seems to qualify.

Yes, not all things are zero-sum, but enough are that inequality really does matter. Take labor for example. There's only a limited number of skilled people. Who do those skilled people work for? The people that can give them the most money. So, instead of using their skills to build farms, housing, schools and other things that benefit a large number of people they use their skills to build yachts, mansions and manipulation algorithms. Demand from those with wealth increases the price of skilled labor to the point where people with no money can not afford it. Skilled people from poor communities move to the places where the rich throw their capital around, work on things that the wealthy think are important, and the communities they leave behind suffer as a result.