What editor did they use to write this code? I think this predated vi, and folks were probably using older tools they were familiar with. ed? How much of the source code could they see at once? Was there such thing as a "full screen editor"? If anyone can illuminate the development environment/workflow from the late 1970s I'd love to hear about it.
I don't know my history well enough to answer your question, but you can see one approach to the 1970s computing experience in this excellent video series about the Altair 8800 by deramp5113 on YouTube: https://www.youtube.com/playlist?list=PLB3mwSROoJ4KLWM8KwK0c...
Payitoff | Fullstack/Backend Engineers, Devops/Sysadmin | USA | FULLY REMOTE - US Timezones only
hi! We're Payitoff, and we're making a dent in Student Loans that affect 46,000,000 Americans. Our main products are an API and embeddable widget used by fintechs and larger institutions to power in-app student loan experiences. We also built our own infrastructure around loan aggregation and automating outcomes, including plan enrollment, certification, and payment processing.
We're looking for fullstack engineers and a network security specialist. The company is ~15 people, mostly engineering, and we're well-funded.
We're happy to teach you Elixir. Bonus points for fintech/payments experience. We have great benefits including half-day Fridays, extensive time off, family-oriented culture, health/401k/529/student loan contributions, and a professional development budget. Women, minorities, and other underrepresented groups are especially welcome.
Please email desmond [at] payitoff.io if interested. Thanks :)
hi! We're Payitoff, and we help borrowers pay off their student loans. Not through refinancing (though that's one option) but by doing the hard work of understanding and codifying federal repayment programs and awards to give borrowers the best possible guidance on their journey. Our main products are an API and embeddable widget used by fintechs and larger institutions to power in-app student loan experiences. We also built our own infrastructure around loan aggregation and automating outcomes, including plan enrollment, certification, and payment processing.
We're looking for frontend and backend engineers, a devops/sysadmin to help with compliance, and one product manager to accelerate our team ahead of payments resuming in February. The company is ~10 people, mostly engineering, and we're well-funded.
We're happy to teach you Elixir. Bonus points for fintech/payments experience. We have great benefits including half-day Fridays, extensive time off, family-oriented culture, health/401k/529/student loan contributions, and a professional development budget. Women, minorities, and other underrepresented groups are especially welcome.
Please email desmond [at] payitoff.io if interested. Thanks :)
It sounds like you're recruiting from a pool of junior developers and convincing them to use Elixir instead of attracting folks who are already interested in the language. Not only is that community sizable, but it's experienced- surveys of attendees at my conference (https://empex.co) consistently show that 50% have >5 years and 30% have >10 years in the industry.
Elixirists really are senior developers and Elixir is usually their fourth or fifth language. If it's taking your hires years to get up to speed, then I would look at your hiring practices before blaming the community.
As for libraries, I challenge anyone to name an unmet dependency in Elixir that is 1) trivial to implement and 2) not for some niche application.
My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits.
I'm pretty sure I can find more than one package I'll miss.
> My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits.
Hosting costs are a lot cheaper for us than developer's time. Downtime has never been an issue given "cloud" (docker based) infrastructure. The productivity part is something we're not seeing to be any better than with more traditional technology, and the reason we're moving away.
I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.
Ironically, Europe has a higher concentration of Elixirists given Erlang was invented there. My hiring attitude is that paying for senior developers is cheaper in the long run given their ability to make better decisions.
> I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.
Emphatically no. Having more servers costs more than just hosting, there's maintenance, orchestration, and communications complexity.
While other package ecosystems certainly have _more_ packages, the question is: how many of those will you actually use?
> While other package ecosystems certainly have _more_ packages, the question is: how many of those will you actually use?
Exactly. Saying NPM has millions of packages is completely misleading. There will be 20, 30, 40 packages that all do the same thing.
Elixir is also a very stable language with no current plans for a 2.0 release. This means that while a lot of Hex packages may not have been updated in a while, they are still rock solid. I agree that this is a very hard thing to get used to since the first thing I always do is looked at the last commit date and then the number of stars. While this is still useful, it doesn't hold the same weight it does in other ecosystems. Personally, I think this is how it should be.
I won't say that the Elixir ecosystem is perfect, though. There has been trouble with maintainers leaving projects, but to knowledge someone always steps up.
> Exactly. Saying NPM has millions of packages is completely misleading. There will be 20, 30, 40 packages that all do the same thing.
And the one with the obvious name hasn't been updated in 18 months. Maybe it's complete. Maybe the developer has moved on. Then there are a couple half hearted forks. All of these dependencies bring in 1 to 100 dependencies each and you have to spend a days on the treadmill every month or two to keep things updated.
I loved Node development despite the packaging mess but I really appreciate how the Elixir community tends to coalesce around key libraries/frameworks/methodologies and focus on making them the best possible.
Is that a Node specific problem though? I have elixir packages up on Hex that I haven't maintained or looked at in years. In fact, I'm pretty sure they are buggy but since no one is using them I'm not worried about it.
There are packages on Hex that haven't been updated in a long time but still work perfectly (Canada, for example: https://github.com/jarednorman/canada). Elixir itself doesn't change much... in fact there's no plans for a 2.0 on the horizon, so the fact that packages don't change often isn't a big deal if they still do what they say they do and aren't hurting for more features.
Ooo, I'd also mention that there often isn't a need for a lib. For example, as outlined in The Little Ecto Cookbook, it's trivial to build a small fixtures framework—the API is two one-liner functions! Sure, it's missing a few things, but I've been using it on my own project and have not missed anything provided by dedicated fixtures lib.
> As for libraries, I challenge anyone to name an unmet dependency in Elixir that is 1) trivial to implement and 2) not for some niche application.
For quite some time the ex_aws[0] package was no longer maintained because the only person who maintained it stopped using AWS. There were many months in between before a new maintainer was found. Unlike Python, Ruby, PHP, Node, Go, etc. there's no official AWS SDK for Elixir.
The ecto pagination[1] package has a "low maintenance" warning, basically the author is no longer maintaining it except for fixing issues even though there's a number of interesting features that could be added that other web frameworks have available.
The arc file upload[2] package was no longer maintained or touched for a really long time until someone took it over but now that new package is also racking up open issues and looks like it kind of stagnated in development. This isn't based on looking at last commit times too. I mean there's issues open to address important topics that haven't gotten reviewed for a long time.
There's also no official Stripe SDK for Elixir and all of the community created ones feel kind of abandoned or no where near feature parity with Python, Ruby, Node, PHP, Golang or any of the other official packages offered by Stripe. This is the last thing I want to have to implement myself since it's so critically important. The same can be said for PayPal and Braintree integration. There's official SDKs for Python, Node, etc. but not Elixir. I've asked Stripe a couple of times about an Elixir client and they all say the demand is not near enough to consider creating one officially.
These are only a few examples of tools I've found in questionable state when working with Elixir compared to Python and Ruby. All of which are very important in a ton of applications.
Then there's also less generic but still really useful things like notification abstractions to send emails, texts or broadcast notifications to connected clients. Rails, Laravel and Django all have excellent solutions to this where you can get up and running in no time but with Phoenix you'll have to write all of this on your own. It's a huge undertaking.
Long story short, I started with Phoenix and Elixir almost 2 years ago and today 2 years later I feel like if you plan to write any type of business'y app with Phoenix you're going to have to end up writing a ton of libraries yourself instead of focusing on your business problem. That might not be a problem if you have a huge team and your business idea is already proven and 5+ years old but for anyone who wants to build something and see if it works, it's hard to say you'll be able to build something faster than Rails, Laravel, Django or Flask if you already know one of those frameworks.
Now you might say some of those packages are trivial to write but they're really not. That seems to be a common pattern I've seen with the Elixir community where someone will say just do it yourself because it's easy and then you're left hanging. Sure maybe it's easy if you're Jose or someone with 5+ years of prior Elixir experience and have written 100k+ lines of Elixir code but a regular developer who just wants to build web apps (not libraries) is going run into tons of roadblocks. I know I did.
Payitoff | New York, Los Angeles | Software Engineer | Full-time, Remote/Onsite, USA | https://payitoff.io
Payitoff is a Student Loan API that crunches government regulations to save borrowers tens of thousands of dollars on their student loans. We're not a refinancing company. We do the hard work of simplifying the complex world of student loans so borrowers have an ally along their journey to pay it off. Our customers are fintechs, financial advisors, and banks who consume our insights and leverage our infrastructure to provide student loan tools to their users.
We're a small (<10) engineering-focused company (the CEO wrote the MVP in Elixir) and we'd like to stay that way. We're fully remote across the US, but if you're in New York or LA you're welcome to share an office! If you're looking for a chance to dig into a dense domain that makes a huge impact on ordinary people please get in touch.
Our tech stack: Elixir, Postgres.
We're looking for experienced Software Engineers (5+ YOE), preferably with Elixir/Erlang experience who have been impacted by Student Loans (either you, a friend, or loved one). Fintech experience preferred, but not necessary. Also open to the right Product Manager, but as we're an API-driven company this isn't a fit for some.
If interested please contact me directly: desmond [at] payitoff.io
I've been using Elixir professionally for the last ~5 years on over a dozen projects.
I was originally drawn to it because of its superior support for websockets. It can trivially handle shitzillions* of simultaneous connections and thus make fully realtime, dynamic web applications within reach of small teams of developers. Other languages _can_ do this, but with much more complexity and cost to host and develop.
Currently I'm working on a fintech API that doesn't use websockets :). Elixir is a great choice because its syntax is the perfect balance of being expressive but not dense. I find that describing a solution in my head translates almost perfectly to a series of functions. It's my go-to language for any task outside of scripting.
I'd compare the experience of using Elixir to drinking a glass of lemonade on a warm summer day. Everything seems to happen very easily.
I'm an experienced consultant who brings product ideas to life, trains up teams on engineering processes and skills, and builds cultures of fun, respect, and empathy. I've led large teams and small ones; my specialties are listening and helping.
My primary language is Elixir - I founded the EMPEX conferences and cohost the ElixirTalk podcast. If you're thinking of getting the next big realtime platform off the ground, let's talk.
Other languages: Ruby, Javascript, Objective-C, Swift, Clojure, C
Datastores: Postgres, Redis, Elasticsearch, MySQL, MongoDB (Please don't ask me to use mongo)
Other tech I've used in production: AWS, nginx, various Linuxy stuff, Rails, React, React Native
Yeah exactly. I've sat in so many engineering rooms with graphs that, while colorful, end up obscuring the human users behind them. Pulse isn't trying to replace New Relic, Datadog, etc but complement them.
