mrdoops

Picking up Elixir is a decent way to get into backend distributed systems from a Ruby/Rails background.

The runtime isn't designed for fast numerical computations, but rather I/O, concurrency, and robustness. You can however get the best of both worlds by orchestrating the fast numerical computations (C++/Rust/C) with Ports and NIFs.

A market's throughput is limited by the number of participating actors. If a large percentage of the population can't participate, the market's capability to price, evaluate and represent value is hindered.

UBI makes sense for a purpose of bringing more buyer's/actors to the game. It's especially useful considering our dependence on jobs as the primary activating mechanism shows strain under the troubles of scaling human coordination and hiring. In a sort of backwards way we get more jobs when more people can contribute to the flow of money.

However UBI doesn't solve the problem of debt still piping the cash back into the hands of banks and other financial institutions. What are these UBI checks going to be spent on? Rent that's too high? Student loans for indulgent tuition prices? Without blocking the pipes from the poor to the the actors with pipes of their own, these throughput problems aren't solved more than delayed.

An actor is still a single actor, so if one actor has an over aggregation of wealth and has trouble spending it effectively the potential of that wealth is wasted when at least some actors don't have enough.

So surely trillions of dollars of UBI injected directly into the hands of the poor will stimulate the economy. But for how long until the cash starts to aggregate again into slower pools of cash where throughput is limited? In a sense we almost want inflation if these "overaggregators" are so abundant, but only if the population is maintained at a base level of wealth relative to the inflation. Otherwise the rich, who probably got rich by being more effective with their money respond to the market changes faster and the UBI stimulation is only temporary.

But if UBI causes significant inflation, and the pipes going directly to every individual have enough back pressure, it could be a great situation where the overaggregators lose value to inflation as they struggle to spend or invest.

Asking lots of questions and thinking through the trade offs of more than one possible implementation before coding. Writing your implementation plan on paper especially helps find those unknown unknowns before you code. If you have trouble stating the problem and your solution in words, that indicates an unknown to investigate.

I.e. do a little writing to help avoid coding the wrong thing.

Agreed. I guess my point is that we need to focus more on making declarative business rules systems more tenable as an approach in general. If we consider the framework + CRUD generators as the most productive way to build a web app (probably has been since Rails) - that's a result of tooling built around an approach. What happens when we focus similar efforts of tooling towards these Rule Based components?

If the code is clear and it's documented that's probably the best option in most circumstances. The hurdles for making a tenable configuration / logic-as-data system are much higher. Expert/rule-based systems are hard, but usually necessary in most systems of a size.

The question to think about is "how much will this cost the business to change over time?" A developer hour could cost between $30 - 150 / hr depending. For most businesses cost of development completely dwarfs infrastructure/server costs. If a few small changes like accepting options or avoiding hard-coded values takes a tiny bit more time upfront it's worth considering. If you don't know how the procedure will change, best make it clear, concise, and documented so you, or another developer can make it more flexible down the line. This cost and risk of development is also why the "buy first, develop second" strategy tends to be prevalent in IT decision making.

I guess my real pet peeve is that developers tend to make tooling for other developers and don't always put the same effort into non-developer tooling. If you think about the CRUD apps we build- so often it's on a mountain of tooling and abstractions to get it as productive as it is (Database + ORM + Web Framework). We should be focusing that same kind of effort in tooling development at declarative/point-and-click use cases so developer need-to-know out of the change equation more often.

This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I.e. when a frequently changing business process like a finite state machine for an approval procedure is only change-able by a developer that means there's always the cost of that developer's "need-to-know" for a straight forward change in the business operations. The cost of a given change is greater than a declarative capability that took into account operational changes in the first place.

That said hard coding business logic is often so much quicker to deploy that in many situations you just want to hard code the logic, deploy, get feedback, then introduce flexible to the kind of change needed then continue. If you have engineers who know how to ask the kind of questions that get to the real requirements (usually not juniors) you can have a maintainable code base. Worst case scenario is if you have the "yes I shall do anything and everything with my new code power" developers who just implement out of eagerness and conflict avoidance; this can be the worst of every world: hard coded business logic so convoluted only the junior knows how to make changes.

A few reasons. First is that developer's don't buy it, non-technicals do, and it's got serious vendor lock-in capability. The other reason is that an excel-formula-wizard-type user can basically google his/her way to building a CRUD app for the business - and it works for the most part. Those combined are a billion dollar company. Us developers might not like it, but it has huge business value one way or another.

This area of research is fascinating - my favorite part of research in this area last 6 months is finding DAGs everywhere. More or less Dataflow models work by lifting the computational dependencies into data and breaking each compute step into a small enough piece so that they're composable and can replicate across machines arbitrarily. The dependencies between each step is usually modeled as some kind of DAG in a simple case the output of one step feeds into another. In more complex cases you have logical (if this then that) dependencies for error handling and branching cases.

I think the Dataflow paper: https://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf

and the MillWheel paper in particular are good reads about the problem: https://static.googleusercontent.com/media/research.google.c...

What's especially interesting to me is that the same approach is used for rule/workflow engines. Although the use-cases are somewhat different and the graph structure isn't usually the same - they're still modeling compute steps in a graph just with more conditional logic.

The PLC/DCS/SCADA world hasn't really caught up to modern open-source software in a lot of cultural ways. Lots of proprietary components and "pay-to-learn" practices. I expect there's software-engineer types who would venture into the hard-real-time control systems world if it were as open-source and tinker-friendly as something like Rails. Nowadays someone like Microsoft has to go open source to have any hope of capturing developer mind share for something like .NET.

I'd like to see a 2 year study on absence of Omega-6 and/or Seed oils in the diet.

Agreed. With 7nm fresh off the presses and 5nm on the way we're should start seeing some efficient SoC's to do the 3D mapping AR needs. Even if glasses aren't ready to be the primary interface - phones with the hardware to accurately map and overlay the world still has a lot of promise.

First thing I'd do is go through the Getting Started guide on the main page: https://elixir-lang.org/getting-started/introduction.html to get a feel for Elixir. For setting up an Elixir environment, I'd use ASDF - this guide is good: https://gist.github.com/rubencaro/6a28138a40e629b06470 - but the getting started guide's instructions will work too. The easiest editor for Elixir is probably VSCode with the ElixirLS extension.

After tinkering around in IEX and doing the Getting Started Guide, I'd do Dave Thomas's course (https://codestool.coding-gnome.com/courses/elixir-for-progra...) and read Elixir in Action by Sasa Juric. Dave Thomas's course will get you through the basics of the language and the important concepts step by step. Elixir in Action will go further into the concurrency model that makes Elixir unique.

Finally if you want to build a web app I'd go through the Phoenix Guides: https://hexdocs.pm/phoenix/overview.html#content . Those guides will give you a good example of what a real Elixir/Phoenix Web Application looks like using a database with pooling and request concurrency out of the box. The Programming Phoenix book will take that further (https://pragprog.com/book/phoenix14/programming-phoenix-1-4).

If you want more practice writing functions and algorithms I'd recommend Exercism's Elixir track: https://exercism.io/tracks/elixir or Project Euler (https://projecteuler.net).

I was about 2 years into professional development when I started getting into Elixir. Recursion was a week or two of "err what?" then I got it. Functional composition is way easier to reason about than OOP design patterns (and should be since OOP design patterns are just over-complicated Category Theory).

The tooling gets out of the way, so a newbie is less likely to run into roadblocks. IEX is the best REPL I've worked with. Phoenix is much simpler to reason about than similar frameworks like Rails. And the docs are clean and consistent (+ dark mode). It was really easy to navigate through the docs, try things out in IEX, and get things working. It's just modules and functions. There's no classes, base-classes, abstract-classes, inheritance, instantiations and what-not. Just modules and functions. I doubt there's a better way to learn back-end development (DBs, Queues, Concurrency, PubSub, Distributed Systems, etc.) than Elixir.

A buddy of mine has been getting into Elixir recently while going to school for CS. The school's curriculum is mostly C#, Java, PHP, and what-not. He says Elixir demotivates him from some of the homework because everything in Elixir would be way easier.

What do y'all recommend for frequently updating charts i.e. streaming data sources with histograms, etc?

They rolled out debounce and throttle fairly recently. There's also some very compelling work on a component abstraction (runs in same Liveview process).

Most solar companies I know of do removal fees of some kind. Costs of operating past a certain point in the installation process make a fee-free cancellation a risky thing.

Beyond Tesla's rental I'd also like to see combinations of financing and service / upgrade & optimization contracts. Power usage, and optimal tech changes over time. Most solar installation contracts are inflexible to modification over time. This is mostly due to the single transactional nature between financing companies and installers.

Trial and error as a programmer dealing with depression and anxiety accounts for a lot, but for resources I'd point you to Robert Sapolsky's lectures on Behavioral Biology (here: https://youtu.be/NNnIGh9g6fA). Sapolsky's lectures are great for getting a Biology perspective to how human's operate. Jordan Peterson's has lectures on Personality (here: https://youtu.be/kYYJlNbV1OM) which are also great and echo similar ideas from a Psychology perspective.

Motivation is usually a product of mental health. Mental health is a product of a variety of things like work-life-balance, good sleep, healthy diet, physical exercise, and measured progression towards realistic goals. Optimize and improve on those, and you'll have more motivation and mental energy overall.

Since full time work rarely makes good use of focused mental resources, you might be lucky if you have a couple hours in the evening to work on personal projects. For weekends my experience was I needed Saturday to recover - it's hard to focus on a screen and sit in a chair. But by Sunday I can devote focus into personal projects. Still not very many hours to use. It helps to have no social life and family responsibilities, but I'd rather have those than more programming time.

Overall it's hard to have enough motivation and mental energy while working 8 hours a day, but you can optimize for health and get some more utility out of your free time.

Yeah, at the very least I expect to see Processes used like Liveview when you need containers/reactors to state and/or run-time control for messages between components. I wonder if an approach like Svelte (https://github.com/sveltejs/svelte) where it compiles into DOM updating code can be enhanced with the concurrency the BEAM provides.

It's amazing so much has been done already considering the team only started last February. Writing all those BIFs can't be easy! Lumen is definitely a compelling challenge.

My favorite part about the presentation was the correlations between the DOM tree and a supervision tree. If you've looked into the Scenic project (https://github.com/boydm/scenic) you know how this Process & Supervision model shows real promise for client-side UI concurrency. As your states are changing you don't want one bad state to crash and cascade elsewhere - supervision trees lets you contain and recover from failures gracefully.

I'll be honest I didn't think it would be possible to implement something like the BEAM's preemptive scheduler in WebAssembly until I saw the presentation. Turns out it's very doable with continuations. The timing should be right in the next couple years as both Lumen and some of the bigger components of WebAssembly maturity kick into gear. Similar high level language/runtime -> WebAssembly projects like Blazor(C#) are also pending features like more native control over the DOM without going through JS interfaces (see here: https://github.com/WebAssembly/interface-types/blob/master/p... for more technical details).

Even if client-side UI frameworks don't pan out for Lumen, I can see Lumen being valuable for edge-computation especially where concurrency and fault-tolerance are important.

Productivity is subjective to what's important for the team or organization. I can be productively wasting time if that's my goal. A 10x programmer with superhuman coding powers doesn't really exist, but a programmer who delivers 10x more value to a team or shared goal can look that way.

I find the key point to language adoption is that self-selection that occurs. What type of person and their personality does an ecosystem attract and what is that type of person good at?

The BEAM ecosystem is all about fault-tolerance, distribution, and concurrency. These BEAM concepts could be described as "upper ladder" ideas: they require more prerequisite understanding of systems engineering to appreciate. Despite being a fallacy of composition, to compare a given Erlang vs Ruby/Rails developer may be useful to consider.

A person who invests in learning Ruby/Rails might be motivated to do so because of that bootstrapping mindset of MVP's and failing fast. Our average Rails developer might be rolling the dice for that "killer app" opportunity more often than our Erlang developer prioritizing concurrency and reliability. This may be because those BEAM features are more useful at a later stage of product development. So while the BEAM features are uniquely powerful if they require an upper-ladder understanding our MVP-developer doesn't yet have - they're unlikely to pick Erlang as tool-set to invest in.

If we accept that the BEAM is good at infrastructure and that doesn't result in as many opportunities for these hype-cycle-causing-killer-apps, than what could be changed in the ecosystem to support this goal? Can we get both the later stage benefits of reliability and concurrency in addition to the early-stage productivity benefits? Maybe this early-stage development focus is where Elixir will break out of the infrastructure-niche Erlang seems to be in. Can Elixir's tooling reach a short enough new-product feedback loop more potential killer-apps get deployed into production? I think as Elixir brings in some different personalities to the ecosystem we could see more killer apps but that idea -> production feedback loop seems to be the key component.

Syntax is a subjective concern for sure. My experience has been that Erlang takes a little more effort and time to read fluidly, but only when first learning. I think this is because Erlang uses visually subtle tokens for important language distinctions (upper vs lower caps and periods being the primary culprits). Now that I've spent enough time in the ecosystem reading Erlang isn't really a problem, but Elixir's syntax felt like it took less mental effort to read when starting out.

I think Elixir making different token choices for these distinct ideas is the main reason for readability improvements. Especially since Erlang has less different tokens overall which you'd think would help reduce the noise.

Using the Lightning Web Components without the Salesforce back-end is a compelling idea. The design system is well tuned for standard business requirements (rich data-tables, modals, forms, etc.). If there's a good story around using those UI components without having to use the Salesforce back-end this could have value. The Salesforce back-end is a scary entity-attribute-value system coupled to an Oracle database on top of a layer-cake of legacy multi-tenant architecture constraints and years of Java/C code.

For sure. If there are two flavors of OOP: the Imperative OOP we're familiar with (Ruby, Java, Python, etc.) and the Message oriented variety that Alan Kay described, then Elixir/Erlang are more the Message Oriented flavor.

While you can write either flavor in most languages (even Elixir if you abuse ETS), concurrency's requirements for immutability and run-time support start becoming distinguishing factors.

How to you intend to account for merit and credibility across data sources?

The way I see it we've scaled our communication of information far beyond are ability to scale our assessment of credibility and merit of said information. This problem of merit is where I see the big gap in our tools. Are you planning on doing some kind of credibility assessments per-user based on content written/consumed?

Golden's feature-set is similar in many ways to app's I've prototyped towards this problem; I'd love to hear your thoughts on the subject.

My bet is LiveView will become the king of the fast prototype. It doesn't do SPA, but it does damn near everything else with ease and so few lines of code.

Long term I'd like to see what sort of an effect using their own Semi's for delivery would bring. Self driving or not having a fully consolidated supply chain you can tune and rollout for your own needs is a lot of leverage. Logistics is hard, but also a known problem that Tesla should have plenty of tools to deal with.

You want a couple things for an engineering laptop: Linux support, good hardware (screen, keyboard, build, trackpad, etc), and enterprise guarantees.

XPS sort of does that, but you're still dealing with Dell which has it's own hiccups (variable build quality, archaic sales methods, etc.), also the XPS line isn't quite commercial grade. Thinkpads typically have good Linux support, but sometimes as with these last 6th gen X1's it takes some work to get it right.

The hard part is ultimately enterprise reliability. I want to confidence I can buy 2000 of these for my army of engineers and not overload IT with issues. This kind of support is common enough, but not necessarily for Linux laptops. Hell it'd probably be easier with Linux, the issue is more if the market is big enough to support the operational costs of enterprise support.