whynotwhynot

Will they be contributing back to FoundationDB(FDB)? I ask this because they had used FDB since 2014 to build the Snowflake metadata store, and they've supposedly advanced FDB in the process, and I assume some of those advances are generic and would benefit all FBD users. Now that they'll have the IPO cash, I hope they will contribute back. For example, I know FDB maintainers would love help with optimizing FDB for EKS and other managed K8s platforms on major clouds. Congrats on the IPO! I might buy a few shares :-)

bluetomcat's statement is in the realm of Relativistic Epistemology.

In general, epistemology is about the root of human knowledge, and why some statement of knowledge represents a justified belief, but those roots never terminate because as Feynman said the Why question never stops recurring, as we dig deeper. In other words, there is no objective truth or any thing for that matter (no pun intended) apart from what we observe (the idea of "primacy of consciousness over matter" per E. Schrödinger et al, a neurophenomenologist view of reality) which means that our justified beliefs depend on how we observe and what we can and cannot conceive of given our finite mental model.

I don't think epistemic relativism is the way to go about life as it basically puts a barrier to further inquiry and pursuit of a truth that we feel is there, and it's the act of digging that allows us to progress, and not the transient truths we derive along the way, as we dig deeper. It's almost as if the truth is a magnet with infinite power and infinite distance that keeps our consciousness in motion or that it sits behind the barrier between being and not being, life and death, etc.

In the wise words of Manuel, I know nothing.

Also, see Bohm's final paper on Hidden Variables and the Implicate Order, the most sane of all metaphysical thoughts that I've come across.

"Sean: There was one issue and that was when somebody went to upgrade something and didn’t follow the upgrade instructions. But for the stuff that we built, that was processed at the peak, about 80 million calculations second handling hundreds of thousands of incoming requests a second with packed full of data, which would blow up into like 80 million calculations a second run in for a year. Not one teeny tiny little issue that to me that’s beautiful. That’s beauty to me. Right?"

Sounds poetic enough to me to get into!

From a PL design perspective, I'm interested in finding out what new ideas it introduces to an already crowded field?

Rust is good example of a PL design that introduces new concepts (around ownership.)

Pony is another good example of PL design, for the same reason as Rust, but it differs in important ways by introducing Reference Capabilities. I tried to get some attention to it the other day: https://news.ycombinator.com/item?id=24201754

What new ideas does Elena introduce?

Yes

From 2017,

https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-wr...

I tried getting into Rust, but found its ownership model to be a bit too cumbersome (for me, maybe not for you.)

I'm playing with various PLs designed for safe concurrency, including this one called Pony:

https://news.ycombinator.com/item?id=24201754

Hopefully not off topic, as both Rust and Pony share a similar agenda.

" - It’s type safe. Really type safe. There’s a mathematical proof and everything.

- It’s memory safe. Ok, this comes with type safe, but it’s still interesting. There are no dangling pointers, no buffer overruns, heck, the language doesn’t even have the concept of null!

- It’s exception safe. There are no runtime exceptions. All exceptions have defined semantics, and they are always handled.

- It’s data-race free. Pony doesn’t have locks or atomic operations or anything like that. Instead, the type system ensures at compile time that your concurrent program can never have data races. So you can write highly concurrent code and never get it wrong.

- It’s deadlock free. This one is easy, because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist.

"

"By sharing only immutable data and exchanging only isolated data we can have safe concurrent programs without locks. The problem is that it’s very difficult to do that correctly. If you accidentally hang on to a reference to some isolated data you’ve handed over or change something you’ve shared as immutable then everything goes wrong. What you need is for the compiler to force you to live up to your promises. Pony reference capabilities allow the compiler to do just that."

"Reference capabilities allow you to label different bits of data based on how that data can be shared. The Pony compiler will then verify that you are in fact correctly using the data based on the labels you provide. Reference capabilities combined with Pony’s actor model of concurrency makes for a powerful pairing."

https://www.ponylang.io/discover/

Fair enough. Could you please describe other happy path scenarios? Is there an educational resource (blog post maybe?) that talks in depth about "happy path programming" in the general sense? Same applies to "self healing" I really want to know what the folks who came up with these phrases meant, in both specifics and the bigger picture. Thank you for the enlightenment so far!

FWIW, I wasn't aware that Elixir is not optimal for CPU-bound tasks. I use Go for highly concurrent servers, but it uses goroutines not a process per request, and mutexes and/or persistent channels to synchronize shared memory access.

So, both of you guys talk about API request handling.

How about some computational task where coding only the happy path means accurate calculated results for 80% of the cases?

I think my problem is the marketing hype with Elixir around "happy path" and "self healing" are too broad and resemble hype more than feature description. I'd be happy if those terms weren't used outside of marketing literature, until we have an AGI that can manage complexity on its own :)

That is seems to be more about the underlying infra (BEAM) than the language. I thought it was something specific to Elixir. I thought they meant it at the level of program logic, which is why it seemed very confusing.

I guess Lisp is about beauty and poetic justice and it shall remain in that realm.

I'll look into Elixir. Seems to have a healthy and growing ecosystem.

I'd like to invite you to the Other Side Of The Force, Grant.

http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were...

It's much more pretty over there.

I haven't looked at Elixir but I have read a bit about Supervisors which I think are an excellent idea for fault tolerant systems.

However, the phrase "self healing" is thrown around a lot in talks about Elixir, as if it's a magical feature of the language, without much explanation as to what it means to universally heal from faults (I think maybe they mean self healing strategies that the programmer authors and implements, not some AGI that rewrites the code on the fly to fix it, lol, but that's my gripe, mostly the hype around that... and "coding for the happy path" which is not really a rigorous statement either... maybe someone can tell me what is the happy path for an algorithm in my head without knowing the algorithm, because that somebody is me, and I don't really know my algorithms until I have thought through the not-so-happy path... I mostly code to explore what I need to specify rather than describe some specification I already have.)

Maybe Elixir is not for me. Or maybe it is. I need to learn more, and go past the hype.

For me, Lisp is an alien technology with great power that will never be matched, except by another Lisp.

So it was great to find out about LFE! I even appreciate the separate var/fn namespaces, like nouns and verbs in natural language, e.g. fight the good fight, and I can see how it comes in handy, yet it's a new PL concept for me, so I'm still processing it.

Great coincidence since I wanted to attract attention of HN crowd earlier today to another BEAM language: Lisp Flavored Erlang (LFE)

"[LFE] is the oldest sibling of the many BEAM languages that have been released since its inception (e.g., Elixir, Joxa, Luerl, Erlog, Haskerl, Clojerl, Hamler, etc.)"

I find this little example really cool:

https://lfe.io/books/tutorial/concurrent/dist.html

I've drank the Lisp kool-aid when I had to learn Clojure, but LFE is so much more powerful for building highly concurrent and distributed systems due to it being based on BEAM and having zero interop overhead with Erlang, while being a feature-complete Lisp.