Yeah, I also think it’s similar to how I work in general life, compartmentalizing things when they become too large.
You can use this particular mix task without needing to setup boundaries or add the boundary compiler. I.e. just add the lib as a dependency (I think even runtime: false is enough) and invoke the task on some module.
A powerful type system is a good thing to have but it’s even of lesser value than tests when it’s coming to proving the logical correctness of the software.
At the end of the day, only good software development practices can save it.
And it’s about working with your teammates on software as a team.
I see this trend of techies trying to solve socio-technical problems with more tech and I think about how pervasive that practice is.
To quote “When Coffee & Kale Compete”.
I feel that way especially with software because we have the analytics and the geeks who are building the software; they’re all about tracking and logging and all these data…I always give the analogy of being a retail shop owner and hiding in the back room and trying to learn from your customers by watching the closed-circuit television.
You could watch [customers] come in, walk around your store, pick up things, put them down, try things on…or you could just walk out and ask them, “Hey, what brought you in here today? What are you looking for? What other places did you try in the past?”
And I believe this is at least a part of the reason why people are migrating from Elixir to Go and then to Rust
There is some noticeable brain-drain occurring, especially towards Rust and WASM.
The hell one would prefer a language with rudimentary concurrency primitives for networking heavy-services? That’s really above my head.
I remember a conversation when crypto guys discussed that their node has a limit of 40 connections because async I/O in Rust sucks. They worked in a company that I hugely respect and which was valued above $500m.
Sure, the trade-off there is that Rust became the de-facto standard language for the new wave of crypto projects and it has all the cryptographic libraries which will be ridiculous to reimplement in Elixir (At least it was probably unfeasible before Nx).
But the point is that a team of developers working with a dynamic type system will deliver a better crafted piece of software that will serve their customers better than a group of individual developers working with a static type system.
TLDR: groups of individual contributors who don’t know how to write software together, as a team seeking shelter in their tools.
That doesn’t have to do anything with language.
disclosure: I do love Rust’s type system and it’s the next language that I want to learn because it will definitely expand my worldview.
But not as nearly as Elixir who added notion of time to my everyday practice.
This actually works for a lot of issues. The people who tend to write code negligently and without much care what gets passed to where don’t survive for long coding Rust, OCaml, Haskell, and the other compile-time typed languages.
Even outside that area, enforcing a simple pre-commit GIT hook – which is a tooling solution, not a programming language one – can do wonders for the productivity of the team.
I relate to the argument that not all social / economic / politic issues can be solved by tech. That’s true. But it’s a bit too extreme a view for my taste because my practice has shown that forcing people to “behave” with good tooling (or a strict programming language) works.
Strange example. I’d definitely leave the store and not return there anytime soon. There are acceptable and unacceptable ways of gathering metrics / analytics.
I’ve been in one such company last year. Rust’s async has been improving literally every week, for months. We ended up having one Kubernetes pod with 4 vCPUs and 8GB RAM with a NVMe SSD storage that peaked at about 150,000 parallel requests.
Rust’s async used to suck but the community is extremely dedicated and things are improving with an impressive speed.
I agree it’s not OTP, of course; nobody has beat that so far. But Rust is getting fairly close, trust me.
I’ve seen this but I’ve seen the other extreme as well. This can’t be generalized.
Agreed. Good devs find ways around the problems in their ecosystem and even make them work to their advantage. Example: we might not have compile-time typing guarantees in Elixir but between mocks and property tests you can gear your system with a very heavy anti-bug armor.
Bad devs will screw up no matter what they work with.
That one I fully agree with. Elixir is extremely productive. You can test your idea with just a few lines in iex and prototype a solution in minutes.
Rust’s iteration cycles are very punishing in terms of an up-front cost and this can be quite annoying.
The people who tend to write code negligently and without much care what gets passed to where don’t survive for long coding Rust, OCaml, Haskell, and the other compile-time typed languages.
I’m talking about empowering customers with new capabilities. That’s on the other level than codebase aesthetics and the absence of errors related to type conversion.
If someone doesn’t have the skills to adhere to the quality bar you do pair-programming, let them have time to learn and practice deliberately until a problem is solved.
They will either raise to the brighter part of the hill or will continue their journey where they don’t have to be under the light constantly.
But it’s a bit too extreme a view for my taste because my practice has shown that forcing people to “behave” with good tooling (or a strict programming language) works.
I stick to the theory that people want to become better at what they’re doing. And either developing software is not important for them or the company doesn’t give them a chance to unveil their potential.
But it’s a bit too extreme a view for my taste because my practice has shown that forcing people to “behave” with good tooling (or a strict programming language) works.
Practice can show only that something is not inherently wrong, not that something is completely right.
Rust’s async used to suck but the community is extremely dedicated and things are improving with an impressive speed.
That’s great to know!
This can’t be generalized.
I’m willing to bet my last penny on that. Give complicated enough domain space, decently sized company, and two-three years timeframe. Team will always win over a group of individual contributors.
That one I fully agree with. Elixir is extremely productive. You can test your idea with just a few lines in
iexand prototype a solution in minutes.
I meant long-lived processes that outlive individual I/O requests/response cycles. They add a dimension of time to the app.
Rust’s iteration cycles are very punishing in terms of an up-front cost and this can be quite annoying.
Not only Rust. Again, Rust is a great language. There is no intention to start a flame or language-politics discussion here.
Software is an implementation of a conceptual model and every day we learn more and more about it.
Compare yourself after one year in a project and after two years.
You are more knowledgeable and understand how abstractions should be structured much better than you did before.
But how many teams update their codebases to reflect their updates in their conceptual models?
Many of them prefer to go through hoops of mental-mapping while writing code.
And that’s what makes people neglectable to their professional duties and become disappointed in their software development careers.
Even worse - junior developers are being poisoned into thinking that it’s the only possible way to go.
And then you have to add tools to “force” people into doing things, instead of having them as just a safeguard against a silly mistake.