54 ms·

This feels like the same pattern as Dark leaving OCaml for F#: https://blog.darklang.com/leaving-ocaml// https://blog.darklang.com/leaving-ocaml//. Ecosystem ma

by Zababa 5y ago

This feels like the same pattern as Dark leaving OCaml for F#: https://blog.darklang.com/leaving-ocaml// https://blog.darklang.com/leaving-ocaml//. Ecosystem matters a lot these days. Outside of these two specific cases, I wonder if we're, as an industry, too afraid of writing this kind of stuff now I feel like it was done a lot before, and not at all these days. Sure, NIH syndrome is a fallacy, but having to write one library may not be so bad. I would be glad to hear about any experience with that.

wyager 5y ago
I used to work at an OCaml company and it wasn't nearly as much of an issue as one might predict. You can (it turns out) build a very successful business even if there aren't a lot of existing libraries, or if the language lacks certain basic features like native multithreading (same with Python of course). I don't have a great model for why this isn't devastatingly expensive, but it's probably some combination of * Most existing libraries are kind of bad anyway so you're not missing out much by not using them * If you write everything yourself you get system expertise "for free", and gaining expertise in something that already exists is hard * You can tailor everything to your business requirements * Writing libraries is "fun work" so it's easier to be productive while doing it
- Zababa 5y ago
  That's interesting, thanks for sharing your experience. Sometimes I wonder how much interesting experience I miss by mostly using things people already built. Sure, if you're just trying to get something done it's probably faster, but on the other hand spending more time gives you experience.
- pbiggar 5y ago
  I don't agree with this at all. While it's true that there are lots of bad libraries and many libraries are easy, you really isolate yourself from the broader ecosystem by doing this. Vendors and 3rd party solutions are now much harder to use, and when you use them you'll probably only use them at a surface level instead of using all the features. And some things are so mature and vast you don't have a chance of building them yourself. If what you are doing can be done well in very mature ecosystems like React or PyTorch, the effort to recreate them will dwarf the time spend on important work.
  - jokethrowaway 5y ago
    I know plenty of companies not using third parties for security or ideological reasons. Code is code: both models (3rd party vs no 3rd party) can work and the time spent reinventing the wheel is not necessarily business breaking.
  - Zababa 5y ago
    > If what you are doing can be done well in very mature ecosystems like React or PyTorch, the effort to recreate them will dwarf the time spend on important work. Sometimes that's effort that's not really necessary. At work we had a team build a dashboard with React and a few graphs recently. It clocks at 2000 unique dependencies. That's not a typo, it's two thousands dependencies for a few graphs. Reimplementing all of that would take many man-years of work, but I think it wouldn't be necessary in the first place. Chart.js doesn't use any runtime dependencies, and could probably fill most of our needs. Chart.js is 50k of Javascript, which is a lot but probably more than we need. I don't know how much time it would take to make a reimplementation to have the API we need, but I think it's doable. Why would we want to do that? Because those 2000 dependencies are a liability. Last time I checked 165 were looking for funding. It would be easy to imagine a malicious actor paying a few people to contribute to low profile but widely used JS libraries, and take over the maintenance when the original maintainer becomes tired. I don't know if this is a worse liability than developing our own chart library. I don't know much about security and the tradeoff involved. All of that to say, isolation from the broader ecosystem may be a good thing.
    - ithrow 5y ago
      I guess you mean 2000 dev dependencies because for production that would be crazy.
      - Zababa 5y ago
        I'll have to check but at least half of those are for production.
- brundolf 5y ago
  It would probably depend a lot on what you're building Though I think the "fun work" point is really interesting and worth a broader discussion
- ch4s3 5y ago
  The "for free" is doing a lot of work there! :) I've been there, and you do develop the valuable human capital, but it costs time and salary. That said, you're right it is fun, and people like doing it so its good to keep your work mixed up and you team motivated. It's a good lever to pull IMHO, but not always.
  - nine_k 5y ago
    Yes, it's not free in the sense that this is paid developer time, and also a delay before actual production deployment. As long as learning the basics of a 3rd-party library takes a relatively short time, those who use it have an advantage: they ship faster. Certainly mastering it may take as long as writing one's own. But you can do that while writing more production code and shipping features. Also, you get improvements made by other people for free (because likely you're using an OSS library anyway).
- hardwaregeek 5y ago
  I think Jane Street is a big exception. It's like when PG espouses lisp. Back in the 90's[1] language ecosystems were very sparse. An ecosystem was a few big libraries and a syntax highlighter. Now stuff like IDEs, linting, packages, etc. have made people's standards quite high for ecosystems. On the flip side, back in the day languages like OCaml and Lisp had stuff other languages could only dream about. Functions as arguments! Macros! Type inference! But now, barring macros, these features are all in mainstream languages. If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE. Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde. Which is why a lot of people are moving to Rust I suppose. You still get the hip factor but responsibly. It's the Foo Fighters of languages. Cool, but not irresponsible. [1]: I was in a very famous tv show: https://www.youtube.com/watch?v=FBw-Z8ULwcc https://www.youtube.com/watch?v=FBw-Z8ULwcc
  - Zababa 5y ago
    The big difference between Rust and OCaml is that a company the size of Jane Street can influence OCaml development, while it takes one the size of Amazon (according to the recent accusations) to do the same with Rust. I think OCaml has one of those "ancient" communities that seem to value independence more than consensus. Rust is very hard to build without cargo, OCaml works fine with make or dune. I'm not sure if focusing on independence is the right tradeoff for most companies, but I can see some cases where it might be. > If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE. IDE support is getting there with OCaml. In VSCode, it's not as good as TypeScript but it's usable. > Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde. There are a few libraries that you can use. Serde also tends to make the already long compilation time blow up.
  - wyager 5y ago
- chillfox 5y ago
  Multi-threading can often be handed off to the OS in the form of just run more processes. So in most cases there is really no need for the language to handle it.
  - wyager 5y ago
    There isn't really a need for anything, which is kind of the point. You can use a random language that's missing a ton of functionality and you can probably make it work.
  - throw868788 5y ago
    Its still nice to have shared memory especially in a functional language where due to lots more immutability it isn't as big of a price (i.e. more concurrency safe). Especially if your sharing in-memory caches and the like. I've seen this save tons of dollars in cloud setups (100,000's) in my career in more than one place. Safe multi-threading was marketed as part of the advantage of functional programming to many people; which IMO why I find it strange that OcAML didn't have it for so long. Lightweight threads (e.g. Tasks, Channels, etc) use less system resources than processes as well. You can do anything with anything but you usually pay some price of inefficiency to do so. That may be small, but sometimes it is large enough to matter.
    - scns 5y ago
      It took so long because they wanted to ensure the performance OCaml is known for.
      - throw868788 5y ago
        Agreed; especially since it didn't have it originally. I'm sure some compromises were made to do it in a way that fits into the execution model/doesn't cause regressions to older code. They are both good languages for sure which makes sense because one is derived from the other. F# through itself and .NET has had the equivalent functionality for many years however (Threads, Tasks, Async's, Channel libraries, etc) being the one of the first languages (before C#) to have an Async construct. I would imagine it would take some time I think for OcAML's ecosystem to catch up API wise with this where it matters for application development. Looking at OcAML's recent release notes I see work to slowly migrate multicore into OcAML but the feature itself hasn't landed yet? Think it comes in 5.0. I have to say though F# performance is quite good too those days from working/dabbling with both languages + the ecosystem is bigger. I would like to see/understand where the OcAML perf advantage is there is any for evaluation. The CLR has really good performance these days; its has features to optimise some things (e.g. value types make a big difference to some data structures, hot loops vs the JVM) from my experience especially if you don't allow Unsafe code for many algo's/data structures. For example I just looked at the benchmarks game (I know has its problems including bad contributed implementations for niche ecosystems) but it shows .NET Core (and therefore F#) performance is within the same scale as OcAML at times beating it (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...).
- mbrodersen 5y ago
  My experience as well. I worked in industries (Games development) where no open-source or proprietary solutions existed for what we needed. So we built it ourselves. It wasn’t that hard and we never had problems with it because it did 100% exactly what we needed and nothing else. If any new feature was needed we simply added it. I would routinely get an ask from a programmer, artist, musician or game designer and would have it implemented and a new version ready for them within a day or two. The productivity gains were immense.
pbiggar 5y ago
That was my thought (I wrote the Dark post). It also makes me think of CircleCI where they stayed in Clojure for quite some time - it really didn't have that much need for libraries (and the ones it did need, such as AWS, were provided by Java). When evaluating whether to use a non-mainstream language, the rule I use now is: - will I need to interact significantly with the outside world in a way that can only be done with libraries? - if not, do I gain a lot with this non-mainstream language? That contrasts against how I used to do it, where I viewed it as a trade-off between the ecosystem and the advantage of the non-mainstream language.
- Zababa 5y ago
  Thank you for the posts, the follow up posts and your perspective.
pjmlp 5y ago
That is why when comparing languages we should always look beyond grammar and semantics. This is nothing new, it is also a reason why languages like C and C++ won the systems programming wars from the 1990's. After a while one gets tired to write wrapper libraries, or having to pay extra for an additional compiler that isn't part of the platform SDKs. Hence why successful languages always need some kind of killer feature, or a company with deep enough pockets willing to push it into the mainstream no matter what. Same applies to new OS architecture ideas as well.
- davidw 5y ago
  I wrote about the economics of programming languages a while back: https://www.welton.it/articles/programming_language_economics.html https://www.welton.it/articles/programming_language_economic...
  - pjmlp 5y ago
    Thanks for sharing, spot on. I like the Tcl example, that is how we worked at a .com startup I was part of.
- int_19h 5y ago
  It's also why C++ won - for the most part, you could just reuse C libraries as is by including the header inside an extern "C" block. These days, Zig seems to be explicitly trying to do the same thing, but without paying the backwards compatibility tax: https://ziglang.org/documentation/master/#Import-from-C-Header-File https://ziglang.org/documentation/master/#Import-from-C-Head...
  - dleslie 5y ago
    Nim does it better, it can be used anywhere C can; zig cannot.
    - Zababa 5y ago
      As I've said somewhere else, don't think in terms of languages but in terms of use cases. Nim can make a lot of sense for some cases where C is used, and not much for others. The same is true for Zig. There is no and there will never be a "C replacement", just other options depending on what you are doing.
crdrost 5y ago
Kind of, but like OCaml-to-F# is like "Dark goes from the Prius of languages nobody uses, to the Tesla of the .NET ecosystem." The aims (ecological in the car case) of the purchaser are similar, but the car [at least in its ecosystem] is sleeker and now the roads are a bit different. On the other hand this is like "Wallaroo moves from the Cadillac of languages nobody uses, to the Chevy Equinox of languages nobody uses." Like, totally fine, you grew older and had kids and needed an SUV to keep up with home life, no shame in that... but there is a wistful "ah when we were young" to the transition, no?
- Zababa 5y ago
  I don't know anything about cars and don't understand your metaphor at all, sorry.
  - _dwt 5y ago
    I know a little about cars and I'm still confused - I think I just have a very different view of the relative "it factors" between each pair of languages. De gustibus...
    - crdrost 5y ago
      Yeah I mean that's fair too. My impressions are poorly formed but the analogy is that both F# and OCaml are based on functional programming, which to my mind takes a step back from the "imperative programming -> OOP -> shared state multithreading" history into an alternative history, I'm phrasing this as them being "electric cars" for the first half. OCaml is not really the swankiest of swank in the alt-languages community, so I chose a Prius to be like "what's a car that folks know as eco-friendly but it's not very prestigious?" ... meanwhile F# is like "we are THE functional programming of the .NET world, come over here we're cool and slick and all-electric" hence the Tesla comparison. Pony is like the far-off "ah maybe someday I'll be able to use that at work, maybe for some little experiment" thing and it reminded me of going to a dealer and being like "let me drive the Caddy, you know I'm not gonna buy it, I know I'm not gonna buy it, but I just wanted to live a little today." I don't have any particular experience with Chevy SUVs so I just chose one at random, the point was that Rust is like a "look we're just trying to be C with explicit contracts between parts that allow for memory safety" type of language, very practical and chunky and like people love it don't get me wrong... just, it's an SUV. It's less opinionated and more just "let's get from point A to point B safely."
travisgriggs 5y ago
How depressing. Probably true. But depressing nevertheless. Bigger frameworks, more complicated libraries, deeper multi tiered tooling, all of these things that we call ecosystem, reduce access to general purpose programming and creativity. We've created a bureaucracy of execution so complicated that we need vast amounts of funding to keep us at the tiller doing the biddings of e-commerce apps. It's like the founding fathers of programming have been reborn as Sir Humphreys.
- Zababa 5y ago
  If you're doing things on servers that you manage yourself and not using lots of saas, you can probably still do things in an obscure programming language.
- Karrot_Kream 5y ago
  This is how it is in every applied field. It's not as if 2x4s fall from trees and we use them in our construction. The 2x4 is a specific manufacturing output that's used as inputs for lots and lots of other things. It's the same way when it comes to software. Just like when doing cabinetry nothing is stopping you from processing wood yourself, likewise nothing is stopping you from rolling your own frameworks. But then you'll find you're closer to selling a Morton Chair [1] than regular furniture. (And FWIW that might be fine for your problem domain, especially if you're in the market of beautiful, high-value, handmade chairs with long lead times.) [1]: https://www.mortonfurniture.com/ https://www.mortonfurniture.com/
  - travisgriggs 5y ago
    Where this fails for me is that the 2x4 is a standard. And it's simple. And it's universally acceptable. I can send my wife and my kids alike to buy one from who knows where with little to zero instruction. They can work with it with ease. The "ecosystem" fades into the background. But modern software ecosystems are the exact opposite. You spend more time trying to learn/master/navigate the ecosystem than you do working with the metaphorical 2x4. To make matters worse, getting a 2x4 has been temporally stable for a long time. Not much has changed since my grandfather could send me to the store to buy a 2x4 on my own. But software ecosystems evolve and migrate weekly. Your argument demonstrates that all developed fields create ecosystems. But it does not address the issue that not all ecosystems are equal. Some are good. Some are bad. It's my opinion that modern software ecosystems look more like the British Civil Service than the ecosystem that produces 2x4s.
lmm 5y ago
It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byzantine tower of confusion goes into making an IDE I started to have a bit more sympathy for that kind of decision.
- d3nj4l 5y ago
  Why can’t you just use IntelliJ CE? You won’t get some of the web programming features, but otherwise it’s perfectly capable.
  - vips7L 5y ago
    There’s also the Scala Metals language server and bloop. Plenty of options outside of eclipse.
  - lmm 5y ago
    > Why can’t you just use IntelliJ CE? It's never had working error highlighting for Scala. I filed a bug where using a parameterized member type was incorrectly highlighted as an error, the next version using a parameterized member types was never highlighted as an error. I filed a bug with a case that should have been an error wasn't, the next version my original bug was back. I gave up at that point.
- pkulak 5y ago
  Kotlin is strictly worse if you value language features above all else. In that, there are several (several!) features it doesn't have.
  - kaba0 5y ago
    I’m not one who values languages based on number of features alone (otherwise C++ or C# would be my all go), but based on the synergy of them. I think in this case, Scala is a really elegant language with many features that all come from some simple to understand primitives, for example everything is an object, that creates a highly coherent language. This is in contrast with Kotlin, that tries to gain popularity by including many features, but always feeling “just sugar syntax over Java” to me.
Rapzid 5y ago
Heh, that's a good reference I hadn't read before. I feel like maybe Clojure and OCaml were strike one and two followed by a home run with the F# and dotnet call. Prob feeling real smug right now with aot, wasm, and hot reload being first class citizens haha.
blondin 5y ago
> Ecosystem matters a lot these days. and having a big ecosystem doesn't mean it's a good or a healthy one either.

by Zababa 5y ago

wyager 5y ago

I used to work at an OCaml company and it wasn't nearly as much of an issue as one might predict. You can (it turns out) build a very successful business even if there aren't a lot of existing libraries, or if the language lacks certain basic features like native multithreading (same with Python of course). I don't have a great model for why this isn't devastatingly expensive, but it's probably some combination of * Most existing libraries are kind of bad anyway so you're not missing out much by not using them * If you write everything yourself you get system expertise "for free", and gaining expertise in something that already exists is hard * You can tailor everything to your business requirements * Writing libraries is "fun work" so it's easier to be productive while doing it

Zababa 5y ago
That's interesting, thanks for sharing your experience. Sometimes I wonder how much interesting experience I miss by mostly using things people already built. Sure, if you're just trying to get something done it's probably faster, but on the other hand spending more time gives you experience.
pbiggar 5y ago
I don't agree with this at all. While it's true that there are lots of bad libraries and many libraries are easy, you really isolate yourself from the broader ecosystem by doing this. Vendors and 3rd party solutions are now much harder to use, and when you use them you'll probably only use them at a surface level instead of using all the features. And some things are so mature and vast you don't have a chance of building them yourself. If what you are doing can be done well in very mature ecosystems like React or PyTorch, the effort to recreate them will dwarf the time spend on important work.
- jokethrowaway 5y ago
  I know plenty of companies not using third parties for security or ideological reasons. Code is code: both models (3rd party vs no 3rd party) can work and the time spent reinventing the wheel is not necessarily business breaking.
- Zababa 5y ago
  > If what you are doing can be done well in very mature ecosystems like React or PyTorch, the effort to recreate them will dwarf the time spend on important work. Sometimes that's effort that's not really necessary. At work we had a team build a dashboard with React and a few graphs recently. It clocks at 2000 unique dependencies. That's not a typo, it's two thousands dependencies for a few graphs. Reimplementing all of that would take many man-years of work, but I think it wouldn't be necessary in the first place. Chart.js doesn't use any runtime dependencies, and could probably fill most of our needs. Chart.js is 50k of Javascript, which is a lot but probably more than we need. I don't know how much time it would take to make a reimplementation to have the API we need, but I think it's doable. Why would we want to do that? Because those 2000 dependencies are a liability. Last time I checked 165 were looking for funding. It would be easy to imagine a malicious actor paying a few people to contribute to low profile but widely used JS libraries, and take over the maintenance when the original maintainer becomes tired. I don't know if this is a worse liability than developing our own chart library. I don't know much about security and the tradeoff involved. All of that to say, isolation from the broader ecosystem may be a good thing.
  - ithrow 5y ago
    I guess you mean 2000 dev dependencies because for production that would be crazy.
    - Zababa 5y ago
      I'll have to check but at least half of those are for production.
brundolf 5y ago
It would probably depend a lot on what you're building Though I think the "fun work" point is really interesting and worth a broader discussion
ch4s3 5y ago
The "for free" is doing a lot of work there! :) I've been there, and you do develop the valuable human capital, but it costs time and salary. That said, you're right it is fun, and people like doing it so its good to keep your work mixed up and you team motivated. It's a good lever to pull IMHO, but not always.
- nine_k 5y ago
  Yes, it's not free in the sense that this is paid developer time, and also a delay before actual production deployment. As long as learning the basics of a 3rd-party library takes a relatively short time, those who use it have an advantage: they ship faster. Certainly mastering it may take as long as writing one's own. But you can do that while writing more production code and shipping features. Also, you get improvements made by other people for free (because likely you're using an OSS library anyway).
hardwaregeek 5y ago
I think Jane Street is a big exception. It's like when PG espouses lisp. Back in the 90's[1] language ecosystems were very sparse. An ecosystem was a few big libraries and a syntax highlighter. Now stuff like IDEs, linting, packages, etc. have made people's standards quite high for ecosystems. On the flip side, back in the day languages like OCaml and Lisp had stuff other languages could only dream about. Functions as arguments! Macros! Type inference! But now, barring macros, these features are all in mainstream languages. If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE. Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde. Which is why a lot of people are moving to Rust I suppose. You still get the hip factor but responsibly. It's the Foo Fighters of languages. Cool, but not irresponsible. [1]: I was in a very famous tv show: https://www.youtube.com/watch?v=FBw-Z8ULwcc https://www.youtube.com/watch?v=FBw-Z8ULwcc
- Zababa 5y ago
  The big difference between Rust and OCaml is that a company the size of Jane Street can influence OCaml development, while it takes one the size of Amazon (according to the recent accusations) to do the same with Rust. I think OCaml has one of those "ancient" communities that seem to value independence more than consensus. Rust is very hard to build without cargo, OCaml works fine with make or dune. I'm not sure if focusing on independence is the right tradeoff for most companies, but I can see some cases where it might be. > If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE. IDE support is getting there with OCaml. In VSCode, it's not as good as TypeScript but it's usable. > Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde. There are a few libraries that you can use. Serde also tends to make the already long compilation time blow up.
- wyager 5y ago
chillfox 5y ago
Multi-threading can often be handed off to the OS in the form of just run more processes. So in most cases there is really no need for the language to handle it.
- wyager 5y ago
  There isn't really a need for anything, which is kind of the point. You can use a random language that's missing a ton of functionality and you can probably make it work.
- throw868788 5y ago
  Its still nice to have shared memory especially in a functional language where due to lots more immutability it isn't as big of a price (i.e. more concurrency safe). Especially if your sharing in-memory caches and the like. I've seen this save tons of dollars in cloud setups (100,000's) in my career in more than one place. Safe multi-threading was marketed as part of the advantage of functional programming to many people; which IMO why I find it strange that OcAML didn't have it for so long. Lightweight threads (e.g. Tasks, Channels, etc) use less system resources than processes as well. You can do anything with anything but you usually pay some price of inefficiency to do so. That may be small, but sometimes it is large enough to matter.
  - scns 5y ago
    It took so long because they wanted to ensure the performance OCaml is known for.
    - throw868788 5y ago
      Agreed; especially since it didn't have it originally. I'm sure some compromises were made to do it in a way that fits into the execution model/doesn't cause regressions to older code. They are both good languages for sure which makes sense because one is derived from the other. F# through itself and .NET has had the equivalent functionality for many years however (Threads, Tasks, Async's, Channel libraries, etc) being the one of the first languages (before C#) to have an Async construct. I would imagine it would take some time I think for OcAML's ecosystem to catch up API wise with this where it matters for application development. Looking at OcAML's recent release notes I see work to slowly migrate multicore into OcAML but the feature itself hasn't landed yet? Think it comes in 5.0. I have to say though F# performance is quite good too those days from working/dabbling with both languages + the ecosystem is bigger. I would like to see/understand where the OcAML perf advantage is there is any for evaluation. The CLR has really good performance these days; its has features to optimise some things (e.g. value types make a big difference to some data structures, hot loops vs the JVM) from my experience especially if you don't allow Unsafe code for many algo's/data structures. For example I just looked at the benchmarks game (I know has its problems including bad contributed implementations for niche ecosystems) but it shows .NET Core (and therefore F#) performance is within the same scale as OcAML at times beating it (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...).
mbrodersen 5y ago
My experience as well. I worked in industries (Games development) where no open-source or proprietary solutions existed for what we needed. So we built it ourselves. It wasn’t that hard and we never had problems with it because it did 100% exactly what we needed and nothing else. If any new feature was needed we simply added it. I would routinely get an ask from a programmer, artist, musician or game designer and would have it implemented and a new version ready for them within a day or two. The productivity gains were immense.

pbiggar 5y ago

That was my thought (I wrote the Dark post). It also makes me think of CircleCI where they stayed in Clojure for quite some time - it really didn't have that much need for libraries (and the ones it did need, such as AWS, were provided by Java). When evaluating whether to use a non-mainstream language, the rule I use now is: - will I need to interact significantly with the outside world in a way that can only be done with libraries? - if not, do I gain a lot with this non-mainstream language? That contrasts against how I used to do it, where I viewed it as a trade-off between the ecosystem and the advantage of the non-mainstream language.

Zababa 5y ago
Thank you for the posts, the follow up posts and your perspective.

pjmlp 5y ago

That is why when comparing languages we should always look beyond grammar and semantics. This is nothing new, it is also a reason why languages like C and C++ won the systems programming wars from the 1990's. After a while one gets tired to write wrapper libraries, or having to pay extra for an additional compiler that isn't part of the platform SDKs. Hence why successful languages always need some kind of killer feature, or a company with deep enough pockets willing to push it into the mainstream no matter what. Same applies to new OS architecture ideas as well.

davidw 5y ago
I wrote about the economics of programming languages a while back: https://www.welton.it/articles/programming_language_economics.html https://www.welton.it/articles/programming_language_economic...
- pjmlp 5y ago
  Thanks for sharing, spot on. I like the Tcl example, that is how we worked at a .com startup I was part of.
int_19h 5y ago
It's also why C++ won - for the most part, you could just reuse C libraries as is by including the header inside an extern "C" block. These days, Zig seems to be explicitly trying to do the same thing, but without paying the backwards compatibility tax: https://ziglang.org/documentation/master/#Import-from-C-Header-File https://ziglang.org/documentation/master/#Import-from-C-Head...
- dleslie 5y ago
  Nim does it better, it can be used anywhere C can; zig cannot.
  - Zababa 5y ago
    As I've said somewhere else, don't think in terms of languages but in terms of use cases. Nim can make a lot of sense for some cases where C is used, and not much for others. The same is true for Zig. There is no and there will never be a "C replacement", just other options depending on what you are doing.

crdrost 5y ago

Kind of, but like OCaml-to-F# is like "Dark goes from the Prius of languages nobody uses, to the Tesla of the .NET ecosystem." The aims (ecological in the car case) of the purchaser are similar, but the car [at least in its ecosystem] is sleeker and now the roads are a bit different. On the other hand this is like "Wallaroo moves from the Cadillac of languages nobody uses, to the Chevy Equinox of languages nobody uses." Like, totally fine, you grew older and had kids and needed an SUV to keep up with home life, no shame in that... but there is a wistful "ah when we were young" to the transition, no?

Zababa 5y ago
I don't know anything about cars and don't understand your metaphor at all, sorry.
- _dwt 5y ago
  I know a little about cars and I'm still confused - I think I just have a very different view of the relative "it factors" between each pair of languages. De gustibus...
  - crdrost 5y ago
    Yeah I mean that's fair too. My impressions are poorly formed but the analogy is that both F# and OCaml are based on functional programming, which to my mind takes a step back from the "imperative programming -> OOP -> shared state multithreading" history into an alternative history, I'm phrasing this as them being "electric cars" for the first half. OCaml is not really the swankiest of swank in the alt-languages community, so I chose a Prius to be like "what's a car that folks know as eco-friendly but it's not very prestigious?" ... meanwhile F# is like "we are THE functional programming of the .NET world, come over here we're cool and slick and all-electric" hence the Tesla comparison. Pony is like the far-off "ah maybe someday I'll be able to use that at work, maybe for some little experiment" thing and it reminded me of going to a dealer and being like "let me drive the Caddy, you know I'm not gonna buy it, I know I'm not gonna buy it, but I just wanted to live a little today." I don't have any particular experience with Chevy SUVs so I just chose one at random, the point was that Rust is like a "look we're just trying to be C with explicit contracts between parts that allow for memory safety" type of language, very practical and chunky and like people love it don't get me wrong... just, it's an SUV. It's less opinionated and more just "let's get from point A to point B safely."

travisgriggs 5y ago

How depressing. Probably true. But depressing nevertheless. Bigger frameworks, more complicated libraries, deeper multi tiered tooling, all of these things that we call ecosystem, reduce access to general purpose programming and creativity. We've created a bureaucracy of execution so complicated that we need vast amounts of funding to keep us at the tiller doing the biddings of e-commerce apps. It's like the founding fathers of programming have been reborn as Sir Humphreys.

Zababa 5y ago
If you're doing things on servers that you manage yourself and not using lots of saas, you can probably still do things in an obscure programming language.
Karrot_Kream 5y ago
This is how it is in every applied field. It's not as if 2x4s fall from trees and we use them in our construction. The 2x4 is a specific manufacturing output that's used as inputs for lots and lots of other things. It's the same way when it comes to software. Just like when doing cabinetry nothing is stopping you from processing wood yourself, likewise nothing is stopping you from rolling your own frameworks. But then you'll find you're closer to selling a Morton Chair [1] than regular furniture. (And FWIW that might be fine for your problem domain, especially if you're in the market of beautiful, high-value, handmade chairs with long lead times.) [1]: https://www.mortonfurniture.com/ https://www.mortonfurniture.com/
- travisgriggs 5y ago
  Where this fails for me is that the 2x4 is a standard. And it's simple. And it's universally acceptable. I can send my wife and my kids alike to buy one from who knows where with little to zero instruction. They can work with it with ease. The "ecosystem" fades into the background. But modern software ecosystems are the exact opposite. You spend more time trying to learn/master/navigate the ecosystem than you do working with the metaphorical 2x4. To make matters worse, getting a 2x4 has been temporally stable for a long time. Not much has changed since my grandfather could send me to the store to buy a 2x4 on my own. But software ecosystems evolve and migrate weekly. Your argument demonstrates that all developed fields create ecosystems. But it does not address the issue that not all ecosystems are equal. Some are good. Some are bad. It's my opinion that modern software ecosystems look more like the British Civil Service than the ecosystem that produces 2x4s.

lmm 5y ago

It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byzantine tower of confusion goes into making an IDE I started to have a bit more sympathy for that kind of decision.

d3nj4l 5y ago
Why can’t you just use IntelliJ CE? You won’t get some of the web programming features, but otherwise it’s perfectly capable.
- vips7L 5y ago
  There’s also the Scala Metals language server and bloop. Plenty of options outside of eclipse.
- lmm 5y ago
  > Why can’t you just use IntelliJ CE? It's never had working error highlighting for Scala. I filed a bug where using a parameterized member type was incorrectly highlighted as an error, the next version using a parameterized member types was never highlighted as an error. I filed a bug with a case that should have been an error wasn't, the next version my original bug was back. I gave up at that point.
pkulak 5y ago
Kotlin is strictly worse if you value language features above all else. In that, there are several (several!) features it doesn't have.
- kaba0 5y ago
  I’m not one who values languages based on number of features alone (otherwise C++ or C# would be my all go), but based on the synergy of them. I think in this case, Scala is a really elegant language with many features that all come from some simple to understand primitives, for example everything is an object, that creates a highly coherent language. This is in contrast with Kotlin, that tries to gain popularity by including many features, but always feeling “just sugar syntax over Java” to me.

Rapzid 5y ago

Heh, that's a good reference I hadn't read before. I feel like maybe Clojure and OCaml were strike one and two followed by a home run with the F# and dotnet call. Prob feeling real smug right now with aot, wasm, and hot reload being first class citizens haha.

blondin 5y ago

> Ecosystem matters a lot these days. and having a big ecosystem doesn't mean it's a good or a healthy one either.