Earlier quoted context omitted.
Rust is a community of very nice and helpful people, much like Elixir but with more money behind it. However, I certainly enjoy Elixir's unwillingness to break working code with every release, or to force users to build against nightly releases just to use any features from the last year. Rust is improving in this regard, but isn't quite there yet.
What stuff are you running into with this? The vast majority of the ecosystem is on stable, but there are some holdouts. Working on them! I always like to hear people’s pain points, it helps with prioritization.
Elixir at PagerDuty
61–70 of 190 posts
Re: Elixir at PagerDuty
#62Earlier quoted context omitted.
What stuff are you running into with this? The vast majority of the ecosystem is on stable, but there are some holdouts. Working on them! I always like to hear people’s pain points, it helps with prioritization.
I'm just a dabbler and most of my experience is a few months old -- I have no specifics for you, I'm afraid.
I'll also add that I've actually been really impressed with how much attention Rust takes to not break stable packages. Between crater[1] and how aggressively they've cut point releases to fix any issues that (rarely) happen to slip by.
Re: Elixir at PagerDuty
#63Earlier quoted context omitted.
Type coercion does not equal weak typing -- I submit JS and Perl as examples where types are strong but there is a coercion protocol dependent on which types an operator expects around it.
Fair, C may have been a better example. Where nearly everything is actually just a block of bytes of various lengths and can be intermingled fairly freely with minimal effort to get anything past the compiler. Sometimes useful, but the type system ends up offering few meaningful protections as a consequence.
However, C does allow you to write code that can not proven to be legal with respect to the formal system of the language and get it to compile, I think that is what you are referring to.
But just because you can write an invalid program does not mean the type system doesn't exist or is flawed. I can also write an invalid Haskell program.
The difference between these two would be that the haskell program can be proven to contain only operations that map to well-defined operations in the formal language model by an automated process, while the same can not be done for C in the general case.
However, just because you can not always prove conformance to a formal model using automated means, doesn't mean that no formal model exists (because it does!).
Re: Elixir at PagerDuty
#64I wonder about a language like Elixir in the age of serverless. Erlang will always be great at the use-case it was originally written for (and what Whats App uses it for), but that's not the scale that most startups operate in. With serverless the advantages that Erlang has don't matter much, since the process doesn't live along to utilize them. Instead the bottleneck is cold start times. So these types of languages…
You do realize that outside of cloud providers hype "serverless" is a tiny fraction of cloud use let alone overall use.
Re: Elixir at PagerDuty
#65Earlier quoted context omitted.
Just some random background for those reading about why Erlang/Elixir Rust interop is A Big Thing. The whole point of Erlang and Elixir is robustness in the face of high concurrency. All other design choices (eg functional programming, immutable data), follow from that goal. Core is that if one green thread ("process" in Erl/Ex lingo) crashes for whatever reason, the rest keep on running. Interop with native code is…
Or you can just make a remote node out of your C/Java/Rust/whatever code and not worry too much about it crashing your Erlang system. It's not just crashing either, it's taking a long time to execute a given function in the native code - that can also cause problems for the Erlang system running it.
Re: Elixir at PagerDuty
#66As an Erlang developer for the past couple years now, I love seeing the adoption and excitement around Elixir and the BEAM. I will admit I always shudder when people very quickly call out on Erlang's syntax as a reason not to use it. Feels like a pretty lame excuse... All that said however, it kind of bugs me when I see posts like this (no matter the language) that go somewhere along the lines of "I managed to introd…
Your first comment is kind of funny, because while Elixir's syntax may appear more "esthetic", I find Erlang's way more consistent and logical.
Re: Elixir at PagerDuty
#67Earlier quoted context omitted.
You do realize that outside of cloud providers hype "serverless" is a tiny fraction of cloud use let alone overall use.
Some times hype is warranted. Get passed it and look at the actual technology and its value. If you are building a website in 2018 you are doing yourself a disservice manually managing servers.
Re: Elixir at PagerDuty
#68My impression about the Elixir/Erlang so far has been the same. > Elixir comes with one of the nicest and most helpful communities around Using Elixir, it's easy to write gorgeous code, with a language that for the most part is really minimalist, and you get to play with the great piece of software that OTP is without all the warts of Erlang (which is mostly the developer experience). The BEAM community is fantastic…
I still don't quite understand what makes Rust community this way, but it's one of the best things about the language.
Re: Elixir at PagerDuty
#69Earlier quoted context omitted.
Rust is a community of very nice and helpful people, much like Elixir but with more money behind it. However, I certainly enjoy Elixir's unwillingness to break working code with every release, or to force users to build against nightly releases just to use any features from the last year. Rust is improving in this regard, but isn't quite there yet.
What stuff are you running into with this? The vast majority of the ecosystem is on stable, but there are some holdouts. Working on them! I always like to hear people’s pain points, it helps with prioritization.
Re: Elixir at PagerDuty
#70Earlier quoted context omitted.
Rust is a community of very nice and helpful people, much like Elixir but with more money behind it. However, I certainly enjoy Elixir's unwillingness to break working code with every release, or to force users to build against nightly releases just to use any features from the last year. Rust is improving in this regard, but isn't quite there yet.
What stuff are you running into with this? The vast majority of the ecosystem is on stable, but there are some holdouts. Working on them! I always like to hear people’s pain points, it helps with prioritization.
Also, while I recognize it's a third party project, the hyper API keeps changing faster than I can adapt my code. If you are aware of a more stable HTTP server, ideally one that has proper TLS support and support for unix domain sockets, I would be very interested.
EDIT: on the other hand, after working with rust daily for ~1.5 years, I have only run into one compiler bug and had zero actual bugs in my application due to language/compiler updates so far. There have been a few occasions were essential features were missing from the standard library/language though and several times were we had to backport some code to an older, stable rust version that we're one (when a developer had mistakenly tested their code locally with a newer version).
The highest up on my wish list would be that - as I understand it - you can not currently exit the process cleanly (EDIT: early) with a non-zero exit code in stable rust. That makes it pretty hard to implement good command line utilities. Happy to be corrected if I am wrong on this one though.