Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm Compiler Written in Elm

github.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Elm Compiler Written in Elm

#61

Post by _0w8t »

johnday wrote: post #23
egeozcan wrote: post #22

Earlier quoted context omitted.

If you don't have the urge to jump off a hill when you see heavy pragmatism, Typescript is very popular and well maintained. My experience is only positive. I was also wondering, does Blazor work with F#? That could also be an option. Not a front-end focused language but a front-end focused framework, so, there's that.

I truly believe TypeScript is the only true way forward for frontend web programming. Now what we really need is a functional dialect which compiles to TypeScript...

TypeScript or Flow for that matter sucks at using functional style with immutable data types. There are ESLint plugins that allows to enforce immutability with plain JS objects, but still lack of syntactic sugar or union types makes the experience much worse then in functional languages.

Re: Elm Compiler Written in Elm

#62

Post by wolfadex »

yladiz wrote: post #7

Serious question: how popular is Elm? I've recently seen some tutorials showing up and anecdotally know some friends that have played around with it, but I haven't seen any job postings for it and so I'm wondering if it's just hyped up or if there is real demand for Elm developers professionally.

We have a team at Square that uses Elm and I've made a few commits. They've been working on their app for around 18 months now.

I find it slightly funny because I also write Svelte at work and that app is public facing so it gets public attention but the Elm app is internal facing so the public will never see it. Also helps that Svelte uses its own name in the code it generates. Which is why I try to promote Elm myself. To semi-quote @SvelteSociety "@Square, a >$100 billon company, uses @elmlang."

Re: Elm Compiler Written in Elm

#63

Post by xfer »

pd-andy wrote: post #9
yladiz wrote: post #7

Serious question: how popular is Elm? I've recently seen some tutorials showing up and anecdotally know some friends that have played around with it, but I haven't seen any job postings for it and so I'm wondering if it's just hyped up or if there is real demand for Elm developers professionally.

Neither, really. I'd say it has the largest community out of the various compile-to-js statically typed FP langs, at least with an explicit front-end focus. - PureScript has a small but passionate community, one of the biggest players in that community laid off their whole ps team so that doesn't bode well. - ReasonML fractured into ReScript but left half the Reason community behind, it's a confusing space to navigat…

There is also clojurescript which is fairly popular. I am not a large fan of using these for websites since they have their own heavy runtime that needs to be shipped. ReasonML did fairly well in this aspect but there is still a baggage.

Re: Elm Compiler Written in Elm

#64

Post by girishso »

antew wrote: post #45
donatj wrote: post #39

Earlier quoted context omitted.

Go is open to forks and PRs though. It’s more “we’ve got a vision, but we’ll hear you out”. Elm is full cathedral, Elm comes down from the gods with no input or transparency into the decision process. The Elm developers have a history of ostracizing people who even mention the possibility of forks from the community; tester89 posted a link with a lot of good context. They take a very heavy handed and adversarial stan…

There was a similar project to `go fix` with elm-upgrade ( https://github.com/avh4/elm-upgrade ). We migrated a ~100k LOC app at work from 0.18 to 0.19 and while it was tedious, the compiler really has your back and makes it easier. We weren't bit by the removal of native/kernel code, but it definitely turned a lot of people away that may have been committed to Elm before.

True that.

We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)).

My colleague took notes of the progress at https://gist.github.com/mordrax/efcd34739ed56bb64d2b12d2401b...

Re: Elm Compiler Written in Elm

#65

Post by lioeters »

MobiusHorizons wrote: post #60
mjaniczek wrote: post #44

Earlier quoted context omitted.

I've briefly looked at LLVM and how to interface with it but back then I didn't find much else than some C++ Builder API. I'd hope for some textual format that I could give to LLVM as an input. I assume it exists and that I've just been googling wrong :) Would definitely appreciate some pointers in that regard. Other than that my best bet for native binaries is most likely compiling to C or GraalVM (which already exi…

As the other comment says, LLVM has a text based IR. But you may also want to look into QBE which is simpler and lighter weight than LLVM but has a similar text interface so you could start with that to get up and running, and then add support for llvm later.

To save anyone else a search:

QBE: Compiler Backend - https://c9x.me/compile/

QBE vs LLVM - https://c9x.me/compile/doc/llvm.html

Re: Elm Compiler Written in Elm

#66

Post by savanaly »

girishso wrote: post #64
antew wrote: post #45

Earlier quoted context omitted.

There was a similar project to `go fix` with elm-upgrade ( https://github.com/avh4/elm-upgrade ). We migrated a ~100k LOC app at work from 0.18 to 0.19 and while it was tedious, the compiler really has your back and makes it easier. We weren't bit by the removal of native/kernel code, but it definitely turned a lot of people away that may have been committed to Elm before.

True that. We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)). My colleague took notes of the progress at https://gist.github.com/mo…

Wow! Apologies if this is answered in those notes but my quick question is: Did you make extensive use of Debug.todo to cordon off sections of the app that wouldn't compile in order to work on and "see" the other sections in the meantime? That's what I do on my small elm apps, e.g. put whole features or functionality behind Debug.todos.

Re: Elm Compiler Written in Elm

#67

Post by b3morales »

girishso wrote: post #64
antew wrote: post #45

Earlier quoted context omitted.

There was a similar project to `go fix` with elm-upgrade ( https://github.com/avh4/elm-upgrade ). We migrated a ~100k LOC app at work from 0.18 to 0.19 and while it was tedious, the compiler really has your back and makes it easier. We weren't bit by the removal of native/kernel code, but it definitely turned a lot of people away that may have been committed to Elm before.

True that. We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)). My colleague took notes of the progress at https://gist.github.com/mo…

From the gist:

> We have until Friday 7th September to upgrade to Elm 0.19.

I'm completely ignorant about the transition, but I'm curious what the source of this deadline was. Would you mind expanding?

Re: Elm Compiler Written in Elm

#68

Post by savanaly »

andrewzah wrote: post #40

I know you're not trying to replace the official Elm compiler, but that's precisely what is needed. I really, really wanted to like Elm but the way it's managed is horrible and antithetical to the idea of Open Source software. With the current compiler I wouldn't touch Elm with a 39.5" pole, even if Elm is a joy to work with.

One's attitude towards Elm directly correlates with the degree to which one likes to dig into and tinker with the internals of their tools and frameworks and rearrange things. Unfortunately that means it's a hard sell around HN-- in a way it's antithetical to "hackers". But I don't think it's antithetical to John Carmack's proverbial "engineer"-- someone who wants to do what they can do with what they've actually got. Elm lets me do what I want to do, exceedingly efficiently and makes it fun, and that should make it a good choice for plenty of projects.

Re: Elm Compiler Written in Elm

#69

Post by toastal »

toastal wrote: post #13
yladiz wrote: post #7

Serious question: how popular is Elm? I've recently seen some tutorials showing up and anecdotally know some friends that have played around with it, but I haven't seen any job postings for it and so I'm wondering if it's just hyped up or if there is real demand for Elm developers professionally.

There was a sizable rift after Elm’s 0.19 version. Removing synchronous FFI, especially to existing browser APIs that haven’t been rewrapped with a new API by the core team caused a lot of individuals and businesses to migrate mainly to PureScript, Reason, and/or Typescript—myself included. Couple with community hierarchy issues, lack of development/roadmap transparency, rotting merge requests to the core libraries (…

For more context, I believe Luke Plant summed it up best in "Why I’m Leaving Elm" (https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/). This title should be searchable on Hacker News for even more discussion.

Re: Elm Compiler Written in Elm

#70

Post by RobertKerans »

_0w8t wrote: post #61
johnday wrote: post #23

Earlier quoted context omitted.

I truly believe TypeScript is the only true way forward for frontend web programming. Now what we really need is a functional dialect which compiles to TypeScript...

TypeScript or Flow for that matter sucks at using functional style with immutable data types. There are ESLint plugins that allows to enforce immutability with plain JS objects, but still lack of syntactic sugar or union types makes the experience much worse then in functional languages.

https://github.com/tc39/proposal-record-tuple

Only stage 2, so whether it'll get through to next stage is up in the air, will depend on interest (compare to Temporal which started fairly slow but has gained huge momentum recently and is now at stage 3 and engine testing level) but it's encouraging.

Post reply on HN