5 ms·

Trying to put together cowboy, poolboy, a circuit breaker, a database driver, erlydtl, and various and sundry other pieces, for someone not well versed in Erlan

Trying to put together cowboy, poolboy, a circuit breaker, a database driver, erlydtl, and various and sundry other pieces, for someone not well versed in Erlang is a losing proposition. How so? A framework can very much be (and often is) a reductionist endeavor: the sum of its parts connected by entry points. Particularly ones that are loosely coupled, as the one you alluded to (Chicago Boss) is If someone is not well versed in Erlang, they should probably learn Erlang before starting a project in it. Chicago Boss still makes implicit much of OTP, the process model and records that it's easy for beginners to jump in, though. Their friend, using Elixir, will at least have something up and running in short order. Once again, this is just as applicable to Erlang. A package management system, “hex”. Do people even know why they want/need a hundred language-specific package managers anymore, or is it just a cargo cult thing to do? No, a module system, a dependency resolver (Rebar) and release management may push you out of your comfort zone a bit compared to the typical do-everything package manager blob, but it's very much doable. Ecto database driver, with Postgres as the first database integrated (yay!). Ecto looks more like ActiveRecord, but there's nothing particularly wrong with BossDB. The fact that BossRecords are serialized as proplists means you can perform relatively complicated operations by using list comprehensions alone. Oh, but you have to learn some Erlang. No avoiding that. Ecto migrations. I might grant that. BossDB migrations aren't particularly advanced. Not sure how well Ecto fairs in to it. Porcelain, for working with external processes, where Erlang is somewhat lacking https://github.com/msantos/alcove https://github.com/msantos/alcove https://github.com/msantos/perc https://github.com/msantos/perc Latter is old, but the point remains. Port drivers and NIFs can easily bridge the gap from the Erlang VM to the host OS, and it seems that Porcelain uses exactly the former, at least.

davidw 12y ago
> BossDB migrations aren't particularly advanced. No, they aren't, they were "the simplest thing that possibly worked" for my needs (I wrote that code). One problem with boss_db is that it uses some heavy duty compiler magic that none of the "pure Erlang" kinds of folks really want to touch because it produces un-Erlangy code. This leaves it in a no-man's land: the Erlang people don't want to deal with it, and the people coming in from Ruby or whatever are just going to go straight to Elixir which looks more familiar anyway.
- vezzy-fnord 12y ago
  The implication here being that the Ruby folks mostly care about surface convenience, with not even using parser transforms to provide parameterized modules (remember, one of the reasons people laud Elixir so much is its metaprogramming support) to overload the language a bit and provide ActiveRecord-like patterns being enough. It's not really an indictment on Erlang, though. The situation you present is unwinnable.
- rambocoder 12y ago
  IMHO when Ericsson decided to remove "experimental pmods" support from Erlang in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a liability. Ericsson's development team did release a workaround example, but the whole process how this went down left a sour taste in my mouth. My wish is that Ericsson's Erlang development team became more transparent to the outside world, shared their bug tracker, code reviews (Go team does this wonderfully) and did all development in the open. Then we would not have these situations https://github.com/erlang/otp/pull/687 https://github.com/erlang/otp/pull/687 and it would save me ton of time couple years ago chasing after ssl bugs.
  - davidw 12y ago
    > when Ericsson decided to remove "experimental pmods" support from Erlang in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a liability. It caused a bit of hassle, but not much, really. It was a feature that many Erlang people did not like much in the first place, so heavy use of it put them off to begin with.
    - rambocoder 12y ago
      I agree with you that it wasn't that much of a hassle technically, just wish that the announcement was done with more transparency instead of "OTP Technical Board" met somewhere and this is what was decided http://erlang.org/pipermail/erlang-questions/2012-October/069720.html http://erlang.org/pipermail/erlang-questions/2012-October/06... Reminds me of Microsoft's .NET development process from 10 years ago, huge corporation drives development of a platform behind closed doors with very few people from the outside having any idea what is coming in the future.
angersock 12y ago
Hex is awesome, and easy to work with. Any language nowadays that doesn't have a package manager has kinda already lost as far as practical development goes. It's nice to see Erlang folks adopting Hex in places.

davidw 12y ago

> BossDB migrations aren't particularly advanced. No, they aren't, they were "the simplest thing that possibly worked" for my needs (I wrote that code). One problem with boss_db is that it uses some heavy duty compiler magic that none of the "pure Erlang" kinds of folks really want to touch because it produces un-Erlangy code. This leaves it in a no-man's land: the Erlang people don't want to deal with it, and the people coming in from Ruby or whatever are just going to go straight to Elixir which looks more familiar anyway.

vezzy-fnord 12y ago
The implication here being that the Ruby folks mostly care about surface convenience, with not even using parser transforms to provide parameterized modules (remember, one of the reasons people laud Elixir so much is its metaprogramming support) to overload the language a bit and provide ActiveRecord-like patterns being enough. It's not really an indictment on Erlang, though. The situation you present is unwinnable.
rambocoder 12y ago
IMHO when Ericsson decided to remove "experimental pmods" support from Erlang in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a liability. Ericsson's development team did release a workaround example, but the whole process how this went down left a sour taste in my mouth. My wish is that Ericsson's Erlang development team became more transparent to the outside world, shared their bug tracker, code reviews (Go team does this wonderfully) and did all development in the open. Then we would not have these situations https://github.com/erlang/otp/pull/687 https://github.com/erlang/otp/pull/687 and it would save me ton of time couple years ago chasing after ssl bugs.
- davidw 12y ago
  > when Ericsson decided to remove "experimental pmods" support from Erlang in version 16, the compiler magic in ChicagoBoss turned from "oh cool" into a liability. It caused a bit of hassle, but not much, really. It was a feature that many Erlang people did not like much in the first place, so heavy use of it put them off to begin with.
  - rambocoder 12y ago
    I agree with you that it wasn't that much of a hassle technically, just wish that the announcement was done with more transparency instead of "OTP Technical Board" met somewhere and this is what was decided http://erlang.org/pipermail/erlang-questions/2012-October/069720.html http://erlang.org/pipermail/erlang-questions/2012-October/06... Reminds me of Microsoft's .NET development process from 10 years ago, huge corporation drives development of a platform behind closed doors with very few people from the outside having any idea what is coming in the future.

angersock 12y ago

Hex is awesome, and easy to work with. Any language nowadays that doesn't have a package manager has kinda already lost as far as practical development goes. It's nice to see Erlang folks adopting Hex in places.