greener_grass

I agree, yet Make, CMake or even Node package scripts are more popular than Bazel.

Everyone says they want a "tiny" "minimal" "lean" build-system, but there is lots of real complexity in these areas:

- Cross-compilation and target platform information

- Fetching dependencies

- Toolchains

I'm not sure a system that solves these would still be considered minimal by most, but those are table-stakes features in my view.

If you don't need these things, maybe stick with Make?

My experience is that the less done in GitHub actions the better.

I tend to prefer either:

- Using a build-system (e.g. Make) to encode logic and just invoke that from GitHub Actions; or

- Writing a small CLI program and then invoke that from GitHub Actions

It's so much easier to debug this stuff locally than in CI.

So an interesting trick, but I don't see where it would be useful.

Very few languages let you have multiple versions of the same package in one project; fewer let you use functions from both versions together; and even fewer make this easy!

This is something that would be enabled with hash identifiers and no modules:

    let foo_1 = universe.mega_corp.finance_dept.team_alpha@v1.0.0.foo
    let foo_2 = universe.mega_corp.finance_dept.team_alpha@v2.0.0.foo

    let compare_old_new_foo(x) =
      foo_2(x) - foo_1(x)

There would be a corresponding lock-file to make this reproducible:

    {
      "universe.mega_corp.finance_dept.team_alpha": {
        "v1.0.0": "aabbcc",
        "v2.0.0": "xxyyzz"
      }
    }

I think this is pretty neat!

Readers might enjoy Mozart Was a Red, a play by Murray Rothbard

https://www.youtube.com/watch?v=KIk5C2qsRH8

You would do something like:

    open universe.mega_corp.finance_dept.team_alpha

Then when you use `foo`, the compiler would know you mean `universe.mega_corp.finance_dept.team_alpha.foo`.

There will probably need to be some kind of lock-file or hash stored with the source-code so that we know precisely which version of `universe.mega_corp.finance_dept.team_alpha.foo` was resolved.

I've definitely noticed more anti-gary astro-turfing recently. He seems to have rattled someone...

This could be achieved with a hierarchical namespacing scheme for functions, no?

    universe.mega_corp.finance_dept.team_alpha.foo

But to use `universe.mega_corp.finance_dept.team_alpha.foo` in your application, you don't import a module, just the function `foo`.

Who controls what goes into the namespace `universe.mega_corp.finance_dept.team_alpha`? That would be Team Alpha in the Finance Department of Mega Corp.

I guess this is like tree-shaking by default.

I disagree - if the Vision Pro had some strong use-cases then developers would hold their nose and make apps for it. The platforms that get apps are the ones where businesses see value in delivering for them. Of course businesses prefer it when making apps is easier (read: cheaper) but this is not a primary driver.

The companies that might acquire Reddit are affected by tariffs.

Efficient hiring practices?

Without access to the .NET ecosystem it would be dead in the water

F# allows you to use React pretty much directly, but it has still been only a modest success.

The JS approach is worse than a do-notation approach because it is not extensible. Now we are stuck without cancellation token propagation (forever?)

This already exists with F#, OCaml, Scala, Haskell... it doesn't seem to be a big draw.

When developing something I tend to have lots of programs open:

- The editor

- Several terminal windows

- Some docs

- GitHub PRs

- AWS console

- Admin tools like PgAdmin

- Teams, Slack, etc.

When screen-sharing with Zed, do I only get to share the editor?

Because (clunky as they are) video call apps let me share everything and this is table-stakes for collaboration.

There's a small chance they will get a cult following with more exposure and lead to increase in value of the IP.

We already have many great GC'd functional languages at that performance level.

I first learned about Roc from this talk:

https://www.youtube.com/watch?v=vzfy4EKwG_Y

That's a niche that is not currently filled (well, maybe MLTon) and that has me very excited! I'm sure I'm not alone here.

The author learns that Java is not a Functional Programming language; lambdas ain't enough!

Yes, I read the post.

I don't understand why the goal is not to (eventually) implement Roc in Roc, maybe with a dash of something else for the "platform".

Roc is pitched as a general purpose functional programming language with great performance.

How does a compiler not fall under this category?

OCaml allows mutation via reference cells.

So why is it a non-goal of Roc to be implemented with this approach?

I can't help but feel like the Roc team has an attitude of "imperative programming for me, but not for thee".

And now they are doubling down on that by moving from "OCaml meets C++" to "C, the good parts"!

If FP isn't good for writing a compiler, what is it good for?

> While we're at it, we also want to convert it to use recursive descent; it was originally written using parser combinators because that was what I was comfortable with at the time

Aren't parser combinators just one way to do recursive descent?

There's no good reason FSI can't be improved to handle this though

> other F# script files

This is where it breaks down a bit.

Importing the same script file twice leads to errors, so you must manually ensure exactly once imports across your dependency tree of scripts.

This is where C/C++ code reaches for include guards, but F# does not have a define pre-processor command (unlike C#).

In F# scripts you can add dependencies directly from Nuget like so:

    #r "nuget: NodaTime, 3.2.1"

    open NodaTime

    let now = SystemClock.Instance.GetCurrentInstant()

    printfn "%A" now

Are you Velocio? Thanks for all the hard work!

Sad that lufguss will probably become just another channel on one of the big platforms. RIP.

JavaScript lambdas are better for FP than those in Python because they can be on multiple lines.

If going untyped JS, then you don't have the same restrictions as Java.

If going typed, then the TypeScript type-system is more powerful than Java's.