substation13

Is there any source available for this?

Rich Hickey calls these protocols. In Haskell or Rust you get them via traits.

Many believe that F# is better for functional code and C# is better for imperative code. Hence F# immutable core and C# immutable shell.

But I think this is a myth. F# the language is better than C# at most things and certainly better overall. If you are going to use F#, you may as well go all in and get all of the benefits.

For web services, Giraffe or Suave combinators are much easier to reason about than ASP.NET MVC patterns.

I'm not convinced Tor could scale to a significant percentage of internet traffic using it.

Yes, it can be.

1. Loading data

2. Running algorithms that benefit from shared memory

3. Serving the model (if it's not being output to some portable format)

There are also general benefits of using one language across a project. Because Python is weak on these things, we end up using multiple languages.

Those are real issues though.

Anyone else read the headline and go straight through to the comments?

I think that HN, which has added deliberate friction elsewhere on the site, should consider hiding the comments link until you have clicked through to the article.

It's a bit like how Rust limits dangerous operations to unsafe blocks

> Second, this is still fine. Don't make changes outside of the IAC control. And if you do make them, retro-fix the IAC files until there is no diff with the actual state.

This doesn't work in practice. Some aspects of the business want to tweak things and it should be reasonably guaranteed that the automated side never touches it.

Terraform state gives this assurance because it won't destroy resources not under its state.

With Terraform you can statically analyze the infrastructure definition with some guarantees of determinism etc. Arbitrary execution is allowed, as you say, but only in well-contained places, such as local_exec.

How can this work if, say, TypeScript is used as the definition language?

Exactly. If you want portability across clouds, Terraform ain't it. The only way I know of to achieve that right now (for any reasonably complex architecture) is:

- Minimal amount of Terraform to deploy Kubernetes (which is different for each cloud provider)

- Helm (or similar) for deploying to Kubernetes

But then you have Kubernets to deal with.

Adding a "real" programming language makes certain things easier, such as abstraction, but IMO they are too powerful for the task at hand. Do we really want an infrastructure description to be able to execute arbitrary code?

I would love LLMs to write documentation for me, even though I don't trust them with the code.

Stacking shelves in a supermarket is a perfect example. 1000s of products means that a bit of experience is required to know where everything goes in order to quickly stack. With a HUD, workers become productive much faster (and are more inter-changeable) - which is something large enterprises love.

A job or a house: choose one

Using this to push Brainfuck at work

Function coloring is orthogonal to the underlying mechanism.

You can think of the Java / Go approach as adding the bind points automatically.

If the prices have significantly risen since you purchased (as they have for most buyers) then moving even to the same quality of house makes you a net buyer because you need to take on more financing.

Remember, the day you buy a house, you are no richer. This is because the asset (house) is offset by the liability (the mortgage).

I wonder if wages have risen in response to this? You cannot operate a business that doesn't pay staff enough to live for very long.

I can see LLMs as a novel front-end for a traditional search engine.

It's really easy to get an LLM to hallucinate by asking an open ended question - the type typically answered by a Google search or checking Wikiedpia. However, this is not the best application of LLMs. This criticism is getting old.

LLMs are great at:

- Text synthesis given all of the facts in a prompt (expand these bullet points)

- Summarization (condense this text)

- Data extraction (fit this data into this schema)

- Fiction (virtual characters, scripts, etc.)

They will dramatically change these industries.

Free speech does not allow the right to do harm. We can debate where exactly that line is, but in my book protesting right outside of a clinic is harassment.

We can't let this "bundling" of laws allow things to slip though the net. The solution is to make a new bill with the good parts.

How should users write async, futures, option, result, etc. in Scrap?

My hunch is that if you do not put the syntax into the language, then it will be hard for the community to standardize on one preprocessing tool.

OCaml (which I am a fan of!) struggles with fragmentation here.

Hello!

This looks really interesting to me.

There is a feature I would like that I have never seen in a scripting language, and I wonder if Scrap might support it:

> Monadic bind points and applicative join points in the script language

Hopefully an example can convey what I mean.

Bind:

    do {
      let! x = some_value_in_a_monad

      x + 1
    }

Applicative:

    do {
      let! x = some_value_in_a_monad
      and! y = another_value_in_a_monad

      (x + y) * y
    }

Now when I embed this script, I would like my runtime interpreter to provide implementations of `let!` and `and!`. The script author defines the bind points and the runtime defines the effects.

Is this possible in Scrap?

I believe that road wear is proportional to mass ^ 4

> Why would a company use ocaml?

Why wouldn't a company use Brainfuck?