Interesting story. I am not entirely convinced that all credit should go to the programming language here, though.<p>My theory is that communicating abstractions is hard. If you work on your own, or in a (very) small team, you can come up with powerful abstractions that allow you to build amazing systems, quickly. However, sharing the underlying ideas and philosophy with new team members can be daunting. As systems grow, and mistakes are made, it becomes more and more likely that you run into serious problems.<p>This may also be why Java and similar object oriented programming languages are so successful for systems that have to be maintained for ages, by large teams of developers. There are but few abstractions and patterns, and it does not allow you to shoot yourself in the foot, nor to blow your whole leg off. Conversely, this may also be why complex frameworks, such as Spring, are not always so nice, because they introduce (too?) powerful abstractions, for example through annotations. It may also clarify why more powerful languages such as Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail to pick up steam.<p>Another theory is that not every developer is comfortable with abstract concepts, and that it simply takes a team of smart people to handle those.
Clojure is a lot of fun to tinker with, but man… I love my static types. I think I’d hate to work on a large codebase in Clojure and constantly be wondering what exactly “m” is.
Maybe this architecture approach would be challenging in Java or Go, but the style of immutable data, don’t go crazy wrapping stuff in classes is very doable in most languages. We enforce “no mutation of data you did not just instantiate” at Notion, and use TypeScript’s powerful type system with tagged union types to ensure exhaustive handling of new variants which I really miss in languages that don’t have it (go).<p>I guess the major advantage for Closure with this style is the “persisted” data structures end up sharing some bytes behind the scenes - it’s nice the language is explicitly situated around this style, rather than TypeScript’s chaotic Wild West kitchen sink design. What I don’t understand the advantage for “state management”. Like, you build a new state object, and then mutate some pointer from prevState to nextState… that’s what everyone else is doing too.<p>There are times though when it’s nice to switch gears from function-and-data to an OO approach when you need to maintain a lot of invariants, interior mutability has substantial performance advantages, or you really want to make sure callers are interpreting the data’s semantics correctly. So our style has ended up being “functional/immutable business logic and user data” w/ “zero inheritance OO for data structures”.<p>Whenever I read some open source TypeScript code that’s using the language like it’s Java like `class implements ISomething` ruining cmd-click go to method or an elaborate inheritance hierarchy it makes me sad.
I'm curious if Elixir could provide a similar development environment?<p>Seems like many similar capabilities, like a focus on immutable data structures, pure functions, being able to patch and update running systems without a restart, etc.
> Today, we're building Vade Studio with just three developers – myself and two developers who joined as interns when in college. (...) Here's what we've accomplished: (...)<p>In how many man-hours/days? It's hard to know if the list is long or short only knowing that calendar time should be multiplied by three for calculating people time spent...
@OP "Model our domain as a graph of attributes and relationships" and "generate resolvers". I'm curious what your model looks like so that you are able to "generate resolvers"? I had looked into using Malli as the model, but curious what route you took.
Is there a technical reason I can't sign into Studio with email? I'll really try to avoid signing in with other platforms, but I'll consider Github if there's some reason it has to be. I'll never sign into a service with Google.
<p><pre><code> Because Clojure treats data as first-class citizens, we could build our own lightweight conflict resolution system using pure functions that operate on these transactions.
</code></pre>
What does it mean to say Clojure "treat data a first-class citizen"? I understand FP would treat function as first-class citizen, but the statement seems to mean something different.
Uncle Bob approved this article!!<p>Incredible history, I feel like Clojure makes magic. What I like about functional programming is that it brings other perspectives of how things CAN work!!<p>Congratulations by the life change
I've built similar systems using Apache Airflow and Temporal, but the complexity was overwhelming. Using simple maps with enter/leave phases for workflow steps is much cleaner than dealing with DAG frameworks.
> Each new layer of complexity fed my developer ego.<p>I'm unable to understand this mindset. All the time I read things like "Developers love complexity because it feeds their egos" but I've never encountered a situation in which added complexity made me more proud of the work. Just the opposite: being able to <i>do more</i> made me more proud of the work I put in, and complexity was the <i>price</i> I paid for that ability. The greatest hacks, the ones that etch people's names into history, are the ones -- like Unix and the Doom engine -- that achieve phenomenal feats with very little code and/or extreme parsimony of design. This is no more true than in that famous ego-stroking/dick-measuring contest of programming, the demoscene. My favorite example being the 4k demo Omniscent: <a href="https://www.youtube.com/watch?v=G1Q9LtnnE4w" rel="nofollow">https://www.youtube.com/watch?v=G1Q9LtnnE4w</a><p>Being able to stand up a 100-node K8s cluster to provide a basic web service, connected to a React SPA front end to provide all the functionality of a Delphi program from the 90s doesn't stroke the ego of any programmer I know of; but it might stroke their manager's ego because it gives them an opportunity to empire-build and requisition a larger budget next year.
> When conflicts occur, our system can merge changes intelligently because we're working with pure data structures rather than complex objects. This would have been significantly more complex in an object-oriented language.<p>Not really, in an OO language state could have been stored in some data structure as well, with a way to serialize and deserialize. E.g. React made this very popular.
I can't find pricing on the same. Though it is no code, there must be a way for me to work with code directly if i wish to do so. No mobile apps. It would be great if you can generate both web apps and mobile apps.
Ultimately, it all comes down to build what you're comfortable with. Additionally, when you're managing large organizations and teams. Build with what you can hire quickly for and easily scale with.
Look these folks can do whatever the heck they want, use whatever language they want.<p>However my criteria for selecting a language for use in a <i>professional context</i>:<p>0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages<p>1: hiring and recruiting - there must be a mainstream sized talent pool - talent shortages are not acceptable - and I don't buy the argument that "smart people are attracted to non mainstream languages which is how we find smart people", it is simply not true that "most smart people program with Scala/Haskell/Elixir/whatever" - there's smart and smarter working on the mainstream languages.<p>2: size of programming community, size of knowledge base, size of open source community - don't end up with a code base stuck in an obscure corner of the Internet where few people know what is going on<p>3: AI - how well can AI program in this language? The size of the training set counts here - all the mainstream languages have had vast amounts of knowledge ingested and thus Claude can write decent code or at least has a shot at it. And in future this will likely get better again based on volume of training data. AI counts for a huge amount - if you are using a language that the AI knows little about then there's little productivity related benefits coming to your development team.<p>4: tools, IDE support, linters, compilers, build tools etc. It's a real obstacle to fire up your IDE and find that the IDE knows nothing about the language you are using, or that the language plugin was written by some guy who did it for the love and its not complete or professional or updated or something.<p>5: hiring and recruiting - it's the top priority and the bottom and every priority in between. If you can't find the people then you are in big trouble I have seen this play out over and over where the CTO's favorite non-mainstream language is used in a professional context and for years - maybe decades after the company suffers trying to find people. And decades after the CTO moved on to a new company and a new favorite language.<p>So what is a mainstream language? Arguable but personally it looks like Python, Java, JavaScript/TypeScript, C#, Golang. To a lesser extent Ruby only because Ruby developers have always been hard to find even though there is lots of community and knowledge and tools etc. Rust seems to have remained somewhat niche when its peer Golang has grown rapidly. Probably C and C++ depending on context. Maybe Kotlin? How cares what I think anyway its up to you. My main point is - in a professional context the language should be chosen to service the needs of the business. Be systematic and professional and don't bring your hobbies into it because the business needs come first.<p>And for home/hobbies/fun? Do whatever the heck you like.