mrdoops

Generate a temporary link that, when clicked sends an event to your system to deprecate the link and redirect the user to a presigned S3 download. In my case the file attachment was the product and it was important the system know when someone had downloaded, but a backend system that keeps temporary urls and requests a temporary download link from the file provider is a useful pattern. Nice thing about signed links is your server doesn't have to handle the file - it's between the client and storage provider.

There's different kinds of "fast" is the problem.

Are you juggling lots of messages concurrently and orchestrating across complex topologies of nodes? A BEAM language is going to excel. That's why Whatsapp, Discord, and RabbitMQ use Erlang/Elixir.

Are you trying to go really fast in a straight and simple concurrency scenario? Go/Java/C++/Rust is going to be faster than a BEAM language in those scenarios.

You won't want to implement a complex concurrency run-time in Java whereas Elixir is not a good choice for a 3D game engine.

Still, there's nothing wrong with using both.

I'm liking the trend of designing runtime-behaviour agnostic libraries in Elixir. We get such powerful runtime capabilities with OTP, but indulged in the wrong context our cool OTP processes can be imposing assumptions onto our users.

I'd like to see some kind of generic HTTP contract or REST-API client builder library next so we can have swappable HTTP adapters (e.g. Mint/Hackney). I don't want to depend on a library like HTTPoison or Tesla directly when making a client, instead just generic Request/Response structs or protocols. That way an internal project can use a single HTTP adapter across all REST integrations rather than whatever the library author chose to use.

It's not strictly a per-company problem. The incentives are for per-watt i.e. bigger system = bigger commission for the company instead of maximizing customer savings with Solar. The incentives don't align customers, sales, utilities, and financial providers.

Authority (City, Utility, etc.) typically push and constrain the installation at least 3-6 weeks and they rarely actually know Solar well enough to be a real 'Authority'. Lots of poorly implemented review procedures from untrained city officials and inspectors. Many unnecessary revisions, nitpicks, and expensive truck rolls surface here.

Then we also have Sales and Financing Providers who have the most leverage out of the stakeholders. High leverage also means they tend to get the biggest cut for a given Solar contract. High commissions and high fees or they leave the installation company who has to fulfill a 2-6 month-payout-delay pipeline. The fulfillment team also has the most people to retain, train, and coordinate over what is typically a multi-state field operation problem.

Not at all easy. Still, it boils my blood seeing some of these organizations fall prey to these pressures and turn to customer exploitation. What it amounts to is some deep-rooted systemic issues with the government-enforced monopolies of our utility companies, overly-simplistic incentives, and a market moving faster than the training and organizational development.

It's really easy to use Erlang libraries in Elixir. It's nice to be able to tap into an ecosystem with Erlang's maturity while still using modern tooling like Elixir.

But what of the newbie developer? Is he/she going to just roll their own dependencies and do so in a way that's tenable? Green developers make up most of the category.

I guess I was trying to approach a few concerns beyond just dependencies: learning curve, conventions/standards, framework volatility, and merit assess-ability of ideas.

The more people involved (popularity), the greater the difficulty to parse the merit of an idea without pre-existing competence. How easy is it for a new developer to find a cogent way of doing things in Javascript land compared to a smaller more specific ecosystem? In the smaller ecosystem the experts are easier to determine due to a smaller population, whereas in Javascript-land there's so many people, opinions, articles, and conventional disparities; a much more challenging exercise.

The way I see it, our over-dependency (sorry for overloading the phrase) on Javascript as the de-facto web language has the pendulum far in one direction. How much longer can we keep this up? What's the maximum capacity of a developer ecosystem before dependency-hell and framework churn reaches critical mass? This is still a complicated information system - how far can it scale? What's the breaking point?

There's so much amateur work and muddied merit-sense-making of what's good software, who to listen to, and how to move forward - my feeling is that pendulum is just about at peak.

Elm will be amazing when it doesn't have to compile to Javascript.

I disagree a smart contract language is without value to business - but I agree it's speculative and unclear at the moment. The best we can do is look at cloud platform and programming language maturation/adoption to get a feel for what a decentralized app platform will take in time and engineering effort.

The idea being we're a few years at least before language and infrastructure can be mature enough to have value for most users beyond earliest of adopters. The other languages you've mentioned are much further along than any "dApp" platform at what they do. Decentralized application platforms like Ethereum are a new space with new requirements but, as far as I can tell, necessitate a new language to satisfy unique requirements. The hot-take is that Solidity is probably going to take some big changes to make it much further. I've not been impressed with it.

Tends to take 12 years for a programming language with traction to really take hold. Maybe 4-6 years for the language to reach maturity so long as it was well-designed and implemented; given early adopter feedback is present. Smart Contracts are best served with a well-typed, highly safe, and formally verifiable language feature set. You need confidence that the smart contract will operate without error once deployed. Implementation-wise I expect the ideal smart contract language will have a robust typing system with functional programming defaults where state is largely immutable and highly explicit. Probably some variation of an ML language.

That's the issue. How do you solve merit without an Orwellian system monitoring everything everyone does? Without some kind of capability for privacy-respecting decentralized systems - solving for Merit is a function of dystopia.

The Gig Economy hasn't even started yet. We've yet to solve Identity (Who is this?) and Merit (Is this person qualified/competent?). Hell, we've only barely started decentralized finance let alone scalable-decentralized-organizations. Uber/Lyft/Taskrabbit/Fiverr are low-hanging fruit compared to the complex workflows most services entail.

I expect we're going to see more niche gig-economy businesses being built around more complex workflows with higher skilled labor. Lots of B2B and B2C potential when you break up services into smaller tasks that can be fulfilled. Success is providing the benefits of scale without the challenge of doing it yourself.

Take something like Augmented Reality, there's a lot for the imagination to run with like reduced dependencies on physical location for high-fidelity communication (less text, more full-body expression). Or we could imagine dynamic tutorials: pop the hood in your car and see a live overlay of the parts and ways to replace them.

So we take this imagined future and think about how aspects might be implemented. What problems and barriers are in the way? If I'm interested in hardware maybe I could tinker with Lidar sensors and software to model physical spaces. If I'm interested in machine learning and statistics maybe focus on object detection. Maybe you're more about design and UI and can focus on the way people will want to interact with the digital overlay. Maybe you're into architecture and can spend time thinking about how to design physical spaces to integrate with the new augmented reality capabilities.

You're not going to solve every problem across those diverse domains, but you can still imagine the possibilities and find areas of interest that you're motivated to spend time in. I feel like this is what they mean by being 'upwind' of opportunity - you're not consuming paths set by others (downstream effects) but what has a likelihood of future value and possibilities.

I think my most valuable career choices have come from imagining what potential sci-fi futures could be. What sort of stories would be told given some technological problems solved in the coming years? Then I look for the problems that are interesting and engaging and invest time there. It's impossible for one person to build some utopian system that solves humanities problems, but designing and imagining such a system at least provides some insight as to where those future opportunities will be.

Agreed. The BEAM run-time and the preemptive scheduler implementation is designed to never block and keep chugging a long; highly desirable for the Actor model. The trade-off is you're further from the metal and raw-compute isn't as powerful as a JVM language like Scala. That said an Actor model on the JVM (Akka) can't make the same run-time guarantees using a cooperative scheduler; instead you get all the enterprise libraries and developer hours to tap into. So the trade-off of more complexity in Scala/Akka is probably worth it for big enterprise who are probably already in bed with the JVM.

I think we'll see more Akka features built in Elixir through things like Genstage and Flow, but it's hard to argue with the mountain of exiting developer man-hours in the JVM.

Between pattern matching and typespecs you get a lot of the "hey you're doing something wrong" checks at compile time to avoid errors. Definitely not a complete solution; a language like OCaml or F# will be better if you're concerned about type safety.

The dynamic typing in Elixir/Erlang is a trade-off for Actor model message passing. You get a state of the art run-time for fault tolerance and concurrency, but the messaging aspect makes typing problem-prone. A co-dependency on a custom type is coupling you want to avoid when sending messages around. You don't want a long running process that knows about Type_v1 sent a message from a newer process messaging with Type_v2.

The Aeternity team is building blockchain systems with Erlang for nodes and infrastructure. However since smart-contracts necessitate so much type safety and formal verification - they're designing an ML flavor functional language just for that.

I'd try building a small service or set of subscriber/workers to start. Messaging infrastructure and API clients are a good place to get a feel for the language. Ideally something that can benefit from the concurrency and stability. It really depends on the team though - it's a harder sell if there's high change potential on the code and maintainers would have to pick up a new language.

If your app is going to do anything real-time with lots of messaging or reactive / live behavior, then Elixir is going to hit it out of the park. There's a reason Discord and Whatsapp are using the BEAM.

Taken further we find the problem of bottlenecked economic throughput or market participation due to the poor's access to capital. Markets thrive on distributed inputs to arrive at a consensus on value - the more participants participating, the more throughput of information being supplied to our markets. More participants is more information which allows healthier markets which provides more opportunities for growth.

So what's the cost of a loan or other financial products? Of course there's utility in providing upfront capital in exchange for time-spread payments and interest (buy the $200 boots today), but what of the macro-cost of decreased market participation for the duration of the payments? The loan payments with interest is money that could've been used by an individual participating in the market that is instead piped to the financing provider who, by definition, is already richer.

Given the rich, or a rich organization, has different buying habits and participation in the markets (different perspective = different information), how much economic flow, throughput, and growth are we losing from financial mechanisms which go from poor -> rich? In this sense wealth concentration is a problem of bottle-necking economic potential by depriving our markets of participants and diverse perspectives.

Seems like Toyota Connected has similar projects in development - although maybe more focused for on-demand capabilities. Electric and self-driving capabilities aside - this sort of service subscription seems to have no major technological barriers; largely an operations + software problem. Seems like a good way to transition dealerships into service outlets towards larger scale fleet management.

What's stopping existing car companies from doing direct sales like Tesla? Removing barriers to customers giving you money is generally a win. How many Tesla's were purchased in the last year that wouldn't have been if the stressful dealership was in the way?

How about a subscription / lease deal where they ship you the new model every year? Sell a cheaper tier for the 2nd year used vehicles. Do telemetry on driver safety and charge accident-prone drivers more! Replace/bundle/improve car insurance while you're at it. Are there regulatory hurdles preventing this for a company like Ford or Toyota? Is it just organizational momentum stalling these changes?

Pattern matching would be nice in this scenario. Would help with isolating responsibility by breaking out the if statements into functions responsible only for the case they know to handle. The additional opportunities to name with more granularity could minimize the comments needed.

Be careful. Elixir is the gateway drug to OTP. There's no going back once you get that taste of sweet sweet Actor-model concurrency.

I wonder to what extent the data being fed to these models are the issue. Or rather the problem is the systems that generate these data-sets and how representative of reality they are. If we make an app that involves humans and that data is used in a model - to what extent does user experience and other factors warp reality?

Maybe our existing methods are good enough given enough compute to reach AGI but our datasets are too low fidelity and non-representative of the problem space to reach desired results?

What kind of crucial infrastructure and components are made of the same plastics consumed by said bacteria/fungi? If it was released to just consume plastic what kind of damage could it do? Can we engineer such a thing just for ocean plastics?

Bottleneck to PV is battery capacity. For Solar to meet peak demands and replace fossil fuels there has to be storage capacity and likely a fair bit of investment into grid infrastructure to meet volatile productions. Getting utility companies (a highly regulated monopoly in most cases) to do anything is a slow and painful endeavor.

The more time/location dependent energy sources we add to the grid, the more valuable and necessary on-demand energy to buffer with will be. Same goes for a steady producer like fusion/fission: an increasing value proposition as these renewables are added.

We should definitely be doubling down on PV, but stay aware of other options as it comes with trade offs.

When municipal fiber started moving into Utah, CenturyLink was a big offender of paying off local authorities to restrict and limit deployment. Lots of cities and areas didn't get upgraded for that reason. Less customers for fiber meant less customers to payback the investment - ends up costing everyone else more. CenturyLink is textbook rent-seeking behavior.

My advice to anyone moving into the Utah area is check the internet service provider options first. Last thing you want is to be in an area serviced only by CenturyLink.

Maybe a CRDT or Operational Transform?

Go is a language designed to take CS college graduates to productive engineers at Google with as little fuss as possible. Considering it was designed for an organization in the scope of Google, it's less likely to be the best option for something like a startup, small business, or even a medium size business.

The worst part of Elixir is when you're working with other languages and you know it'd be better in Elixir.