41–50 of 178 posts
Earlier quoted context omitted.
For every widely used technology, someone had to be the first. And then some small group had to be the early adopters.
If you are a startup it’s best to focus on the product and not necessarily the implementation Groupon was prototyped in Wordpress.
Earlier quoted context omitted.
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...
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 com…
Were these run on CPUs or GPUs? How many of them? Last I looked at running Tensorflow models on CPUs it was really slow, so slow we had to abandon it.
Earlier quoted context omitted.
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...
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 com…
I will also add that Rust is not trying to be C (and neither trying to "replace C"). It's here to offer an alternative, that in some cases makes more sense than sticking with C. C code means a lot of thing. For example, some people code in C89 because they find some kind of purity in it. You're never going to get that from Rust. For some people, it means fast and secure code, like with Python's cryptography. That's a place where Rust can be used. For some other people, it's C because that's the only thing that's allowed by some authority. Again, Rust isn't going to fit here until/if it's allowed. I think in general, trying to reason in terms of use case leads to better comprehension than trying to think in languages.
But outside of that, the move was basically the same. They found another language that's very similar, but that has a way bigger ecosystem.
Just a thought. Rewriting the core platform from one language to another just takes huge resources for orgs who are in high growth path. It feels like a side mission, derailed from core value that is solving the problem statement. Rewrites are generally a red flag for me, especially early in an orgs history.
There's no rewrite here.
This feels like the same pattern as Dark leaving OCaml for F#: 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…
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 *…
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.
This feels like the same pattern as Dark leaving OCaml for F#: 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…
Shocking that using a language that no one use was a mistake on the long term. It made 0 sense what so ever to use it in the first place.
Making bad choices happens all the time. Learning to correct them is a good skill to build up.
You'd also learn that this is a different product with different requirements.
There's no such thing as the "best language" - there's the "best language that fits your problem domain".