emccue

Okay this is cool.

I think mechanically the plans for ScopeLocals can be a part of implementing a scheme like that. Either way - I need to read this thoroughly in the morning.

Can you elaborate more?

All of the parts that throw `InterruptedException` are handling the thread interrupt cancelation mechanism.

There is also the example with the atomic boolean quit flag.

I'm not convinced that Go has any unique mechanisms here. Just like Java you can't forcefully kill a thread without that thread's cooperation.

No, I understand how Loom limits the amount of stuff on the stack. Its just I thought threads always had those large stacks.

Based on what the top person said, I'm thinking that they don't get a large stacks until they cross some threshold of use, but I want to make sure.

Hypothetically there is a version of "static Java" that could start to encroach upon Go's domain. This may or may not come out of Project Leyden, but I think for the reason the other commenter gave GraalVM isn't exactly it.

Still closer though, and GraalVM native images are pretty cool.

https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...

Here is the part where I admit that I am an idiot and don't actually know.

All I do know is that in Java I cannot create this many threads and in the talks given about Project Loom this is given as the explanation as to why.

https://www.youtube.com/watch?v=EO9oMiL1fFo @ ~4:00

Is it maybe not the actual spawning but some "switch" that flips once you start using the thread?

I'll update the post or leave a comment with a correction once I understand exactly what you mean

True, but I didn't write any of the Go here. Somewhat out of my wheelhouse

Yeah - ConcurrentHashMap makes the most sense. I left it off just because I thought it would be easier to see the parallel with the Go code.

Datalevin is good, but its more useful in the same realm as sqlite

In this respect XTDB has a more directly useful model

Feel free to reach out via any of the contact info on my github. The more the merrier chasing this magic dragon.

I think this is true - you will have an easier time not blazing new trails in general - but the need of ledger-like functionality isn't the distinguishing factor.

Preserving the history of all changes isn't just for reconstructing that history later, it's a central component in maintaining ACID while allowing for distributed readers.

Datomic has a singular transactor - node that can accept writes. So all transactions happen in sequence and consistency is maintained within the data model.

So your database goes

DB (0 transactions) -> DB' (1 transaction committed) -> DB'' (2 transactions committed)

With normal databases, when DB'' is created, DB' is lost. You change stuff in place. This means that anyone wanting to observe a consistent view of the database needs to coordinate with writes. This is why SQL dbs are single giant machines.

For Cassandra, Dynamo, Mongo, etc you still change stuff in place, but you just accept that things will be potentially inconsistent ("eventually consistent") for your readers. Once you drop that part of ACID you can scale your readers and your writers arbitrarily.

With Datomic DB, DB', and DB'' are still maintained. If you want to read the database "now" you can get a handle to the state that your reader thinks is the most recent. This might not be behind the absolute newest state that the transactor knows about, but it is still a consistent view of the database.

Its because of this you can scale your read nodes independently of the system. Because if you are reading DB' you know the value of that won't change you can load chunks of the indexes into the memory for caching and even embed the querying into the application making queries.

The proprietary-ness and JVM-ness of Datomic are its biggest weaknesses. I choose to believe those weaknesses can be addressed.

As the world stands today, it makes sense to use Datomic if you are writing code on the JVM and are willing to pay for the database and associated support.

In a hypothetical future world where the data model and query approaches have more widespread open source adoption it is competitive for a lot of the same use cases.

If anyone is interested, I am attempting to revive an open source clone of Datomic called EVA.

As is the original codebase works fine, its just unmaintained. My hope is to clean up the code, make an HTTP layer for a remote peer, and make a Rust embedded peer so that this sort of Database can finally escape the JVM.

https://github.com/bowbahdoe/eva

If you want to use something open source today that has the same query language but a different data model, https://xtdb.com/ is high quality.

To be clear, I'm no stranger to Lisps. I use Clojure a ton for personal stuff and on occasion have found ways to sneak it in to production.

The difference there is that Clojure isn't responsible for giving a wide enough ecosystem to justify investment, it just yoinks it from Java.

Racket doesn't have that ecosystem and probably never will. Macros on the level of common lisp and clojure are already found in those places. Racket gives, and seems to base it's pitch around, a far more flexible hammer than classic lisp macros.

But it doesn't do anything to offset the downsides of a small community or justify why that more powerful "actual mini language" level DSL is something to care about.

I am well aware of how macros can let you add your own language features and conveniences specific to your project. Homoiconicity is an all around neat property to have.

I'm just not buying a "beating the averages" style "you just see it as blub" explanation either. Mini languages do have niche uses. I acknowledge that. ANTLR wouldn't have users if they didn't. It's just not something I think is worth writing home about.

Weird nitpick, but "No Makefiles required" is an odd selling point to me. I haven't seen or used a Makefile in eons, and I would wager a decent chunk of programmers never needed to.

I'm not sure how to describe the feeling this creates. Like...I can feel the authors other experiences shine through or something to that effect.

There was a talk awhile ago by John A. De Goes where he asserted roughly that Scala's then pitch of "combines object oriented and functional programming" was basically gobbledygook from the standpoint of "why would I use this language."

https://youtu.be/v8IQ-X2HkGE

I feel much the same way about Racket. Cool, very advanced DSLs and mini languages...what does that give me? What can I do with that?

Most of the page is dedicated to justifying "no wait everyone, we have the bare minimum number of libraries" or waxing poetic about the mini language concept.

What is the reason to use this over a less "lexically powerful" lisp like Clojure? What is the reason to use this over one of the boring old stalwarts like Java or Python?

Can I read from a Kafka queue? Can I call into AWS? Google Cloud? How strong are the libraries, and what would I have to commit to writing myself?

I actually do not understand why I would use Racket, and this page doesn't help.

This is why I like transparent sql libraries like https://www.hugsql.org/

Just writing sql and maintaining and testing it like regular code is a perfectly reasonable thing to do.

Not to mention that having sql be callable as an actual function in the programming language that the rest of your application is written in is just so much more comfortable than having small bits of sql scattered about in strings.

Oof magoof