bitwalker

I build releases with distillery and deploy them with Docker, the combination has worked really nicely for my projects.

Disclaimer: I'm the author of exrm and distillery, so I'm probably biased.

As far as I'm aware support for this is still not implemented in Elixir, I'm assuming the implementation would match Erlang, but as shown here, it doesn't necessarily have to. Personally I'm of the opinion that functions like this are better written as named functions, but the one place this is awkward is in iex, where you can't define named functions at the top level, so it has it's place.

That's what initially attracted me to Elixir instead of Erlang, though the tooling has definitely improved in Erlang with the introduction of rebar3. The integration of testing and documentation (i.e. doctests) is still better than any other language I've worked with. The documentation generator (ex_doc) is excellent too.

I'm not sure who told you that, but it's patently false. Phoenix is just another OTP application, you can build a Phoenix app without knowing Erlang at all. It is a practical reality that you will eventually dig into Erlang to some degree, but I wouldn't say it's a requirement by any means. Perhaps what was meant is that you will need to understand OTP, the Erlang standard library (because Elixir avoids wrapping it as much as possible), and some of the semantics of Erlang interop such as the binaries vs charlists, the use of records instead of structs, etc. For just getting started though, much of that can be avoided, and you can tackle it as the need arises.

My apps are handling events from devices, a great many of them, probably ~1k/sec. That said, it could certainly depend on the app.

I run several erlang/elixir applications in containers, it works just fine. I'm not sure why someone claimed it doesn't, but I suspect they didn't try very hard if they did have trouble.

In my experience code examples as documentation are far more common than actual documentation (e.g. guides, user manuals), but perhaps I just haven't worked in a language where the opposite is true.

My experience in the military was that phased inspections on fighter aircraft was done every N flight hours, not based on a fixed amount of time, I would assume helicopters are the same, but I was under the impression that helicopters required more maintenance, not less, due to the increased mechanical complexity, but I never got to work on those, so I really have no idea.

The fear about macros in Elixir itself seems a little overblown. Most macros are consumed in the same way you would consume functions or keywords in another language (e.g. defmodule/def/defp/if/unless/etc.). The only one that I can think of that can be problematic is `use`, which is more of a problem with third-party libs where someone might do a lot of "magic", but in general is mostly used to do things like import functions, alias modules, etc. The concern about macro abuse is certainly valid, but I don't feel like it's at all a problem with the core language, but rather abuse by people who feel the need to use macros for things which do not require macros. In addition, macro usage in Elixir is always explicit - you must import/use macros at the top of a module, and the implementation of those macros is easy to find by going to that module definition. It's not nearly as dangerous as say, monkey-patching in Ruby.

In any case, just wanted to chime in with my two-cents. I've been working in Elixir for the last couple of years and have never felt like I've been bitten by macros. Elixir is certainly a bigger language than Erlang, but many of the things Elixir adds on top of Erlang are what make it so pleasant to work with. For example, the reduction in boilerplate for gen_servers which is made possible with `use GenServer` in Elixir.

Just to add another datapoint, I'm also in MSP, and I'd say ~120k is where I'd value myself as well, though I ended up taking less than that for my current gig because I wanted to work with Erlang (amongst other things), and it was an opportunity to do so. I'd +1 everything you said.

UTC is intrinsically linked to leap seconds, that's why it's called Coordinated Universal Time, because it's coordinated to shifts in the solar year using leap seconds. I do think everyone using UTC + an offset would be a great switch though.

Most everyone thinks of noon in terms of solar noon - they just don't know it. Solar noon is when the sun is at it's highest point in the sky for a given location. So their point was that noon would no longer be aligned with that intuition.

F#/OCaml too, probably all the ML variants actually.

I mentioned this elsewhere in this thread, but abbreviations are not unique across timezones. The rules for timezones change based on locale, and if you have multiple zones with PST as an abbreviation, which one do you use? It has to be an explicit choice or it's almost certainly going to be wrong. There is no way to get America/Los_Angeles from PST without knowing the locale that the date and time is from.

Abbreviations are reused in different locales. PST in one locale can have different rules than PST in another locale. The reason the fully qualified name is needed is because it uniquely identifies a locale for which timezone rules can be followed.

Offsets aren't always the right thing to use either. If you are in America/Chicago and use -0600 for your timezone, that's only accurate during standard time, and is off by an hour for daylight savings time. Knowing how/when to shift offsets is part of the timezone rules associated with a locale, because they are not constant historically.

LFE is not a "LISP-wrapper around Erlang", it's a LISP that compiles to BEAM bytecode, just like Erlang compiles to BEAM bytecode.

I'd agree, it seems like an almost primal comparison, rather than something deliberately conceived. The way some places in the books are described take that quite literally: Rivendell, the bastion of good, is described in terms of safety and light (even at night, with the moonlight), and Mordor, the bastion of evil, is described in terms of danger and darkness.

I'd agree up to a point, but if I read something where early on there is an obviously biased and/or incorrect series of statements being made, it's not much of a stretch to assume the rest of the content will share that trait. Still, it doesn't necessarily mean they won't make some decent points regardless, but it makes it all too easy to dismiss an argument when it's formed that way. I'm not sure I'd call it "looking for an excuse to be dismissive", as much as "not giving the author a chance to redeem their argument in spite of obvious weaknesses".

You know, I had never noticed how the Neimodians in Episode 1 spoke in that Asian-stereotyped speech pattern before, but now I can't unhear it when I think of their scenes from that movie. Seems obvious in retrospect.

As a counterpoint: Saruman the White and his horde of orcs were about as evil as they come, there were evil humans of both light and dark skin, and that applies to many of the "good" races. That said, yes, the evil parties tended to be of dark complexion, but I think of that as less a racial undertone, and more likely a literal illustration of the classic good == light, evil == dark parallel (for instance, Sauron being called the "Dark Lord", many references to "the darkness", etc.). Who knows though, perhaps Tolkein was racist, I just never felt that his writings came across that way.

In my opinion they are two words for the same thing: Someone who builds software.

The word programmer refers to the literal act of writing the code, while to me the word developer implies writing the code, but also all the other "software engineering" aspects of developing software. If you wanted to be technical, you could say a programmer just codes, while a developer codes but also determines requirements, develops a specification/scope, etc.

I refer to myself with both interchangeably, and I assume most others do as well. I really don't consider them to be different in any meaningful way.

While I agree with you, Erlang for instance has collections as primitives (lists/tuples), but then offers more complex collections (such as gb_tree) as part of the stdlib.

I agree with most of this, but I don't agree that the lead should only care about inputs/outputs when it comes to a task a given dev is working on. A lead should have defined conventions for how code in the project is written, and I think it's absolutely reasonable for that to be part of handing off a task to a junior. My approach is usually something like: "Ok Paul, I'm going to have you build out feature X, Y, and Z, defined in ticket #s 1,3, and 5, see the README about coding conventions, and let me know if you need more context/detail on any of these. I'll swing by each morning for a few minutes to see how things are going"). Then beyond talking to each team member every day, we have standups to keep everyone on the same page, on whatever interval makes sense given the complexity of the project.

I think a lead should care about how their team is implementing the features they are working on, because as the lead, it's crucial that you know the ins and outs of the system - where I think we agree though is that a lead shouldn't care about how the work is done, as long as it's done within the project guidelines (coding style, consistent structure, testing, etc.).

I think the lead should be setting up source control, the dev/staging environment, deciding on the frameworks used (for the big stuff at least), and defining the architecture and code style for the project, and last but not least, they should break up the project into major features, and individual modules/components/tasks. As far as the last bit goes, the level of detail I shoot for is something like this (given a fabricated web app as the software being developed):

Feature: User can register an account

Tasks:

  - Registration page markup/styles

  - Registration page JavaScript (form validation/submission)

  - Registration API endpoint (validate properties, ensure user doesn't already exist, persist user model, send email confirmation).

Prerequisites:

  - Data access layer implementation

  - User model

  - App layout markup/styles

  - Email service implementation

I agree with the lead setting up the initial project skeleton, but I'd take it one step farther and say the lead should also document the conventions for adding new modules/etc, so that the structure doesn't start to fall apart once the lead stops being the one managing it day to day.

I'd say there is plenty of interest in a cross-platform Visual Studio. It's hands down the best IDE I've ever used, and if it was available on OSX you can bet I'd use it. That said, since VS is not in fact cross-platform, some VS-specific feature obviously doesn't apply to those developers who don't run Windows.

Personally, I do C# development in a Windows VM, everything else in OSX. With the new vNext stuff, the only thing still binding me to Windows for anything is the lack of Visual Studio (and WPF). I wouldn't be surprised to see an effort made to bring it to a larger audience now that .NET is going cross-platform.

As an aside, this reference makes me happy. The Phantom Tollbooth was one of my favorite books when I was younger, just brilliantly written. So many good lessons about life (the Humbug being a great example). Another great one that is somewhat applicable here is Canby, the regular visitor to the Island of Conclusions, who attempts to be as much as he can be of all things (hence his name), which leaves him not very much like any of them, instead of picking one thing and mastering it.

No word on how the site was compromised yet, but jQuery's administrators are already working on addressing the issue.

Also sounds like jQuery itself was not modified in any way, only the malware dropper itself being inserted in jQuery.com's markup. Not sure what the impact will be, or what browsers and the like are affected - hopefully the impact is relatively limited.

It's in the nature of developers to care about API design, which is really what this is about. Would you want someone to design an API for your software product that does so as haphazardly as the PHP standard library was designed? Probably not. It's only natural that people want to discuss why it's bad and how it could be fixed. I would be more concerned if you were a developer and didn't care about these kind of issues.

Definitely good points. Your first is one of those really small, but also really annoying things about Erlang. I spend a lot more time with Elixir than Erlang, and while the first one is addressed, and the the second one is mostly covered, printing is still a pain point for people new to the language. Once you understand the caveats, it becomes a non-issue, but it's certainly frustrating for new users of both languages.

> * Go has a great, consistent, modern, bug-free standard library. Erlang - not so much.

Erlang has one of the most battle-tested standard libraries around. OTP is rock solid. It may not be bug free (I don't know that any language can claim a bug free standard library), but it's damn close.

It's pretty obvious you haven't spent much time at all with Erlang based on your points here:

- Claiming "X is fast, Y isn't" is not even an argument, you should've just left that out.

- Arguments about syntax are rather pointless, but Erlang has very consistent syntax, and it's small. You can pick up Erlang in a couple of hours if you are familiar with FP concepts.

- I haven't encountered any real problems working with strings in Erlang. It may not have a bunch of standard library functions for manipulating them, but it's pretty trivial to do most things you would in any other language. It makes up for it with how much of a breeze it is to work with binary data.

- As mentioned previously, structs aren't datastructures, and Erlang has an equivalent (records) for those anyway. Erlang has trees, maps, tuples, lists - I would consider those a lot more obvious and necessary.

- Erlang and Go are both general purpose programming languages. They don't share the same design goals though. You could write a Go program to do a poor approximation of what Erlang is good at, and vice versa, the point though is to use the proper tool depending on the application. I don't know where you got the idea that fault tolerance isn't important for "90% of software", but the software I work on certainly requires it.

- Your argument about shared memory makes it clear you haven't actually used Erlang. The copying of values between processes is abstracted away from you entirely, there simply is no awkwardness. Perhaps there is in Go.

You are claiming the article is biased, but your post is riddled with it. There are certainly problems with Erlang, but none of the things you list are one of them (except perhaps strings).