I haven’t looked at it myself, but this one does sound interesting: https://github.com/rancher/k3s. It aims to be a “lightweight” kubernetes distribution.
yes https://rancher.com/ is doing good job about k8s
This is doable, K8s running on the intel nuc’s in restaurants
And the performance and benchmark is important as well. Please don’t judge other on your personal opinion.
I don’t know if that was directed at me for asking what kind of performance you are seeking. I hear the argument that x technology is not fast enough, but in my experience the languages I have worked with (now and in the past) has been fast enough—because it turns out that the performance I need for the problem space I am in is IO bound, and very rarely CPU bound.
Thanks for the tips. I have been thru those topics and covered Elixir in Action to a great deal.
Typically, when I am adding members to my team and dont find direct match in terms of specific language being used, I adopt this approach - look for devs who have solid foundation of concepts, make sure they are committed and interested in stack that we are using in the project and then give them time to pick up language specifics while tackling simple tasks. Its relatively a safe bet.
So, I am not thinking myself as a junior developer. What I was trying to convey is that I am willing to start as a Junior/Developer on a project to give comfort feeling to the employer to take “risk” with a dev with no prior commercial experience in Elixir (but fair understanding of the language and framework having done 2 non-commercial projects), prove myself and then progress to tackling tasks matching my skill-set while learning quickly the additional bits of knowledge that I need to gain to ensure effective delivery.
The point I was trying to make that even this approach did not help much in securing a job as Elixir developer since most of the requirements are primarily for “Senior Developer” or with prior experience, which is a big hurdle in adoption, IMHO.
It highly depends on the developer background. If one has even slight experience with FP then it will be much easier. In general jumping from imperative language like Ruby/Java/Python/etc. to Elixir will introduce some friction, but it is understandable.
- the learning resources + help from this forum are great. I came from an imperative / OO background.
The Elixir plugin for Webstorm is actually the best IDE I’ve used for it by far (the color coding is so much better than the alternatives).
Raw CPU performance is pretty lackluster compared to things like C++ or even NodeJS – but being able to fan out to dozens of cores with virtually no effort is pretty amazing. Adding in things like Hastega (for GPU) and Rustler (for Rust NIFs) will probably cover a lot of critical performance paths in the future.
As someone who’s gotten paid to write in maybe 10 different languages… I agree. The shift to FP/OTP/Beam is a big one, but I think worth doing.
I think DocTests are amazing! You finally know the docs are correct – because they compile! Refactors are painful, the sad lack of types can be somewhat mitigated with Dialyzer.
Thank you for your introduction!
Hastega slide is here
Video is here
I hope your happiness!
I do not know where sandy you feedback, but on slide with comparison between approaches this:
1..1_000_000 |> Enum.map(&foo/1) |> Enum.map(&foo/2)
1..1_000_000 |> Enum.to_list() |> func() def func(), do:  def func([h | t]), do: [h |> foo |> bar | func(t)]
Aren’t equivalent in execution, as first one will create new list with
elem1 = foo(elem) and then it will create new list with
elem2 = bar(elem1) while second will create it in single pass, so you will not traverse list twice. What you wanted is:
1..1_000_000 |> Stream.map(&foo/1) |> Enum.map(&bar/1)
Which will work similarly to your example, but that will make Java example “outstanding” implementation (unless compiler is smart enough to optimise that out).
It’s worth noting that there is an overhead to using streams so it’s worth benchmarking your application to ensure that this change has the desired performance benefit.
‘Moving away’ makes it sound like someone will never use the language again.
This is something that is definitely not true for me/my company: We most definitely use other languages besides Elixir. Even though we are using Elixir in some projects, we are still using Ruby/Rails because it is in some cases faster during prototyping (for the same reasons that make Elixir better suited for maintaining longer-lasting projects) and because of the larger pool of people who already know/use it.
I am using Haskell as web-development language in a personal project, and also really liking it.
Rust is something I’d love to be able to finally use in a real project as well.
However, neither of these have ‘replaced’ Elixir. Rather, they are separate tools with separate strengths/weaknesses, and each has its own purpose.
To be honest, I don’t think I have ever ‘moved away’ from any language. There are definitely languages I enjoy less working in (C and Java come to mind) because of some design decisions that are now (arguably) viewed as dated. However, I still (have to…) work with those languages because not everything can be evergreen in this world. And I do like the intellectual challenge of writing clean code in Java, or building my own Trait-system in C.
And another side note would be that there are also languages out there that I shun to touch with my ‘bare hands’: Rather than writing plain HTML/CSS/JS, I much prefer HAML/SCSS/ES6 (or even replacing ES6 with Elm) because of the tremendously improved development experience of these higher abstraction languages.
«Moving away»…I am not a native english speaker, so perhaps I worded it poorly. I asked this question because I wanted to hear about the painpoints people feel when the honeymoon phase is over. I think the thread was somehow successful, because though it spun off into multiple directions, the answers still highlighted some interesting points.
Moving away from a language; I used to do NodeJS. Personally I will never use it again for anything—so I think there is such a thing as moving away from a language/thing/etc. But then again, I have moved away from Denmark, but I will most likely move back to Denmark at some point in the future
Oh, absolutely yes. I have moved away from multiple languages. More often than not, it is a slow process. But there can come a point when you decide that a language is no longer useful enough to justify its pain points, that there are better options available, and stop taking new work in that language, while considering how to get out of maintenance work.
It is not that late-linking is desirable for hot-swap. It is rather that, as a dynamic language, Elixir does not require a module to be available at compile time. This brings some nice properties too, such as straight-forward parallel compilation of modules.
But Elixir does come with a cross-reference tool and you could easily make all of those become errors by enabling
warnings_as_errors in your project:
[elixirc_options: [warnings_as_errors: true]]
Or if you want to enable it only for xref:
[aliases: ["compile.xref": "compile.xref --warnings-as-errors"]]
So the tooling is there and it can do what you want, you just need to tell it to.
Thank you for you opinion!
Well, to discuss exact semantics, it may be true that Stream should be used instead of Enum, though we can get correct results in this case.
I agree it. Thank you.
Thank you, Jose! I didn’t know about that tool/config, I’ll check it out.
I’m not sure that it would help here, though: There are no warnings for cases like this one.
It should. Generally speaking, if you invoke a module or a function that does not exist, Elixir will emit a warning.
In the router, the action is invoked dynamically (not because of performance but because of how the pipeline is designed), but you should catch mismatched module names as you mentioned in the issue.
EDIT: Pushed a fix to Phoenix to guarantee it happens: https://github.com/phoenixframework/phoenix/commit/e4378c3bc8ea6478bc80f2fe41f0516424ee106c
Thank you! IMO it’s a win when we give feedback like that. Here’s my use case, though:
I add a failing route:
get("/nothing", NoController, :no_action)
mix test compiles and runs with no warnings. (In real life, this would manifest as a broken refactoring, or a misspelled controller or action.)
I’d love to get a warning for a reference like this.
I edited my comment above and it links to a commit that does exactly that. It was used to emit the warning but it was accidentally removed once we added some optimizations. It will emit the warning in the next Phoenix version.