[HN Gopher] Caramel: An erlang back end for OCaml
___________________________________________________________________
Caramel: An erlang back end for OCaml
Author : todsacerdoti
Score : 111 points
Date : 2020-09-27 09:08 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dynamite-ready wrote:
| What is it about Erlang's AST, that attracts so many language
| designers?
| marianoguerra wrote:
| The target language is really simple and all the tooling for
| the erlang compiler itself is in the standard library.
|
| so it's easy to get started, easy to get something usable quick
| and easy to see how it's used in real stuff.
| miloandmilk wrote:
| Not an expert - so just a guess, might be more to do with the
| advantages the BEAM provides?
| sigwinch28 wrote:
| I don't think it's the AST: I think it's the BEAM itself.
|
| The intermediate representations used in (and even accepted as
| input formats by) the compiler are relatively unstable, with
| the exception of the Erlang Abstract Format.
|
| This makes it a great target for other compilers because they
| don't have to track breaking changes to the intermediate
| formats, they don't have to worry about generating BEAM
| bytecode, and they get to take advantage of all optimisations
| already implemented in erlc (the Erlang compiler).
|
| As an example of recent amazing changes to the BEAM: JIT to
| x86_64 https://github.com/erlang/otp/pull/2745
| laser wrote:
| Perhaps it's a lot more than the AST that's attracting them?
| Like maybe the actor model (genservers)? Or OTP overall as a
| great platform for building self-healing, fast, distributed,
| _functional_ systems? Or Immutability? There 's lots of things
| to like about building on a foundation like Erlang.
| rkangel wrote:
| The BEAM provides an unmatched concurrency model and related
| infrastructure. Targeting a language at it gets you all the
| benefits of that language plus all of the fundamental work done
| to build distributed systems.
|
| Another way of looking at it: almost nothing that is important
| or wonderful about writing Erlang is the language itself. Most
| of what people rave about is the BEAM. This means you can
| fairly easily throw out the language and use a different one
| and get all the benefit.
|
| Now that I'm thinking about it - that last point is a
| spectacular achievement of design and abstraction.
| hobby-coder-guy wrote:
| Why?
| Nelkins wrote:
| Looks cool! There's also a similar project for F# (but hasn't
| been updated in a while):
|
| https://github.com/kjnilsson/fez
|
| https://skillsmatter.com/skillscasts/11312-fez-fsharp-type-s...
| varbhat wrote:
| Honest Question :
|
| What is the real benefit of this over ocamlc ? Can we get erlang
| interop ?
| rkangel wrote:
| Given the readme shows the ocaml being executed from an erlang
| interpreter, pretty sure yes.
|
| You basically can't run anything on the BEAM without that
| interop anyway.
| ulucs wrote:
| One thing I'd really love to have on BEAM was a strong type
| system. Does this help achieve that? Is there a way to interop
| with Erlang/Elixir libraries?
| tym0 wrote:
| Gleam looks really neat.
|
| https://gleam.run
| Multicomp wrote:
| This is the one I'm watching. Besides the docs not being done
| towards the end of the getting started syntax guide, it seems
| to be among the most developed of the make Erlang static
| typed competitors.
| cosmos64 wrote:
| There is also the (now unmaintained) FSharp converter to it:
| Fez. And Elchemy. Also unmaintained. Sadly.
| b3orn wrote:
| > One thing I'd really love to have on BEAM was a strong type
| system.
|
| Isn't BEAM already strongly typed? Did you mean a static type
| system?
| wut42 wrote:
| Facebook is going to release soonish a new language on the
| BEAM, that's fully static typed.
| slifin wrote:
| Ugh I hope this isn't going to be another php->hack project
|
| Static analysis is great and required for modern development
| in dynamic languages and CPU/memory intensive to do well
|
| These big companies should write their own LSP server since
| all editors support the LSP protocol and mandate their use in
| employee editors
|
| Waiting till compile time to find that typo is rubbish, at
| runtime and compile time there should be as little checks as
| possible to keep performance up and the application running
| but on every keystroke in the editor it should be check city
| and again in CI
|
| Instead Facebook keeps lagging up their dynamic languages by
| building incompatible languages with static analysis into the
| compile step fracturing communities for a worse solution
| conradfr wrote:
| To be fair Hack made PHP getting serious about PHP7 and
| nowadays you get really great strong and strict typing,
| with PHP8 going even further.
|
| With a good IDE it's more pleasant than writing Elixir with
| typespecs and guards in that regard.
| tym0 wrote:
| There is more information in this talk:
| https://youtu.be/RHnjPW4YOrs
| amw-zero wrote:
| Why do you want that? Interestingly, Joe Armstrong said that
| people always asked about a static type system, but he couldn't
| figure out the value of them. They were able to build extremely
| reliable systems with Erlang's existing type system. And he
| mentioned at least one project that was 2 million LOC, so these
| weren't just toy projects.
|
| So what are you unable to accomplish in Erlang that makes you
| feel like it's missing something?
| brightball wrote:
| From the conversations that I have seen, it seems to just be
| a comfort level thing. I haven't seen many strong arguments
| for it other than "I want it because it helps me a lot in
| other languages."
|
| The benefit just isn't that prominent in a system built for
| the BEAM from what I've seen. And there are a bunch of
| negative trade offs that make distribution and hot reloading
| a lot more complicated.
| giantDinosaur wrote:
| How does one avoid type errors in Erlang applications? If the
| answer is 'testing' then types are indeed an obvious gap in
| the language. If it's something else, I'm genuinely
| interested to know. What makes Erlang so special that a lack
| of types actually aids (or at least does not at all hinder)
| in long-term maintenance/refactoring or enforcing type-level
| constraints on values?
| filmor wrote:
| Erlang doesn't lack types. It's also strongly typed. You
| can get quite far with properly chosen guard expressions
| (`is_binary`, `is_number`), general pattern matching and
| Dialyzer to check what's checkable.
|
| Static typing severely hinders hot code-reload, which was
| deemed more important for long running systems.
| loxs wrote:
| These are runtime checks and have nothing to do with what
| most people understand under the term "static
| typing/types".
| igouy wrote:
| Dialyzer is a static analysis tool.
|
| https://erlang.org/doc/man/dialyzer.html
| loxs wrote:
| After many conversations on the topic with good to great
| Erlang programmers (I also have 7 years of experience under
| my belt) I come to the conclusion that they just "don't get
| it".
|
| Probably there is a subset of extremely smart people who
| can write good and very reliable software in a dynamic
| language without going mad, but I am not among them. In the
| end I just left the language and now I am much happier with
| a mix of TypeScript, OCaml and Rust
|
| Also the reliability they are talking about is quite
| different from the reliability that most people (especially
| ones who have not worked on erlang-y systems) think of when
| they hear the word. The Erlang reliability is about finding
| bugs and patching them (often in production) and not about
| avoiding them in the first place. Also it's about avoiding
| total system failure because of some bug in a part in it.
| This is a nice to have thing in all systems, but Erlang
| makes it easier to implement.
|
| Of course, they also like to avoid bugs, but for that they
| use testing. And of course, we have to mention dialyzer
| which is something like TypeScript for Erlang but a lot
| less polished and with practically no tooling support. It
| is used in every significant Erlang project but the process
| is IMO quite sub-optimal and the price you pay (in
| suffering) is quite high.
| coldcode wrote:
| I've never worked in Erlang, but I did use Objective-C
| for a long time, and switched to Swift almost 5 years
| ago. Strong types makes it massively easier to ship high
| quality applications, while I could do so in the C
| variant it took a lot more effort and testing. In Swift I
| can make the language make it almost impossible to create
| erroneous code.
|
| It's not that you can't make good code in any language,
| but the cost is often not worth it; anything that makes
| it easier and more reliable saves you time and effort in
| the long run.
| Multicomp wrote:
| Your last paragraph is why I enjoy F# and rust as much as
| I do. If the computer can do more to help you make
| illegal States unrepresentable then why not let it?
|
| Hence I am waiting on Gleam before I invest in Erlangy
| stuff. In the meantime I will explore the actor model of
| concurrency with F# Mailboxes.
| lostcolony wrote:
| 'Of course, they also like to avoid bugs, but for that
| they use testing.'
|
| This is kind of the key bit.
|
| To caveat this - I'd like better typing in Erlang, and
| when i last used it in production I added type
| annotations to everything and ran Dialyzer as part of the
| build. But this is personal preference, and I'm not
| convinced it was the best use of my time; just the most
| conservative way to approach things for a system I needed
| extremely high uptime on.
|
| You have to write tests anyway. Just because a statically
| typed system compiles doesn't mean your test load is
| reduced. While it eliminates certain classes of bugs,
| those same classes mostly get covered just by writing
| functional tests of sufficient coverage.
|
| Between that, and Erlang's supervision tree (so that if
| you DO get a type error at runtime, it would be in a path
| you haven't adequately tested, and so not your expected
| 'happy path', and as such, can reasonably be restarted),
| it strikes me as a reasonable position to take.
| andrenth wrote:
| Pattern matching and immutability help a lot in practice,
| even with dynamic types.
| StreamBright wrote:
| The biggest use of the static type system to me is
| development efficiency. I can write type safe code much
| faster than I can write duck typing code.
|
| Examples:
|
| - I accidentally pass in 3 params instead of 4 to a function
| (with static typing this does not compile)
|
| - I forgot to handle an edge case (I can use a discriminated
| unions for example to handle all cases explicitly)
|
| - I did not check if something was null and pass it in to a
| function (does not happen in most ML languages)
|
| I know that you can have editor plugins to handle these,
| still. I can develop reliable code much faster in F# than in
| Clojure, even though I love Clojure to death.
|
| You can do many things in Erlang that helps with these, still
| it would be really good to have a language that unifies
| Erlang and ML (any ML with Hindley-Milner type system would
| work).
| lostcolony wrote:
| - I accidentally pass in 3 params instead of 4 to a
| function (with static typing this does not compile)
|
| In Erlang this will also not compile, unless you have a 3
| parameter version of the function, in which case static
| typing will not help you.
|
| - I forgot to handle an edge case (I can use a
| discriminated unions for example to handle all cases
| explicitly)
|
| You also forgot to write a test it sounds like. And if it
| affects your production code, you also forgot to think
| through your supervisor restart strategy.
|
| - I did not check if something was null and pass it in to a
| function (does not happen in most ML languages)
|
| Null isn't a special thing in Erlang. You can have the atom
| 'null' or 'undefined' or whatever, but that's an
| intentional assignment you create. And given the single
| assignment immutable nature of Erlang, you won't
| accidentally be setting/leaving things set to 'null'.
| splintercell wrote:
| Have you written code in an ML flavored statically typed
| language? If not then I highly recommend experiencing it.
| Your post (especially that second reasoning) reminds me
| of my pre-ML days when I used to be rabidly anti-static
| typing.
|
| In theory what you say is equivalent, but in practice,
| thinking about these things at the design phase is far
| more easier than to handle them with testing (which is
| pretty forgiving if you miss things).
|
| https://i.redd.it/2uxj8u6yx9121.png
| Multicomp wrote:
| I am not GP.
|
| > unless you have a 3 parameter version of the function,
| in which case static typing will not help you
|
| I half disagree. Let's say we go with the above scenario.
| If you have a three parameter function, static typing
| adds a check that the input parameter types need to
| match, if they don't, the program will not compile.
| Additionally, the returned type of the function may also
| not match, which would also be caught by the compiler,
| and depending on when the developer is writing the code,
| maybe immediately by the developer noticing that the type
| signature of the function does not match what they
| expect.
|
| With dynamic typing, those checks have to happen at
| runtime or as a human written test. But if the compiler
| is smart enough to do it automatically, why not use that?
|
| > You also forgot to write a test it sounds like. And if
| it affects your production code, you also forgot to think
| through your supervisor restart strategy.
|
| Programming languages like F# have exhaustive pattern
| matching, which obviates the need for testing on whether
| all cases of a union type have been matched, because if
| they haven't, the compiler will emit a warning or error
| depending on one's language server settings. Whichever
| setting is used, the developer immediately knows they are
| missing a pattern match case at compile time.
|
| >ngiven the single assignment immutable nature of Erlang,
| you won't accidentally be setting/leaving things set to
| 'null'.
|
| This is similar to ml languages like F#. They are also
| immutable by default. F# calls it "unit".
| rkangel wrote:
| "Is possible to do" isn't the same as "helps you to so".
|
| You can write extremely reliable code in C (e.g. medical
| devices and car ECUs) but you have to be vary careful with
| any concurrency and usually dynamic memory allocation is
| banned. An enormous amount of testing and other design rules
| are needed. Maybe Rust would help to automatically check some
| of those things that otherwise require a lot of work to
| achieve.
|
| You can write highly concurrent server applications in C.
| It's a lot of work and bug prone. If you write them in Elrnag
| or Elixir your life will be much easier. That's why we use
| them.
|
| Maybe a static type system would help enforce some invariants
| about your code. Maybe it saves you from witting some classes
| of test. Basically, maybe you get to the same endpoint but
| with less work.
| romanoderoma wrote:
| > _" Is possible to do" isn't the same as "helps you to
| so"_
|
| The things that help you usually also limit you
|
| See: training wheels or armbands
|
| I've seen much code written in static typed languages
| (mostly JVM languages) that supposedly help the programmer
| to write better code or code with less errors just by
| playing tennis with the compiler
|
| Thruth is that most of the code I've seen written "with
| type aids" is terrible from any other point of view
|
| The types are correctly passed to each function, but what
| purpose those types serve it's a mistery
|
| When you only have numbers, binaries, lists and tuples,you
| are forced to think about data structures in a simpler and
| more elegant way
|
| IDE generated "type safe" code too often is simply "a class
| for everything" and bad abstractions
|
| Most of the time when I review code my remarks is: it
| should be a 10 lines function, why did you write 10 classes
| with 10 getters and setters each?
| m45t3r wrote:
| > Most of the time when I review code my remarks is: it
| should be a 10 lines function, why did you write 10
| classes with 10 getters and setters each?
|
| This is the fault of the language or programmer itself
| instead of its type system.
|
| I am programming in Dart and sometimes I feel that I am
| writing some code just to workaround some limitations in
| the language (the language itself is nice 90% of time,
| just to make it clear).
|
| Now, I also program in Python using mypy, and I never
| needed to write "10 getters and setters" to make the
| compiler happy. Sometimes I do need to write additional
| code to make mypy happy, but generally it is in overly
| clever code that mypy doesn't understand. So generally
| fixing the issues makes the code better.
| higerordermap wrote:
| If nothing, it is great for IDE support and refactoring.
| ollysb wrote:
| A new effort just popped up to have another crack at adding
| strong types https://elixirforum.com/t/typechecker-for-
| elixir/34474/7
___________________________________________________________________
(page generated 2020-09-27 16:00 UTC)