Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir at PagerDuty

pagerduty.com

Post reply on HN
Print view View original

161–170 of 190 posts

Re: Elixir at PagerDuty

#161

Post by mononcqc »

dqv wrote: post #123
dxhdr wrote: post #96

Earlier quoted context omitted.

> This topic is quite subjective, but could you provide some example? Elixir's pin operator is a good example of unnecessary complexity.

I'm okay with this trade off instead of having to do Variable0, Variable1, ..., VariableN. It would be cool to have an option to turn off rebinding for those who don't want it (and then not requiring the pin).

Elixir already has those rebindable variable, which can be "turned off" by using the ^ prefix on a match variable. Wouldn't that make the |> less useful to you already?

Re: Elixir at PagerDuty

#162

Post by AzzieElbab »

jvican wrote: post #125
AzzieElbab wrote: post #94

Earlier quoted context omitted.

> This is simply not true. First, there is no Haskell influence on the language. Since Scala has no build-in way to define FP constructs(monads, functors.. ), cats and scalaz are practically inseparable from the language itself when you try to go beyond the basics in FP. So, it is very easy to see where all the confusion is coming from

Lisp doesn't have any way to define those FP constructs and it's one of the first functional programming languages ever. I think you're being misled by Haskell.

I can't argue about Lisp. For better or worse scala fp programmers are more inspired by Haskell. Scalaz was basically an attempt to port all of Haskell to Scala, 1 to 1

Re: Elixir at PagerDuty

#163

Post by crad »

pera wrote: post #144
mmartinson wrote: post #132

Earlier quoted context omitted.

Ya I get the sense the Erlang example is written a bad faith a little.

Not my intention at all, please feel free to rewrite it: I don't know much Erlang and I actually copied that code from Rosetta Code.

Apples to apples? I don't do Elixir but this is what I think it's doing:

io:fwrite(string:join(string:tokens("Hello,How,Are,You,Today",","),".")).

Re: Elixir at PagerDuty

#164

Post by OvermindDL1 »

dqv wrote: post #123
dxhdr wrote: post #96

Earlier quoted context omitted.

> This topic is quite subjective, but could you provide some example? Elixir's pin operator is a good example of unnecessary complexity.

I'm okay with this trade off instead of having to do Variable0, Variable1, ..., VariableN. It would be cool to have an option to turn off rebinding for those who don't want it (and then not requiring the pin).

`|>` would replace the great majority of need for multi-staged named variables.

In addition, naming variables like that in Erlang is a mis-design, the names should be more descriptive.

Re: Elixir at PagerDuty

#165

Post by OvermindDL1 »

dnautics wrote: post #153
mmartinson wrote: post #133

Earlier quoted context omitted.

I think I would also prefer there to be no reminding. On the topic of the pin operator though, it seems more clear to me that it's an assertive component of a match, rather than needing to reference all variables in a scope in the case where there was no rebinding, to determine if something matching has already been assigned.

A buddy of mine and I were talking at length about this and we came to the consensus that the smartest choice would have been: no rebinding by default, if you want rebinding, make it available, say, using "var", or a sigil

This is precisely how I think as well, some declaration like `let` or `var` or so to say "This is a new binding"

Re: Elixir at PagerDuty

#166

Post by OvermindDL1 »

pera wrote: post #142
OvermindDL1 wrote: post #108

Earlier quoted context omitted.

Entirely subjective yes! ^.^ However what you show is not focusing on syntax differences but rather function differences, even `|>` is an (macro) operator. By syntax I'm talking about things like the `do`/`end` and `fn`/`end` and `,do:`/`do...end` mismatches, things like atom key short-form of `someatom: ...` (being short for `:someatom => ...`) only being useful at the end of it's list/map context instead of everywh…

Thank you very much for your insight! I believe the term "core language" may be more appropriate than "syntax" in your argument: it's true that the pipe operator (|>) is a macro, as well as fn/end or the match operator (=), but that's an implementation detail, they still are syntactic forms. As with any programming language (except of course for Scheme, which is perfect :D) Elixir has some inconsistencies, but I don'…

Elixir defines its parts as either 'Language Syntax', 'Special Forms', 'Kernel', 'Standard Library', and of course user code.

Things like a function call is language syntax. You cannot replace language syntax with anything else. Special forms are things like `for` and `with`, and you can replace these with syntax (though that's going the wrong direction in my opinion). Kernel are the standard library bits that are auto-imported into every module (unless explicitly told not to via `except:` or so), these cannot replace special forms or syntax. Etc...

The Pipe operator is just a normal macro in the Kernel, it is redefinable and in fact there are a surprisingly large amount of libraries that do (to make it more monadic interestingly, which makes me think Elixir needs a binding operator in kernel, perhaps `~>` or so).

Things like `fn`/`end` are language constructs, just no way around that at all.

The match operator `=`, interestingly enough, is a special form and not a language construct, so there are times that you can override it as well.

> except of course for Scheme, which is perfect :D

Take a look at Racket, it is scheme refined into bliss. ^.^

> Elixir has some inconsistencies, but I don't think they make the language "hard-to-read" in any realistic way.

Not overall 'hard-to-read' (not like Java for example), but definitely harder than Erlang I'd state.

Re: Elixir at PagerDuty

#167

Post by inferiorhuman »

steveklabnik wrote: post #150
inferiorhuman wrote: post #146

Earlier quoted context omitted.

https://github.com/rust-lang-nursery/rust-bindgen/issues/104... So yeah looks like I'm tethered to the nightly toolchain after all. :/

I happen to be in the same physical location as the maintainers of both. This should be re-opened. I’ll chat with them. But first... I’m also confused. The component is the rustfmt-nightly codebase. You’re still seeing problems with the component?

I'm using bindgen to generate bindings for radare2. But I'm also using TryFrom, so I'm not likely to move off of the nightly toolchain any time soon.

Before I ended up going down the TryFrom rabbit hole I ran into two issues with bindgen:

1.) Bindgen segfaults with the ancient LLVM on OSX 10.9. Issue #1006. Solution: use LLVM >= 5 binaries from the LLVM site.

2.) Stable (deprecated) rustfmt causes bindgen to segfault. Solution: cargo install -f rustfmt-nightly. It could be as simple as "stable rustfmt requires --force to run because it's been deprecated", but more helpful error messages would be a great thing here.

Re: Elixir at PagerDuty

#168

Post by karmajunkie »

joelbluminator wrote: post #160
cutler wrote: post #26

Earlier quoted context omitted.

How can you compare the overall developer experience of Crystal, which isn't even 1.0 yet and has very few libraries, with the mature ecosystem of Rails?

This. If I was a CTO I would never ever choose Crystal, or Elixir, or Kotlin. Give me a proven, "old", battled tested framework with tons of resources that's easy to teach, learn and get sh done with. I'd choose PHP over Elixir for a new business.

I can't tell if you're trolling here or you geniunely don't realize that the foundation of Elixir is older than PHP.

Re: Elixir at PagerDuty

#169

Post by karmajunkie »

tylerhou wrote: post #40
Touche wrote: post #34

I 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…

http://erlangonxen.org/zerg Seems to be down at the moment, but here's some previous discussion: https://news.ycombinator.com/item?id=5243360

It might be down because the project is pretty much dead at this point. Ling hasn't seen a commit in 3+ years.

Re: Elixir at PagerDuty

#170

Post by steveklabnik »

inferiorhuman wrote: post #167
steveklabnik wrote: post #150

Earlier quoted context omitted.

I happen to be in the same physical location as the maintainers of both. This should be re-opened. I’ll chat with them. But first... I’m also confused. The component is the rustfmt-nightly codebase. You’re still seeing problems with the component?

I'm using bindgen to generate bindings for radare2. But I'm also using TryFrom, so I'm not likely to move off of the nightly toolchain any time soon. Before I ended up going down the TryFrom rabbit hole I ran into two issues with bindgen: 1.) Bindgen segfaults with the ancient LLVM on OSX 10.9. Issue #1006. Solution: use LLVM >= 5 binaries from the LLVM site. 2.) Stable (deprecated) rustfmt causes bindgen to segfault…

What happens if you uninstall the rustfmt-nightly and use the component instead?

(TryFrom is being stabilized fairly soon, it got caught up in some silly stuff but is basically good to go)

Post reply on HN