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

Elixir v1.4.0 released

github.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Elixir v1.4.0 released

#51

Post by lostcolony »

zegerjan wrote: post #37
securingsincity wrote: post #14

> [Kernel] Recognize merge conflict markers in source and provide a readable error message Great idea, having to track down a merge conflict that may have been committed can be a drag.

This confuses me, as I can think of any language where ` I'd say the compiler or interpreter should tell you within no time where it encountered invalid tokens?

The point of this change is to make the error message, when the compiler encounters such a line, something like "Unresolved merge conflict detected in source code at (file:line)", rather than whatever it previously was (some sort of nebulous syntax error, that may or may not have been well located, depending on exactly what the parser managed to infer, but certainly was not well defined).

Re: Elixir v1.4.0 released

#52

Post by matt4077 »

sotojuan wrote: post #10

My favorite part about Elixir is that it doesn't try to reinvent the wheel. It's not an untested, trendy new paradigm or tool. It's based on decades of Erlang/BEAM/OTP experience and Ruby/Rails/last 10~ years of programming ergonomics. The only things that are added are those that actually add to the experience. An example: A large part of the Erlang standard library is not translated in Elixir. Instead, you call Erl…

I believe the rails hype was quite warranted. Both the framework as well as ruby were probably the largest leap in their space I've witnessed. When rails first came out, the dominant competitors were Java/spring and all things PHP. The former was an IBM-sponsored attempt to reduce competition using xml-induced suicides. PHP was the land of config.backup.do-not-change-line-endings.php3~.

It's incredible how much dhh got right from the start, and I believe the opinionated nature taught a generation of developers how to structure a project. It's unfortunate that ruby stagnated.

Re: Elixir v1.4.0 released

#53

Post by definiv »

the_duke wrote: post #44
tiffanyh wrote: post #15

Will Erlang/Elixir ever be able to attain the raw performance speed of Go? I'm not talking about concurrency, etc. Just raw computational speed.

Go is statically typed and compiled, while Elixir/Erlang is dynamically typed and interpreted, so beating Go is unlikely. A plus for BEAM is that each process (aka Goroutine) has it's own, independent garbage collector that doesn't interfere with anything else. The point is, though, you don't use the BEAM for it's raw speed, but for it's great concurrency and fault tolerance. Go has decent concurrency, but it's not a…

Elixir/Erlang is dynamically typed, but also compiled. At least in Elixir you can use .exs files (usually for tests or config) that are interpreted, but any .ex files are compiled.

Re: Elixir v1.4.0 released

#54

Post by felixgallo »

btown wrote: post #29
rubyn00bie wrote: post #6

Earlier quoted context omitted.

I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons cannot be properly implemented in any JS engine/backend I'm aware of. If anything I'd think the abstractions of Elixir/Erlang would be cumbersome and very awkward when writing performant code which had to be transpiled to JS. The biggest reason being is BEAM can…

With the right abstractions and (adhered-to) guidelines, a library in a non-preemptive language can allow your code to effectively yield to the scheduler so often that you get many of the benefits of preemptiveness. React is moving in this direction with their ongoing Fiber project [0] - since components are encouraged to be granular, and must be loosely coupled, the new React scheduler can take well-structured React…

there's essentially no similarity at all between React's component model and the BEAM actor model, except that there's handlers. React and JS have no notion of backpressure, work-stealing schedulers, NUMA, per-actor GC, the list goes on forever.

Re: Elixir v1.4.0 released

#55

Post by innocentoldguy »

sotojuan wrote: post #10

My favorite part about Elixir is that it doesn't try to reinvent the wheel. It's not an untested, trendy new paradigm or tool. It's based on decades of Erlang/BEAM/OTP experience and Ruby/Rails/last 10~ years of programming ergonomics. The only things that are added are those that actually add to the experience. An example: A large part of the Erlang standard library is not translated in Elixir. Instead, you call Erl…

+1! You bring up some excellent points, I think. For example, Elixir is based on decades of Erlang success, and a decade of Ruby and Rails success. I've been using it as the backend to a mobile app for about a year now, and it has far exceeded my expectations in learning curve, ease of writing concurrent code, maintainability, scalability, and performance.

I also agree with you regarding Ruby/Rails. Ruby and Rails are both elegant technologies, and have had a significant influence on how we write web applications today. You cannot take those contributions away, regardless of how many "better" languages come out. I think both Ruby and Elixir have their strengths and weaknesses, but that doesn't mean either is bad. Saying so would be like trashing a screwdriver because it isn't very good at driving nails.

Re: Elixir v1.4.0 released

#56

Post by innocentoldguy »

erik14th wrote: post #38
MrBra wrote: post #35

Earlier quoted context omitted.

Better than what?

Erlang was developed to solve problems that are quite common in Web Development like concurrency, high availability and so on. I see Elixir basically as a user-friendlier version of Erlang with some added goodies. So I think it makes perfect sense for it to be popular among the Web crowd. It definitely has it's own problems(ease of deployment, package maturity, imo). But if your problem involves networks I think Elix…

Deploying Elixir is extremely easy with Distillery, I think.

https://github.com/bitwalker/distillery

Re: Elixir v1.4.0 released

#57

Post by btown »

felixgallo wrote: post #54
btown wrote: post #29

Earlier quoted context omitted.

With the right abstractions and (adhered-to) guidelines, a library in a non-preemptive language can allow your code to effectively yield to the scheduler so often that you get many of the benefits of preemptiveness. React is moving in this direction with their ongoing Fiber project [0] - since components are encouraged to be granular, and must be loosely coupled, the new React scheduler can take well-structured React…

there's essentially no similarity at all between React's component model and the BEAM actor model, except that there's handlers. React and JS have no notion of backpressure, work-stealing schedulers, NUMA, per-actor GC, the list goes on forever.

All true and duly noted, though readers may be interested in how sophisticated Fiber's scheduler may end up being: https://github.com/facebook/react/blob/39278c41e2f98d357f166...

Re: Elixir v1.4.0 released

#58

Post by themgt »

rubyn00bie wrote: post #6
themgt wrote: post #2

Coming from Ruby, Elixir feels like a powerful, beautiful language with a surprisingly radical but ultimately simple approach to concurrency thanks to Erlang/BEAM, and Phoenix is like Rails 2006, as far as the framework to sell Elixir's advantages to the masses. It's very powerful and scaling "just works". All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM, and along with Nerves it's ready…

I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons cannot be properly implemented in any JS engine/backend I'm aware of. If anything I'd think the abstractions of Elixir/Erlang would be cumbersome and very awkward when writing performant code which had to be transpiled to JS. The biggest reason being is BEAM can…

No I'm totally aware you wouldn't be able to replicate BEAM/OTP on a JS runtime, but my guess is you could port enough of the syntax and some of Elixir's high-level abstractions, especially to ES7. The point wouldn't be running the majority of existing Elixir/Erlang libraries, but to easily write ElixirScript within a webapp and transparently reference/integrate with server-side models, auth, etc.

Re: Elixir v1.4.0 released

#59

Post by raarts »

sotojuan wrote: post #10

My favorite part about Elixir is that it doesn't try to reinvent the wheel. It's not an untested, trendy new paradigm or tool. It's based on decades of Erlang/BEAM/OTP experience and Ruby/Rails/last 10~ years of programming ergonomics. The only things that are added are those that actually add to the experience. An example: A large part of the Erlang standard library is not translated in Elixir. Instead, you call Erl…

I like Elixir and am using it but the large amount of Ruby references is starting to annoy me. I've never used Ruby so all those comparisons add no value for my learning it.

But I do like the language and the environment.

Re: Elixir v1.4.0 released

#60

Post by true_religion »

mkarklins wrote: post #40
true_religion wrote: post #27

Earlier quoted context omitted.

When I subclass hashmap, I may desperately want to reimplement collision handling without also having to rewrite the every other private function it calls. Private functions close the library off to custom extension.

... and keeps the library's updates smoother, since there can't be any tinkering with library's implementation.

You don't have to support users who use your library internals. Django for instance didn't support everyone who relied on undocumented internals in its orm. The standardization for the latest release made those internals clean and documented, but unapologetically broke other people's code including mine.
Post reply on HN