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.
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-Head...
https://www.welton.it/articles/programming_language_economic...
There's a third strategy: hitching your wagon to an already-successful ecosystem, like languages such as Kotlin do.
* 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
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
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.
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.
Though I think the "fun work" point is really interesting and worth a broader discussion
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?
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.
A language that does NOT have as many features and limits more what you can do is NOT a strictly worse language. You can never say a language is worse than another, anyway, in general: it's always relative to what usage you have in mind. Your apparent disdain for a language just on the basis of the language features shows that you have a lot to learn about language economics, mentioned in other threads here.
and having a big ecosystem doesn't mean it's a good or a healthy one either.
Like, the only reason are computers are remotely working fine is that great deal of abstractions.
https://corecursive.com/055-unproven-with-sean-allen/#consid...
We are a little volunteer driven project and will be here whenever you find the time. Stop by the Zulip sometime and chat!
https://ponylang.zulipchat.com/
-Sean-
- garbage collection - no mechanism for synchronous access to actors
We ended up building a C++ actor model, with it's associated headaches. Yes, we still have race conditions and some developers invoke the function directly instead of using messages, and yes, sometimes we will grab a locking mechanism to do synchronous access, but at the end of the day, the performance of real code (embedded gaming system) is all that matters, and we did meet our performance goals.
Having said that, I've given up looking for an actor programming language and started building my own. Essentially, C++ like with Actors and compiler validated tracking of resources across actors (so the compiler knows about locks and actors). Still working on the compiler (compiles to C++20) and maybe 18 months away from public reveal. But the initial batch of test apps look very nice (but without compiler validation of resource sharing at this point in time). Very terse code, and implementing a compiler that outputs C++ was much easier than I originally feared. And no, there are no forward declarations or header files, compilers are run on modern workstations that have the grunt to produce the necessary scaffolding (from the project dependency script).
That is presumably intentional, since if you could access actor state synchronously it wouldn't really be much of an actor. This sounds a lot like a "doing it wrong" kinda problem.
> (but without compiler validation of resource sharing at this point in time)
Not sure how you'll do this without garbage collection (like reference counting, which is what Pony uses iirc).
Honestly I suspect if you continue forward you'll probably walk away with much more appreciation for Pony's design decisions.
It's still a fair bit away, I just got the proof of concept compiler which outputs C++ working (and the compiler is written in the language itself, so I'm dog fooding the project).
That said, I don't think we ever got any business as a result of folks having heard of Wallaroo from any of the promotion we tried to do around technical decisions.
We did however attract interest from investors who would notice when our technical content did well on HN. It certainly didn't hurt during fundraising.
Our decision to go with Pony for the original product we were building (high performance, finance focused, stream processing) was in a large part driven by time to market. We didn't have runway to build our own high-performance runtime for the product and using Pony got us that runtime.
You can hear me talking more about the decision process here:
https://corecursive.com/055-unproven-with-sean-allen/
There was more to it than that, but the "we get a runtime that can meet our needs" was a huge, huge part of why we picked Pony. I have often told people that we didn't so much pick a language as we picked the runtime and the language came along with it. That's not really true, but it's not really wrong either.
My experience is quite similar : I either end up working with clients who are already using Spark etc, or they don’t have a mature data engineering lab. In both cases, deploying a model to production is always the most challenging.
I hope their MLOps strategy is better, than just binding to MLFlow. This tool is absolutely not ready for prime time, and plagued by bad product decisions.
There's no rewrite here.
The description and outcome statistics make it sound _excellent_ and their technology stack makes their claims seem viable. However, and I say this as someone that is currently running an MLOps RFP, after looking at every page of their site and all their open job postings I have no idea what it's actually like to use their product.
I’m sure some devs would love to learn a new language at a new job, but many would see it as a career mistake. Your career income increases the more you master a certain discipline like a certain language. If you’re a jack of all trades (and adding Pony developer to your resume), you’re probably limiting your future income potential.
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.
Rightly, around the time I left the company, they pivoted and started a new product that they thought would have better product market fit and they started over with a new codebase as it is a rather different product than what we first built.
>Pony [...] has a smaller community, and as a small startup we were better off not having to solve problems outside our core domain
>wealth of available libraries
>access to a large community that will guarantee ongoing future support
>a wide variety of tools
>much larger pool of engineers who are eager to learn and work in Rust, or who already have significant Rust experience
>more resources available for learning Rust, and more opportunities for participation in conferences, etc.
Didn't say that Pony was bad for some technical reason. It was/is bad choice for a startup to use due to being a relatively new, niche language.
I've never heard of Pony before - is it any good, or worth playing around with?
I think at worst, you would get something out of learning Pony (although that can take some time, it's one of the harder languages to learn).
Feel free to stop by our Zulip and chat more as folks from the Pony community are rarely on HN, but are on the Zulip all the time.
> in the meantime data science and machine learning continued to explode ... With the increasing focus on MLOps, Rust became a better fit
This sounds like, "Our business goals shifted, as did the industry around data science, and Rust's maturity improved such that it made sense for us to migrate our stack."
I think it's fair to say looking back it was a mistake to pick Pony on the assumptions it provided marginal benefit for the exact needs of the business day 1 but at the same time I think it's fair to say that picking Pony was not a mistake as it allowed them to get where they are today.
Groupon was prototyped in Wordpress.
[edit: oops, thanks for the heads up on the spelling :)]
It's just OCaml by the way, for Objective Caml. Unless you're talking about the secret Irish fork /s.
There's a nice page on the official website about the history: https://ocaml.org/learn/history.html.
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".
very strange and odd.
