Sucks (.. maybe?) for the creators, but I'm so glad this is being done.
How else are you going to know which of these GPTs are garbage or not without wasting all kinds of time and energy on them otherwise?
Personally, more than happy to use anyone else's GPT to support them if it's good and clear that they've put good effort into it. OpenAI should create an interface like Github that lets folks collaborate on prompts instead of this derivative black-box concept.
We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit but for DSLs we built for finance and contracts).
While most folks tend to see F# as a .NET-oriented/back-end kind of language, they'd be missing some incredibly unique web technologies such as the Fable compiler (F# -> JS, Python, Dart, etc) and Elmish (Elm, but for F# with a JS target via Fable). It boggles my mind that more of the web dev community haven't discovered these tools.
These "communities" fall completely outside of MSFT's umbrella, but are transformative for how you think about architecting applications: Elm as an architecture (rather than as a language) enables a large amount of optionality in terms of what technologies one might use as a "reactivity layer" (e.g. can swap out React for SolidJS or even non-JS targets like Avalonia quite easily if it made sense to).
Our bet is that it enables us to future proof things in a number of unique ways as better WASM-based solutions come online as well that hopefully won't require shipping the whole .NET runtime (e.g. Bolero). The approach is also v helpful in managing state across an otherwise very complex application.
I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.
Yeah, I suppose it depends on what you're building.
Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS.
With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation.
To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.
FWIW the benefit tends to come in the long run. Same argument as TypeScript, really. You add some conceptual overhead to get code that fails less in the face of change, better refactoring, etc.
Is it really appreciably different from "transpilation" with TypeScript?
Like, I have seen a little of both (I've used a lot of TypeScript, but who actually looks at the output JS lol), and while I agree the JS output from Fable seemed surprisingly verbose, I'm not sure I see how it practically matters unless one is worried about bundle size or something.
I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more.
For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.
> In theory Elm is just such a fascinating project... if it was not held back by the people developing it.
PureScript may be worth a look, it’s got several features that were rejected by Elm devs: typeclasses, ability to publish modules that use FFI to JS, runs server-side, etc.
Please PLEASE enough with the character assassination of the Elm guy.
He wants to run his own project his own way.
There's a small but dedicated residue of people who just can't stand being told "no" and go around crapping on the kid whenever they get a chance.
I get it. You don't like Evan's project management style. Move on already.
- - - -
The fact of the matter is that he's a person who took his thesis, made it into a product, and got traction in the real world. People have used Elm to make things. Things that go.
How many of us can say the same?
And that's before you get to all the fascinating and as yet still-too-obscure things that the OP talks about. Things that are in part a little more widely known and understood thanks to Elm project.
We should be open & honest in our discussions about whether we genuinely recommend a platform or project to others, including the details which underlies our thoughts.
As I go through rewrites and greenfield projects and so forth, I begin to realize that for any particular technology you are not simply having a relationship with a static list of pros and cons, but you're also having a living relationship with the team behind the work.
In other words, a bet on TypeScript is also a bet on the TypeScript team, and in my experience the TS team is very fast at their work. This makes me more forgiving of bugs. Similarly, a bet on Terraform is also a bet on Hashicorp.
Here we have someone recommending a choice of F# over Elm because betting on the leadership is allegedly not good. This is not character assassination. The commentator is not criticizing Evan on irrelevant private affairs and by extension saying that you shouldn't use Elm. Evan has created a company and is advocating for his product; he is a public figure and is being criticized on the grounds of project management.
This is not only about leadership style, but also founding. I don't know the current TS team, but I know its dozens of full time workers backed by microsoft, not only core devs, but community organizers, evangelists, etc. There is no comparison to an independent project.
Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such.
I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who don't want to collaborate, who want to take their ball and tell others how to play with it, really putting the 'dictator' in BDFL." and you know what? that's fine. I don't harbor anything against them as people. But that left a permanently bad taste in my mouth and I'm unlikely to ever trust that group or a project they're managing.
Without this management style Elm would be the oppositive of what it is today
(simple language, very fast compiler, efficient tree shaking, no runtime exceptions) wanting to add at all costs Haskell features and JS direct sync interop.
Because of that management style, it has been bitrotting for FOUR YEARS and has even gotten forked by a couple people involved so at least some progress could continue.
I simply don't think locking down the compiler so only blessed Elm devs can modify internals was necessary. I don't think the flack given to people forking the repo was necessary. Say no to pull requests, fine. Don't try to control the technology.
From outside, with no knowledge of this "ELM Controversy", this is all very confusing.
I love the ELM Architecture. Why is there a problem if it is implemented in another language?
I'd think any functional language could implement the ELM Architecture, and thus be 'native', or more integrated into that particular languages ecosystem, and this would offer benefits beyond trying to integrate ELM into each individual ecosystem.
And doing this re-implementation, would in no way be a comment on the ELM founder.
Also, Doesn't Linus say "NO", quite a bit with Linux? Why jump on the ELM guy for doing same thing.
When Linus says no, he rejects features and pull requests. That's fine. That's responsibly shepherding your implementation.
That's not what Elm does. They lock down the compiler so only Elm devs can modify internals, which would be equivalent to Linus trying to prevent people from modifying the kernel.
They really don't like people forking their repo, which would be equivalent to Linus getting mad at people making derivative kernels (because it would "split the community.")
It's not just a matter of saying "no," it's trying to control what devs do to an UNREASONABLE degree.
The link is that Elmish is a competitor of Elm, and that the creator of Elm is a factor to the evolution of Elm. Leadership is a big deal in open source and is the sole differentiator behind the late iojs and OpenTofu. The matter of leadership is especially weighty for niche or emerging ecosystems like Clojure, Rust, or SolidJS.
FWIW my comment was along the lines of allergic reaction. I'm not an Elm fanatic, I'm just sick of seeing people snipe on the dude.
You're entitled to your opinion, of course, and you articulated it well. But again I see it as another example of someone not liking being told "no", no?
That's really reductive and biased against us, the potential user base of Elm that decided not to engage. Why is it that we don't like being told "no," as opposed to the Elm leadership and Elm community not liking being told "this isn't a 100% solution for me so I'd like to modify it"?
Obviously Elm is his passion project, that's fine. But nobody who locks down their compiler on a supposedly "open source" project can actually seriously expect others to engage with that in good faith.
Furthermore, the absolute state of just trying to modify Elm to be more fit for purpose is horrendous. Every time I see a parallel implementation or a fork, the author has to bend over backward with platitudes to placate the Elm masses and ensure them that this project isn't trying to "split the community," which is a nonsense idea to start with imo.
It feels cultish, on top of a project that is actively hostile to people who want to use it any way other than how the BDFL has mandated its usage. If you want to say the problem is with the users, that's fine, but that's exactly the attitude keeping me from ever engaging. I personally think the problem is with the people who want such fine control over their technology and community, as opposed to understanding that they can really only shepherd their implementation. That's about as far as their reach rightfully extends.
EDIT: also, the fact that they aggressively lock down their compiler and have such hostility to anyone working in parallel is imo the definition of "holding it back"
> That's really reductive and biased against us, the potential user base of Elm that decided not to engage.
My complaint isn't that you or anyone doesn't engage with Elm, that's your prerogative, of course.
My problem is that a small segment of people do engage with it whenever it comes up to smear the project in general or Evan in particular for nothing worse than wanting to run his own project his own way.
He's not an ogre? I mean here he is, look, he semms nice enough to me?
"The Economics of Programming Languages" by Evan Czaplicki (Strange Loop 2023)
https://www.youtube.com/watch?v=XZ3w_jec1v8
As far as I've seen, there was no attack on the person.
What I usually see are warnings about what happened to the project and how it is run, mostly targeted to the unaware. This is a sign of respect to people's time before they waste it on something that might disappoint them when they get to know the details.
Every time Elm comes up people climb out of the woodwork to cast aspersions on it for no better reason than that Evan wants to run his project his way. Some people evidently just can't accept that and have sustained a grudge that drives them to comment on it whenever it comes up.
Look, I get it, I'm still sore about Google Feed Reader, 'member that?
But enough is enough. It's old news. Get over it. Etc.
It's like if every time someone mentioned Caddy server there was someone bringing up that time Matt Holt put that header in and pissed off a bunch of people. Life goes on. We forgive and let things go.
It's high time for folks to forgive Evan for his mistakes. I mean, he's very young still, eh? Cut the guy some slack already?
Again, the things I read are not personal, grudges or inability to accept someone's personal choices. For starters, you write his name more than anyone else here. You're not doing him any favor specially when it comes to Streisand Effect.
When I propose a tool to my CTO I couldn't care less about the project's leadership personal choices.
Mature engineers think in terms of ROI, dependability, bus factor, predictability, funding, mind-share, hiring ease, license, etc.
But it would be naive and unprofessional of me to handwave technical issues with the tools. And ALL tools have hard edges and undesirable characteristics.
And putting a header in a HTTP server is not proportional as restricting who can change the source code of a compiler.
Evan wants to control the technology. That's a management decision that makes it unfit for purpose. This is a legitimate criticism that had long ranging impacts. I have seen no reason, no commitment from the management side, to believe this won't happen again. It is worth bringing up when there are similar alternatives without such a spotted history of lockdown and control issues from management. I know nothing about the fellow. This is not personal.
My understanding of this is that he managed to hype the language with certain killer features. A lot of people were enthusiastic and invested alot of time in learning and building in it. Evan than "suddenly" said they wanted to take the language in another direction and dropped some of the core features and pricipals that drew people in. While perhaps a mischaracterization, it comes a cross as a kind of "bait and switch" or at least undependable.
But the trail never ended at "one ought not critique my critique", so who are you responding to? If anything, saying that something is character assassination is a statement on what's off-limits for debate.
Totally agree. Even the mention of Elmish, which has nothing to do with the creator of Elm, is derailed into yet another discussion of why some people hate the creator of Elm. It is the deadest of beaten horses on HN.
He's absolutely entitled in running his project his own way. As such, it is obvious that adoption outside of his own circle is to remain minimal.
I would love Elm to be in a position where I could advocate for it at work (aside from it being a "neat hobby"). However, the simple fact is that the way Elm is run has lead to disillusionment among advocates of the first hour. And there is nothing to indicate that this will change.
And if the guy has inspired a new generation to create something to his own achievement, kudos to him. As far as I'm concerned Elm is not the enemy, JavaScript is the enemy.
For those interested in .NET languages with alternative compilation targets, F#'s Elmish (https://elmish.github.io/elmish/) is pretty unique.
We use F# on the front end (instead of TS), and thanks to the Fable compiler (which transpiles F# to JS, Python, Dart, PHP and Rust), most of the benefits of an Elm-style model in the UI can be ported to all sorts of different outputs languages. The rust target is in beta, but its promising because the WASM bundle size stands to be dramatically reduced compared to Blazor.
Congrats on the launch! Its been a far better experience than Mailchimp for us, even during the very early beta days.
How has your experience been using Lexical? Would love to get a sense of where you've run into limitations/etc as we're exploring it (albeit, for a very different use case).
Lexical has been great. I think the biggest drawback is that its an earlier project (compared to alternatives) so there are not always best practices for what we want to do. That said, the community is pretty active (in discord) and generally responsive to bug reports.
Huge congrats to the team. I reached out to them four or five months ago as we explored offline-first frameworks, and its awesome to see how far they've come in a short time.
We didnt find anyone else who was tackling the tie between client-side SQLite, an open source CRDT/sync layer, and Postgres. We found a few who were attempting to manage this in a closed source way, but it didn't make sense to give up control of the server/auth, and every other fully open source solution was SQLite -> SQLite, not Postgres.
They're syncing client-side SQLite to server-side Postgres on backend via an Erlang service that enables bi-directional active-active replication. They have a little more work to go until they solve the RLS concerns, but its been an incredible project to follow.
Cool to see it going this way. Over the last two years, we've been busy reinventing contracts and financial models as the dependency graphs that they are to provide a deterministic, intermediate representation of this information in finance.
Still not sold that it'll fly in finance without that sort of observable, intermediate representation.
See: https://news.ycombinator.com/item?id=37584049