[HN Gopher] Doing Hard Things While Living Life: Why We Built Va...
___________________________________________________________________
Doing Hard Things While Living Life: Why We Built Vade Studio in
Clojure
Author : puredanger
Score : 85 points
Date : 2025-01-07 13:52 UTC (3 days ago)
(HTM) web link (bytes.vadelabs.com)
(TXT) w3m dump (bytes.vadelabs.com)
| Nijikokun wrote:
| 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.
| mkreis wrote:
| Quick (and cheap?) hires are not necessarily good hires. In my
| experience (and my theory) developer productivity can range
| from 0.5x to 5x and more, and those developers in the upper
| range tend to look for certain programming language which they
| enjoy, like Rust, Go, Elixir, Scala and Clojure. They are hard
| to get if you are on a "boring" stack like Java, NodeJS, PHP.
| So if you might need to invest some time and money to find the
| right people, but at the end you make a better deal: Even if
| the salary is twice as much, the productiviy is even more.
| Additionally less people means less communication overhead,
| which is another advante.
| deeviant wrote:
| I find the opposite to be true, that best and most productive
| developers tend to be more language agnostic than average,
| although I'm not saying they don't have their preferences.
|
| Specifically, I find language evangelists particularly likely
| to be closer to .5x than 5x. And that's before you even
| account for their tendency to push for rewriting stuff that
| already works, because "<insert language du jour here> is the
| future, it's going to be great and bug free," often instead
| of solving the highest impact problems.
| ilkhan4 wrote:
| Yeah, this has been my experience too. The mentality seems
| similar to "productivity hackers" who spend more time
| figuring out the quickest, most optimal way to do a thing
| than people who just do the thing.
| dionian wrote:
| I agree with you but also agree with the above, if youre
| stuck permanently in some tangled codebase with a boring
| language/style, the really good programmers tend to find
| something more fun to work on - unless they can bring their
| new skills/experience to bear. personally I'll only go back
| to doing boring stuff if i can't find a job doing the fun
| stuff
| switchbak wrote:
| Oddly, I think both are true, at the same time.
|
| I've worked with language zealots and it's awful.
| Especially the ones with the hardcore purely functional
| obsession. But that can apply to almost anything: folks
| that refuse to use anything but $TECH (K8S, FreeBSD, etc).
| Zealots like this general care less about delivering and
| more about what they get to play with.
|
| Then you have the folks that care about delivering. They're
| not language agnostic, they have strong opinions. But also:
| they communicate and collaborate, they actually CARE: they
| have real empathy for their users and their co-workers,
| they're pragmatic. Some of these folks have a lot of
| experience in pushing hard to make things work, and they've
| learned some valuable lessons in what (not) to do again.
| Sometimes that can manifest as preferences for languages /
| frameworks / etc.
|
| It's a messy industry, and it can be extremely hard to
| separate the wheat from the chaff. But a small team with a
| few of those can do truly game changing work. And there's
| many local optima to be had. Get a highly motivated and
| gelled team using any of: Elixr / Typescript / Zig / Rust /
| Ada / Ocaml / Scala / Python / etc, and you'll see magic.
| Yes, you don't need fancy tech to achieve that. There's
| more than a few of those writing C for example, but you're
| unlikely to see these folks writing COBOL.
| Nijikokun wrote:
| I'm not in the business of cheap. I do care about resource
| availability though.
| joeevans1000 wrote:
| In my case, it was definitely worth becoming uncomfortable for
| a bit to learn Clojure because I was very uncomfortable with
| the experience of many of the other languages. It's also great
| to have endless backwards compatibility and little reliance on
| changing external libraries baked in.
| Nijikokun wrote:
| Never opposed to sacrificing some comfort for learning.
| joeevans1000 wrote:
| And for superpowers. :-)
| j45 wrote:
| This. And End users rarely care what the solution is coded in
| if it's a tool they use and don't modify or script at the code
| level.
| smw wrote:
| Anyone else unable to login with github to studio?
| noshitsherlock wrote:
| Yes, I was unable; just bumped me back to the login
| atarian wrote:
| same just redirects me to login every time
| garyrob wrote:
| Same here
| jolt42 wrote:
| @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.
| knubie wrote:
| I think these words will make more sense in the context of
| Pathom.
|
| https://pathom3.wsscode.com/
| jimbokun wrote:
| I'm curious if Elixir could provide a similar development
| environment?
|
| 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.
| smokel wrote:
| Interesting story. I am not entirely convinced that all credit
| should go to the programming language here, though.
|
| 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.
|
| 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.
|
| 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.
| j45 wrote:
| Clojure has some interesting advantages - which doesn't mean
| others might not.
|
| Rapid application technologies, methedologies, or frameworks
| are not unusual.
|
| I know some wonderfully productive polyglot developers who by
| their own choice end up at Clojure. It doesn't have to be for
| everyone.
|
| I wouldn't rule out that Clojure doesn't deserve credit. I
| wouldn't think it's a good idea to discredit Clojure from not
| having tried it myself.
|
| I do hope someone with extensive Clojure experience can weigh
| in on the advantages.
|
| How easy something is a codebase grows is something to really
| consider.
|
| This product regardless of how it's built is pretty impressive.
| I'd be open to learning advantages and comparisons without
| denying it.
| skydhash wrote:
| Another theory is that C inspired languages are very
| mechanistic and easier to visualize. Same goes for OOP with the
| Animal->{Cat,Dog} explanation. But that's just surface level
| and once you get to the difficult part (memory management in C
| and software design in Java) where the ability to grasp
| abstractions is required, we're back to square one.
|
| I believe once you've got to another point, dealing with
| abstractions is a way of life. It's either in the language, the
| technical requirements, or the software design.
| bsder wrote:
| > It may also clarify why more powerful languages such as
| Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail
| to pick up steam.
|
| Languages need a window of opportunity, and many of those
| squandered it.
|
| Clojure won over Scala because at the time when people were
| loooking for an alternative JVM langauge, Clojure was more of a
| departure from Java and seemed to have better tooling (compile
| times and syntax support) than Scala.
|
| Smalltalk and Common Lisp wasted their moment by not being
| cheap/free to people using micros in the 1980s.
|
| Lisp, especially, _very much_ wasted its moment with micros.
| The fact that no Lisper had the vision to dump a Lisp onto the
| bank switched micros (which makes GC really easy and useful) of
| the mid to late 1980s is a self-inflicted bullet wound. Lots of
| us _hated_ doing assembly language programming but had no real
| alternative. This was a loss born of pure arrogance of Lispers
| who looked down on those micros as not being "real machines".
|
| I weep for all the hours I wasted doing assembly language as a
| teenager that I could have been writing Lisp. How much software
| could have been written that would have been <100 lines of Lisp
| if only someone had written that tool?
| joeevans1000 wrote:
| 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.
| j45 wrote:
| Agreed. If a google account goes away, so does the access to
| all your google authenticated stuff.
|
| I only use google for email logins for services I don't take
| seriously and am willing to lose.
| justinl33 wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-10 23:00 UTC)