Earlier quoted context omitted.
> Scary news from Vue Do you have a link?
He's most likely referring to: https://news.ycombinator.com/item?id=20237568 Which is a bunch of FUD (see top comment by EvanYou).
Thanks
Elixir 1.9
131–140 of 174 posts
Re: Elixir 1.9
#132If anyone is on the fence on learning Elixir / Phoenix (Elixir's most popular web framework library) please do yourself a favor and give it a shot. If you're on a time crunch and want the best bang for your buck on "why bother learning yet another language to write web apps in?" then watch this talk called "The Soul of Erlang and Elixir": https://www.youtube.com/watch?v=JvBT4XBdoUE I'm not affiliated with the languag…
The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise or Django. The framework authors refuse to ship a first party implementation and instead leave it to the community. Problem is, the ones available are mostly extremely low level (ueberauth, guardian etc.) and you have to spend ages customizing it. On Rails it's literally two commands to set up user registration, email confirmation, password reset. Despite its supposed Rails roots, Phoenix has a long way to go (the greater irony is that the company behind Devise, Platformatec, is also the company behind Elixir).
If you only need basic functionality and absolutely have to use Phoenix, Pow is a good choice:
Re: Elixir 1.9
#133Earlier quoted context omitted.
The thing is, nowadays, statically typed languages became so ergonomic, there is really no reason to go with dynamic languages.
Erlang’s Dialyzer (and the related Elixir project Dialyxer) provide compile-time type safety analysis. It’s optional and only at compile time, but immensely helpful in verifying correctness.
Worth noting that Elixir Language Server will also hook into your text editor/IDE and provide warnings every time you save a file (it compiles the code behind the scenes).
Re: Elixir 1.9
#134Earlier quoted context omitted.
The thing is, nowadays, statically typed languages became so ergonomic, there is really no reason to go with dynamic languages.
Erlang’s Dialyzer (and the related Elixir project Dialyxer) provide compile-time type safety analysis. It’s optional and only at compile time, but immensely helpful in verifying correctness.
I also highly recommend the dialyzex [0] project as well. While it's not going to match every feature of some type systems, it does a much better job than one might expect.
It's always a little frustrating that folks pass on Erlang or Elixir as entirely dynamic. It's a lot closer to what you find in gradually typed languages if you take advantage of the tools available.
[0]: I know there are a few of these elixir projects, though I am not familiar with the parent's. Perhaps it's a typo?
Re: Elixir 1.9
#135Fantastic. Congratulations to the Elixir team! Something striking from the release announcement: > As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned. Part of me is a little alarmed—no one wants a language to stagnate. José makes it clear that this doesn't mean it's the last version: > Of course, it does not mean that v1.9 is th…
"no one wants a language to stagnate" In the sense of the language itself, I do. The language community should keep growing, libraries, frameworks, etc., but I'd like to see more languages qua languages declare themselves "done" sooner and more often, or failing a sudden cutoff, start seriously raising the bar on the next "new feature". There's a lot of good languages out there that were great in years 5-15 and then…
Programming languages are software products, when they are done, it is time to move on.
Re: Elixir 1.9
#136Earlier quoted context omitted.
"no one wants a language ecosystem to stagnate" I used to be so happy when there was a new Java version every year, something new is good, something better is good, some hype is good. Now I am getting old I just want to use the same tools for the next 15 years. I mean it is not like most of the problem we are trying to solves were limited by the languages itself. ( Mostly the ecosystem around it )
A difference with Java is that new Java releases tend to come with changes to the JVM. The language's semantics and the abstract machine are intertwined in a way where the JVM might be changed to enable a new language feature, or vice-versa. And the JVM itself improving is pretty much always an unalloyed good, so people tend to look forward to releases of Java to see what JVM improvements it has in store. Elixir does…
Unless you are using Android J++, then you get some Java features at the expense of de-sugaring.
Re: Elixir 1.9
#137Earlier quoted context omitted.
The thing is, nowadays, statically typed languages became so ergonomic, there is really no reason to go with dynamic languages.
Erlang’s Dialyzer (and the related Elixir project Dialyxer) provide compile-time type safety analysis. It’s optional and only at compile time, but immensely helpful in verifying correctness.
dialyzer is terrible and doesn't actually work in practice, as is evidenced by the many dialyzer errors that slip through to current releases on hex of libraries even the size of Phoenix, StreamData, etc.... Even the major community members don't use it. It's not a substitute for a type system and especially not one that allows you to properly model things in it.
Re: Elixir 1.9
#138Earlier quoted context omitted.
The thing is, nowadays, statically typed languages became so ergonomic, there is really no reason to go with dynamic languages.
Most people who point to Elixir's lack of static typing as a weakness, or believe their productivity would be adversely affected by it, do so because they haven't actually used the language. Anyways, this subject occasionally comes up for discussion in the community. This post sums up my thoughts fairly well: https://elixirforum.com/t/static-vs-dynamic-typing/9824/3
It's a near certainty that I've written an order of magnitude more elixir code than you have and I can say without a shadow of a doubt that elixir's lack of static typing definitely makes it less useful.
Even if you disregard the modeling power that you can get from this there is an upper bound on any elixir project after which any work on it becomes less and less easy to do, as with all languages that lack a static type system. We write assertive elixir code as much as we can, but that doesn't mean that you can actually guarantee anything about a code path that is less traveled.
dialyzer is also not the answer. Oftentimes we'll find ourselves in a situation where dialyzer complains because someone who made a major library simply doesn't use dialyzer. You might wonder why they don't in that case, because it would pick this particular issue up very easily, but the next time you run into some garbage error that dialyzer spat out that you are instantly reminded that you can neither trust it to be correct or safe, so people turn it off.
Elixir has upsides: I think it's solidly the best language for creating servers of different kinds, but it's near useless after you pass a fairly short distance with it. I would absolutely never, in my personal endeavors (as opposed to my working contract) write an elixir server that actually tries to do anything meaningful itself other than just route messages to other servers.
Re: Elixir 1.9
#139Earlier quoted context omitted.
The thing is, nowadays, statically typed languages became so ergonomic, there is really no reason to go with dynamic languages.
I partially agree, but none have the preemptive green threads of the BEAM VM and its amazing tooling around supervisors and worker hierarchies. Trust me, if somebody puts that in Go, Rust or OCaml -- I'd ditch Elixir tomorrow. The BEAM VM is just too good. You can have thousands of smaller tasks running in parallel and nothing lags until you hit the physical limits of the hardware -- which 99% of the apps never do.
I think this is right on point. The BEAM is finely tuned for a specific problem and it solves it beautifully in a way that is extremely hard to replicate unless you actually are willing to invest in some kind of run time (which instantly makes you ineligible for consideration in a lot of peoples' minds). Every language that has tried, as far as I know, has done so as an afterthought and obviously does not end up replicating the important parts.
Knowing that, it's perhaps more pertinent to talk about what you can actually bring to that VM. Alpaca [0] could potentially be the solution. Interoperation with the rest of the VM languages and static typing on top of that. I have no doubt that most of the community would simply not use it, because they don't care about static typing, but I have zero reservations about saying it would be a better way to write code for the BEAM in the future.
Without something like that, it's unlikely that I will actually put any code that does more than something like routing messages to other services or the like on the BEAM in the future. Beyond a fairly low number of lines I simply don't trust anyone to write code that does exactly what they think it will do and no more in a dynamically typed language.
Re: Elixir 1.9
#140Earlier quoted context omitted.
You could run PG in either WSL or a Docker container. I currently use Windows (where I spend 99% of my time in WSL) and everything runs great.
Maybe somebody else knows where to wave the dead chicken to make postgres under WSL work well, but my last two tries (Feb 2018, Nov 2018) suggested that trying to do so invites lots of yak-shaving, pain, and poor performance. And that's just using the package manager to install, if you want to build from source, it may not work at all. Stories to the contrary and hints how to make it work are welcome.
Might be worth retesting, we did some changes to PG to handle the unsupported syscalls more gracefully (warn once, and then not anymore) in a recent set of minor releases.