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

Elixir 1.19

elixir-lang.org

Post reply on HN
Print view View original

61–70 of 152 posts

Re: Elixir 1.19

#61

Post by dragonwriter »

thibaut_barrere wrote: post #56
bryanlarsen wrote: post #21

Earlier quoted context omitted.

> So many examples of programming languages have huge breaking changes between versions I can only think of 2: python 3 and perl 6. Those two were very traumatic so it's not surprising it feels like more.

Ruby 1.8 to 1.9 has been fairly hard, despite being a minor version change. Strings became Unicode, this broke tons of stuff. Also hash ordering. This caused quite a lot of work on the apps I worked on.

> Ruby 1.8 to 1.9 has been fairly hard, despite being a minor version change.

Ruby 1.8 to 1.9 was a major version change in the semver sense; Ruby wasn't using Semver before, IIRC, 2.1.0, it was using a scheme that was basically loosely like Semver with an extra prefix number. Ruby minor versions were equivalent semver major (and also had a less-stable implication for odd numbers, more stable for even, Ruby “tiny” versions were equivalent to semver minor, and Ruby still had patch versions.

Re: Elixir 1.19

#62

Post by cess11 »

Blackarea wrote: post #18

I really came to love gleam over the last few months. I appreciate elixir getting a type system and remember that this was the big NoGo for me when I explored it a while back. I'd like to give it another chance some time, but I'm worried that it's like typescript - looks typed on the outside but for many libs and packages the types are just a dynamic/any. Is my fear justified? Beam is amazing btw

Elixir has had types since forever, both primitive and things like structs and shape based destructuring. Then there's Dialyzer and libraries like TypedStruct.

It's never been a wat-language in the style of JavaScript.

Re: Elixir 1.19

#63

Post by barrell »

Blackarea wrote: post #18

I really came to love gleam over the last few months. I appreciate elixir getting a type system and remember that this was the big NoGo for me when I explored it a while back. I'd like to give it another chance some time, but I'm worried that it's like typescript - looks typed on the outside but for many libs and packages the types are just a dynamic/any. Is my fear justified? Beam is amazing btw

I would not entirely compare it to TypeScript. Due to pattern matching, legacy elixir will probably come out roughly 50% typed (extrapolating from my own usage, I'm not sure the accuracy of this number). Then since vanilla elixir is getting types (not a separate TypeElixir) I would venture anything actively maintained will get typed relatively quickly.

I personally do not like type systems, and still code in JS, not TS. Any JS artifacts I produce are untyped. Yet even my Elixir-code is nearly type ready.

So while TS is fighting an uphill battle, I think Elixir is working downhill.

Re: Elixir 1.19

#64

Post by andruby »

tyre wrote: post #30
chillfox wrote: post #27

Earlier quoted context omitted.

Ruby 1.8.7 -> 1.9.0 caused a lot of problems in the sysadmin space that took years to get resolved.

triggered. There was a rails upgrade around that time that was similarly painful, at least in the humongous rails app I was working in.

Rails 1 to 2 was a big one indeed. Rails 2 introduced restful routes iirc, which meant refactoring a lot of fat controllers.

Re: Elixir 1.19

#65

Post by barrell »

29athrowaway wrote: post #53

Elixir was not a happy experience. The language itself is maybe OK but the overall experience is not. On a production build, stack traces look like Erlang code, which is the weird syntax that Elixir tried to improve upon. Then you have macros, which make code unmaintainable at the 10k SLOC mark, and increasingly harder to maintain as projects get larger. Running "mix xref graph" on most Elixir projects shows a spaghe…

I have the opposite experience. Even in production builds, I get Elixir stacktraces, and they're exceptionally helpful. Macros only save me time and LoC, I think maybe once I've struggled with a macro-caused issue (and it was immediately apparent that macros were the issue).

ExUnit has been hands down the most impressive testing library I've ever worked with, and the debugging, profiling, analytics, introspection, observability, etc of the BEAM is unbeatable.

Documentation of elixir, elixir deps, and elixir code is also far and above any language I've ever seen.

And the struggles I had supporting minimal concurrency in python were completely alleviated - so even if you don't need massive concurrency, elixir has a good chance of massively simplifying anything that needs minimal concurrency (which is probably most web related projects).

Re: Elixir 1.19

#66

Post by yuliyp »

asa400 wrote: post #10

Just a data point on the deps compilation, on a small Phoenix app with mostly stock Phoenix deps: MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile 32.30s user 7.23s system 320% cpu 12.336 total MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile 0.37s user 0.49s system 12% cpu 6.970 total MIX_OS_DEPS_COMPILE_PARTITION_COUNT=10 mix deps.compile 0.38s user 0.50s system 12% cpu 7.236 total Machine is a Mac M1 M…

You're measuring a cached compile in the subsequent runs. The deps.compile probably did some native compilation in the dep folder directly rather in _build.

Re: Elixir 1.19

#67

Post by patates »

jameslars wrote: post #40
bryanlarsen wrote: post #21

Earlier quoted context omitted.

> So many examples of programming languages have huge breaking changes between versions I can only think of 2: python 3 and perl 6. Those two were very traumatic so it's not surprising it feels like more.

Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.

What started as a "this should be just a few namespace changes" might have cost thousands of person days in my current job. So many tests red, the whole CI/CD broken, and when all "fixed" and done, there were still some uncaught production bugs haunting us for many months... Simply horrible.

On paper, it really was just a few changes. In practice, it forced a massive transitive dependency and technical debt cleanup for many companies.

Re: Elixir 1.19

#68

Post by patates »

agrounds wrote: post #48
bryanlarsen wrote: post #21

Earlier quoted context omitted.

> So many examples of programming languages have huge breaking changes between versions I can only think of 2: python 3 and perl 6. Those two were very traumatic so it's not surprising it feels like more.

Scala 3 has failed to be widely adopted, and now the language as a whole is more or less dead. Not that that’s due to the 2-to-3 transition entirely.

I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?

Re: Elixir 1.19

#69

Post by pandemic_region »

jameslars wrote: post #40
bryanlarsen wrote: post #21

Earlier quoted context omitted.

> So many examples of programming languages have huge breaking changes between versions I can only think of 2: python 3 and perl 6. Those two were very traumatic so it's not surprising it feels like more.

Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.

I don't remember anything significantly bumpy for about 30 large-ish applications we migrated from 8 to 11, guess the mileage varied. JDK is serious stable stuff.

Re: Elixir 1.19

#70

Post by pandemic_region »

recroad wrote: post #23
mcdeltat wrote: post #15

Elixir just keeps chugging along steadily releasing great features and improvements. It's an astoundingly well designed language and the creators have a solid approach to its development. It's a shame I don't get to use Elixir day to day.

I quit my job and started a company just so I can use Elixir.

How's that going for you?
Post reply on HN