41–50 of 57 posts
Earlier quoted context omitted.
Elchemy creator here. Quite the opposite to be honest. I come from Elixir background. It's just that npm is much more reliable when it comes to global system-wide installations
Are you saying Mix/Hex is unreliable or are you saying npm is on more machines globally?
Or if you’d rather have typeclasses: https://github.com/purerl/purescript
Purescript by example[1] is the most approachable introduction to Functional programming that I have seen (yet). Even if you don't intend to ever use Purescript itself for application development, the book is worth a read, as an introduction to FP concepts, especially if you are coming from a Javascript/Web-dev background. [1] https://leanpub.com/purescript/read
Love the concept. But please don't use fonts with ligatures in code snippets on the homepage. Especially when these code examples are actually screenshots which people can't copy. Ligatures may be "obvious" to developers already familiar with the syntax of the language, but can make things very confusing for beginners, esp. in FP languages that lean heavily on operators etc. I am really glad that the docs/roadmap etc…
Meh. You can reasonably expect someone interested in this project would have at least some passing understanding of functional programming, if not the niche of programming Elm and Elixir are trying to fill. In which case arrows and lambdas should be fine. Even if you're a C++ developer, you've seen arrows drawn in some capacity, I can't imagine what confusion using an arrow could possibly cause.
1. What’s the genesis of this project?
2. Do you use it internally, is it backed by any company?
3. Is it already handling some production code?
Thanks!
Earlier quoted context omitted.
Meh. You can reasonably expect someone interested in this project would have at least some passing understanding of functional programming, if not the niche of programming Elm and Elixir are trying to fill. In which case arrows and lambdas should be fine. Even if you're a C++ developer, you've seen arrows drawn in some capacity, I can't imagine what confusion using an arrow could possibly cause.
The confusion, which may not apply for a savvy developer, would arise from somehow believing that the unicode arrow (→) is being used and not the hyphen-greater-than-sign (->) arrow.
Why would this target Elixir instead of Erlang or BEAM byte code directly? Putting a language on top of a language on top of a language does not seem that smart to me.
beautiful ... ? readable ... ?
neither ... yes
Or if you’d rather have typeclasses: https://github.com/purerl/purescript
Purescript by example[1] is the most approachable introduction to Functional programming that I have seen (yet). Even if you don't intend to ever use Purescript itself for application development, the book is worth a read, as an introduction to FP concepts, especially if you are coming from a Javascript/Web-dev background. [1] https://leanpub.com/purescript/read
As someone who writes Erlang for a living, I highly recommend rust as a well typed alternative to Erlang, that still keeps all of the things that make Erlang great. I do love Erlang, but working on a large codebase can be frustrating when nothing is speced or commented, and even when it is speced it’s usually part of a gradually typed codebase with very non descriptive types.
Same feeling here. I used to work in Erlang on daily basis - now Elixir. And although I'm not a big fan of its syntax (Erlang looks more readable to me) the tooling and the amount of love from Elixir's community is immense I've never had a chance to play with Rust yet. I'll definitely give it a shot someday In my opinion, the best example of how typed languages make it more manageable is Elchemy's codebase itself - w…
The comparison of Rust with Elm and F# in this article really clicked for me:
https://www.chriskrycho.com/2018/exploring-4-languages-start...
I always thought of Rust as similar to Go, but now I think more of it like an ML descendant with C'ish syntax. There's more to it though, Rust is more low-level than languages in the ML family and can often provide the same abstractions without hight costs in performance.