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

Alpaca – Functional programming inspired by ML for the Erlang VM

github.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#61

Post by Ixiaus »

spraak wrote: post #22
jerf wrote: post #15

Earlier quoted context omitted.

There's always room for another language. What's hard is cracking into the very, very top tier, the C++, C#, Java, etc. tier. I am also increasingly of the opinion that it simply takes massive corporate backing to get to that level, based on the observation that I haven't seen anything get to that level without it. Python's the only one that has arguably gotten there, I think, and it's still debatable. That said, I d…

I'd love to have something that takes the best of Go (static typing, fast compiles, binaries, community) and functional paradigm.

Rust?

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#62

Post by jnbiche »

Ixiaus wrote: post #61
spraak wrote: post #22

Earlier quoted context omitted.

I'd love to have something that takes the best of Go (static typing, fast compiles, binaries, community) and functional paradigm.

Rust?

Rust doesn't have fast compile, and I think it's hard to argue that a language without TCO is a functional language. Recursion is a critical part of the functional paradigm.

Also, I think a lot of people are attracted to Go because it's very simple to learn and use. Rust with its borrow checker is definitely not simple to learn and use.

But it's true Rust has some functional features.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#63

Post by jnbiche »

Athas wrote: post #53
jerf wrote: post #26

Earlier quoted context omitted.

Ocaml is close. Not sure how their concurrency is going, but I'm sure the act of mentioning that will bring someone out to bring us up to date.

Compared to Go, OCaml is unfortunately a rather large language. It has many non-orthogonal features, some of which are not used widely. The impression I get from Go programmers is that the small size of the language is one of the chief attractors.

> Compared to Go, OCaml is unfortunately a rather large language.

I agree. That said, ML is definitely a small language like Go, without OCaml's extras like the object system.

Alas, ML lacks Go's awesome and very modern standard library, which is a key part of Go's allure.

But yes, I would adore a functional language with Go's best features, particularly the standard library, solid concurrency, simplicity/ease-of-learning, fast compiles, binaries, static, etc.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#64

Post by wtetzner »

Athas wrote: post #53
jerf wrote: post #26

Earlier quoted context omitted.

Ocaml is close. Not sure how their concurrency is going, but I'm sure the act of mentioning that will bring someone out to bring us up to date.

Compared to Go, OCaml is unfortunately a rather large language. It has many non-orthogonal features, some of which are not used widely. The impression I get from Go programmers is that the small size of the language is one of the chief attractors.

There's also Standard ML, which smaller, and fully specified, with multiple implementations.

But I think part of the problem with both is tooling. Build and dependency tooling in particular. Opam was a good step in the right direction, but I think OCaml and SML could both benefit from a Cargo-like tool, that made managing projects and their dependencies simpler.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#65

Post by wtetzner »

salimmadjd wrote: post #11
platz wrote: post #7

Earlier quoted context omitted.

> enough eyeballs left for a new language that does not have a large corporate backing It's a solid point if the goal is winner-take-all style competitive victory. But I'm not sure software should co-op SV-startup-business exponential growth-or-die mindset. What happened to hacker culture? Are open source developers corporatist now? /end-speculative-rant

The point I was making is for something to get enough traction, so that it would get active contributors who help mature the language, tools, etc. I think there are only handful of people out there who can contribute in a meaningful way for a project like this. If they are consumed working on open source Swift or doing pull request on many things pushed by FB or Google or working contributing to existing projects lik…

The good news is that you don't need that big of a community for a language to do well. It does, of course, need to be big enough, but you don't need to compete too hard with the big corporation-backed languages to have your language community grow enough that it can sustain itself.

Of course, I guess I don't have any real data on it, so this is just my intuition based on observing various languages. So, you know, just my 2 cents.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#66

Post by louthy »

cousin_it wrote: post #50
louthy wrote: post #33

Earlier quoted context omitted.

I find this to be a really poor argument. Essentially you're lucky if your systems continue to work as others go off changing message formats without consideration for the code that will receive it? On a suitably complex/large system this is a recipe for disaster. Things start to slowly rot. It is far better to maintain the old function, accepting the old struct, map it to the new struct and forward it on to the new…

I've worked with systems like that for years, and it's fine. We can have several large binaries with different release schedules, passing around a big struct with 50 fields and many nested structs, with different people making changes to different parts. And nothing breaks. New code accepts old structs, old code accepts new structs, no conversion code required. To achieve that, we follow the design of Protocol Buffer…

What you're describing sounds like a manually implemented type system.

> Each field in each struct has both a name and a numeric id. Only ids are used for serialization, so field names can be changed at any time.

Fair enough your field names can be renamed. But the 'contract' is field numbers, not names.

> All fields are marked as optional or repeated, never required. Most code is written to handle missing fields gracefully.

So if all fields are optional, and you provide no fields at all, what happens? I assume the process rejects it, because it's not of the correct type?

> Changing the type or id of an existing field is forbidden.

Forbidden by what?

> Adding a new field is okay, as long as you use an id that was never used before. (Each struct definition has a comment indicating the next available id to use.)

I can understand this being the least problematic change to a type. But it still leads to 'if x has y field' behaviour, as your code tries to manage the full range of possible message types it might receive.

> Removing a field is okay if you've checked that no one is using it anymore.

That sounds super fluffy.

> As a small but intentional bonus, you can change an optional field to repeated while preserving binary compatibility.

Sorry, I don't follow? This bit confuses me 'change an optional field to repeated'.

> In the end it works out. You can think of breakages that could theoretically happen, but they don't.

I can think of many:

* If picking of IDs is done by a human, at some point a human will make a mistake and re-use an existing one

* If 'Changing the type or id of an existing field is forbidden' is a human enforced constraint, then it will fail

* If you think a certain struct pattern can't happen any more (you think you've retired all nodes that send the old format), and then you deprecate the many matches that deal with legacy messaging, and then realise that actually there is an old node that does it after all.

* You may re-add a field to a type which was previously removed and cause unexpected behaviour in parts of the system that match on that old format

* Removing a field that you thought wasn't used any more but actually still is

By the way, I'm not suggesting it's not possible to develop robust systems without a static type system of some sort; but I do think the hoops you're jumping through in items 1-6 indicate the problems of not using static types. Each change in functionality could just use a new struct, with a new function, and the old function maps to the old struct to the new one. It captures precisely the change in logic in one place, has no runtime cost for nodes that are sending the new struct, and can't lead to the edge cases that I listed above.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#67

Post by platz »

runeks wrote: post #57
platz wrote: post #21

Earlier quoted context omitted.

> everything that uses that type is statically checked to be "behind" that gateway In a distributed system, the largest the "gateway" can reliable be is a single node, because you don't get guarantees about the code that other nodes in the system are running. Even the single node case poses difficulties, because I believe in OTP the upgrade path means you have to transfer state during upgrades. What if the types of t…

> [...] etc... it gets complicated Which is exactly why we want to employ static types: in order to catch the difficulties in implementing it correctly. We describe the complications in the type system, through a model that captures them, to allow compiler errors -- rather than runtime errors -- to guide us in implementing it correctly. Types only hinder getting an invalid program to compile -- which is exactly what…

In general, sure - but this post is about erlang/OTP, and the way you're speaking in generalities makes me think that you're just trying to persuade me about and champion the value of static types in general.

To digress slightly, consider an example from another domain, although I would rather keep this discussion about erlang. Now, Haskell is the only well-known language that has lazy (non-strict) semantics. Over the years many folks have proposed to make Haskell strict by default, alleviating some of the headaches that occur from non-strict evaluation. However appealing that may be, it would be a sad day if that occured, because we'd loose the only language to understand how lazy/non-strict evaluation affects how we design programs while there are countless strict languages, and lazy/non-strict evaluation has some very nice properties indeed.

Now to bring this back to erlang/OTP... sure, it is very nice when we add static types to erlang because we get all the nice things that static types provide, but we also loose some things. There are some features in erlang/OTP that are very dynamic, and forcing a static type system simply kills those features. I think that would be a sad day for the erlang, because you'd loose the ability to design distributed systems utilizing the full range of behaviors what the erlang/OTP system offers. There are already other actor systems in the world that offer static typing. You don't need erlang to build those systems—There is only one erlang/OTP that some some very unique features that none of other have.

Say, if we're talking about javascript, which runs at the level of a program on a single machine, I say bring on the types. If we have some other statically-typed actor system that works well for certain use cases, great. If we're talking about erlang/OTP, which is designed specially for fully distributed systems, I say let it be.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#68

Post by geofft »

dmm wrote: post #23
geofft wrote: post #12

Earlier quoted context omitted.

The Apache license has an explicit patent grant (the MIT license says "permission to use", which isn't a copyright grant, so it probably has an implicit patent grant), and an explicit statement that patches intentionally submitted for merge are submitted back under the Apache license. The reason we have licenses at all instead of the Unlicense or similar is to make things unambiguous for courts and lawyers. Explicit…

License bikeshedding is fun, so please indulge me. People dislike apache because it's complicated and requires annoying notices on distribution of modified versions. Debian and fsf say it's free. OpenBSD believes the patent provisions are non-free and refuses to include apache licensed software. I think a project is better off having non-trivial contributers sign explicit license grants, even you admit that explicit…

I don't understand how the OpenBSD project defines "free", so I can't usefully comment on how they consider the Apache license "non-free".

It sounds from https://softwareengineering.stackexchange.com/questions/2632... like they are reading the existence of an explicit patent clause in the Apache license (regardless of what that clause is!) as an "additional restriction". I want to know whether they believe the MIT license has a patent grant, and if not, what they think "Permission to use" means.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#69

Post by platz »

runeks wrote: post #51
platz wrote: post #3

I continue to be believe even as a static typing fan that static types are fundamentally incompatible with OTP and it's goals. Distributed systems just seem to too thorny for static types to subjugate/bend to their will. Sure, you can declare global invariants ahead of time that your cluster must uphold, but it's a bit less "distributed" in a real sense then

> Distributed systems just seem to too thorny for static types to subjugate/bend to their will. The more I've learned to leverage types, the more I realize that it's my limited knowledge of type systems that prevents me from expressing something in it. Types do not bend to the will of programs; programs bend to the will of types (in statically typed languages). > Sure, you can declare global invariants ahead of time…

> What prevents the implementation of these protocols from leveraging type safety

Global invariants of a running distributed system are different than local invariants in a single program that you can stop, deploy re-compiled binaries to, and then start again.

Now, you can use static types in actor systems, and they are some of these that exist. These typed actor systems don't do all the same things that erlang/OTP does (that may be ok - maybe you don't need them). If your use case fits into what the typed actor systems actor systems provide, by all means, one of those are probably a better fit for you.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#70

Post by bluejekyll »

unrealhoang wrote: post #45
spraak wrote: post #22

Earlier quoted context omitted.

I'd love to have something that takes the best of Go (static typing, fast compiles, binaries, community) and functional paradigm.

How about Rust, no fast compile though.

With

  cargo check
It's significantly faster than before for type checking etc during development, which is I assume the point at which most people complain about compile speeds.
Post reply on HN