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.
I've started reading Bohm's paper- it's fascinating, thank you for the recommendation. The focus on the "verb" or "happening" rather than the particular seems to line up with Levinas. In turn, I'd highly recommend checking out this paper "Essential Vulnerabilities: Plato and Levinas on Relations to the Other" if you resonate with Hidden Variables: https://www.jstor.org/stable/j.ctv3znz3r
Considering the topic of the article, it's interesting that this comment was downvoted to [dead]. Humans seem to have a strong dislike for the general idea that there are limits to our knowledge of reality, and it seems to me that the magnitude of that dislike increases as a function of the intelligence of the individual (the smarter one is, the more disgust experienced during discussion of the unknown/unknowable).
We all know absolutely there are limits - quick tell me the first words ever uttered by any human being! We can't for it has been lost to entropy, whole converted into the same end state regardless of possible outcomes. It isn't even "find what word was written on this paper before it was immersed in ink and smoother" but "find out what word was written on the paper after it was burnt and the carbon used through a cycle of bacteria, plant, animal, and minerals for a few millenia.
The rhetoric is particularly galling because it is self-reinforcing willful ignorance - refusing to learn and then saying "We cannot possibly know!" instead of trying to stretch our limits.
Once attention is drawn to it, yes. But in our real time behaviours and thoughts, at the low level detail of how the human mind works, do we sometimes ~forget? Does man sometimes suffer from hubris or other imperfections?
> The rhetoric is particularly galling because it is self-reinforcing willful ignorance
That is but one of many possible interpretations of my words, as is often the case, but not always realized.
> refusing to learn and then saying "We cannot possibly know!" instead of trying to stretch our limits.
I've made no such claim (but to be clear, I'm not sure if you were making that assertion). I've noticed that the human mind is often able to "see" things that aren't there (something else that seems to be often overlooked, particularly when convenient for the person doing the looking) - it is an incredibly powerful entity.
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
I heard a good podcast about pony recently: https://corecursive.com/055-unproven-with-sean-allen-1/ - it’s about how Wallaroo Labs came to use it. They talk about using it to deal with some really interesting engineering challenges. One of the things that I found interesting is their comparison to Rust was that at least at the time Rust didn’t have a comparable runtime to Pony’s high performance actor based one.
It's a shame Pony does not get enough attention as it's a very nice language that as you say, introduces truly innovative ideas.
I wrote some code in it and it was extremely fast, in the same order of magnitude as Rust/C. But it was quite complex to write, unfortunately, compared to the Rust version (which also guarantees no deadlocks and safe concurrency). On the other hand, the code looked quite a lot prettier due to its Python-like syntax.
Anyway, it's one of those tools I keep in the shed, hoping to one day find a good use for it... just hope it continues evolving (specially running Actors on multiple machines would be a real killer feature - making Pony like a typed Erlang with beautiful syntax).
I'd like to find an excuse to use it for something just to try it out at some point! Being able to run it distributed like Erlang would be really cool, interesting idea :)
"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?"
Just so you know, it appears you've been shadow banned. No idea why. I would suggest joining lobste.rs, an HN clone built out of frustration of HN's lack of transparency on banning.
I've seen a few people on HN offer invites to other users after a conversation regarding the site. I've also seen lobste.rs threads where users suggest preventing new users from joining and even suggesting deleting existing users so they can preserve whatever perceived superiority their site has, so I don't expect them to be very open in general.
The point is also to vouch for someone when an invite is sent. At least in my mind, as in it's officially done, if the invitee misbehaves, it's kind of the responsibility of the inviter. Every profile has who invited who.
Then how does the inviter know, that they can vouch for the invitee? Perhaps no one there knows me. Why would anyone vouch for someone they don't know? Wouldn't that make vouching a useless hurdle?
> Then how does the inviter know, that they can vouch for the invitee?
AFAIK you aren't accountable for your invitees on a day-to-day basis. It just reflects poorly on you if you invite many poorly behaved people - this isn't substantially different from everyday life.
> Perhaps no one there knows me. Why would anyone vouch for someone they don't know?
Some people do invite everyone who asks. They can have their invite rights disabled or in extreme cases be banned from the site. This is relatively rare.
Lobste.rs has a small audience and 3 moderators. The moderation is also much more active than HN - moderators will send private warnings, delete off-topic posts, etc. Moderator actions are publicly visible at https://lobste.rs/moderations. Vouching raises the barrier to entry and allows the moderators to keep up with the workload.
"
- 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."
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.
It's not that complicated. A relatable example would be writing an API endpoint that receives data and then you do something with that data.
1. Write the endpoint so it works for the expected data.
2. You're done
That's it. You don't need to worry about anyone sending you malformed payloads or fuzzing your API. You can ignore it. They cannot exploit anything, they cannot crash BEAM. It will keep working.
Maybe they'll run you out of memory or CPU or bandwidth, but those are problems solved at other layers (unless you include rate limiting in your application).
Ignore all errors you do not need to explicitly handle. That's the whole point. It's wonderful.
Maybe you can do this in other languages with worker pools and supervisors, but it will be very expensive and high latency due to the cost of OS process forking and you're also wasting a lot of resource on context switches with that design anyway.
My 'A-ha' moment with Elixir was exactly your example.
Both me and a friend were building an app that ingests cryptocurrency data and stores it in a database for later analysis. The important part was that we wanted data at regular intervals. I'm not much into all this but this is what was asked of us. He wrote the app in Python; I wrote it in Elixir.
Turns out the API's of the various exchanges are (or were) atrocious. We'd get responses ranging from weird error codes to malformed data to timeouts. API's would randomly change. It was a mess.
My app just chugged along, a process per request per api endpoint. When some of these endpoints 'misbehaved' the others just kept going.
His app kept crashing, restart, and so one misbehaving endpoint would cause trouble for all the other ones. He had to add try...catch statements and fix the problems. I would just look at my logs, update the happy-path code, push it, and recompile() in the REPL.
I also have a bunch of personal projects chugging along on my VPS. They actively handle requests a few times per hour at least, by me, and they're doing fine despite the fact that I was quick about it and only wrote the 'happy path'. There's crashes and errors all over the place, and yet when one part crashes the rest just keeps going. It's been a rare occasion where the entire supervision tree failed and the app gave up.
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 :)
I dunno. I'd say it's rather obvious that it's not a magical solution to everything. For one, Elixir is too slow for computation-heavy stuff.
I just gave an example of how happy path programming works in a use case that is pretty common to my day to day. A lot of other stuff I do is similar enough that the same applies, and that's just my experience, not marketing hype.
Some articles might be a little over-excited, but I don't think I've generally read articles that claim Elixir is God's gift to programmers ;). And in situations where Elixir does help, it can be very exciting.
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.
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.
The underlying infra is not decouplable from the language. The beam is first and foremost designed to get stuff done easy and without error, not to be beautiful and poetic. Doesn't mean it can't be beautiful! And programming is fun because it feels like programming with training wheels on.
Supervisors are only the beginning of the journey to fault tolerance in the BEAM... There's so much you can do; one way of thinking about it is that you get very smart garbage collection on arbitrary system resources, tied to concurrent threads, and you can link threads so they fall in the same failure domain.
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'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.
