Live data from Hacker News

Would you still pick Elixir in 2019?

github.com

241–246 of 246 posts

Re: Would you still pick Elixir in 2019?

#241

Earlier quoted context omitted.

Don't be so dogmatic - Bootstrap works just fine, and if it's what you know, you need some very good reasons to switch and learn a new framework.

Not about being dogmatic. Bootstrap is just wrong in 2019.

What should I use instead of Bootstrap in 2019 then?

Re: Would you still pick Elixir in 2019?

#242

Earlier quoted context omitted.

> I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me. Mind elaborating? F# seems like a decent fit from what you've said. I'm hoping the language will grow less stagnant as .NET Core matures.

I'm a big fan F# the language . It comes across very as a modern, cleaned-up version of OCaml — F# started out as an implementation OCaml, after all — with some very interesting innovations. However, it comes with the baggage of .NET Core, which is a rather big thing. And it's growing, as Microsoft is apparently porting over everything from the older, non-cross-platform .NET stuff. For one, .NET Core includes the CLR…

I see -- most complaints I've heard about .NET Core relate to F#'s status as a second-class citizen vis a vis compatibility problems, which have recently resolved.

I'm with you on AOT, but I think the language makes more sense if you understand it as a .NET port of OCaml. If you isolated F# from CLR, you'd lose libraries and tooling, arguably F#'s raison d'etre, pleasant design choices aside.

Re: Would you still pick Elixir in 2019?

#243

Earlier quoted context omitted.

Wrk2 is not fast enough and will thus give spurious results since the bottleneck is the client. The only measuring tool that is fast enough to accurately measure Phoenix performance is something like Tsung (which is also an Erlang app...)

I am not sure what you are talking about. wrk2 can put out 7M req/s on a 16 core box. That is way beyond Phoenix's performance on the same HW type. wrk2 is widely used and accepted performance measurement tool. Again, you mentioned microseconds latency which means you are talking about localhost microbenchmarking. That is irrelevant from the production workload point of view. I have saturated network links successful…

alright. this looks interesting. I'll have to dive back into this space and see what's changed, I'm probably out of the loop. What's the diff between "wrk" and "wrk2"?

Re: Would you still pick Elixir in 2019?

#244

Earlier quoted context omitted.

Well, yes, but that guy who advocates unit tests might understand all of this and the shortcomings of the chosen programming language, and that is why he advocates unit-testing. Careful who you are criticizing here :)

I never discounted unit tests. I advocate it as an important feature in a project. I'm saying you need significantly less when you have the types of checks I talk about in place. :) The guy I'm criticizing here is a certain breed of person who advocates unit tests but suffers from a logical flaw in his reasoning. He advocates unit tests like a mad man but he uses an unsafe, untyped language for the entire project. Ja…

I understand your viewpoint, but aren't you assuming that the "guy advocating unit tests" has the option of choosing a type-safe language? In my experience, the programmers rarely have the power to choose the programming language. In fact, they were probably hired because of their expertise in the language already being used.

Just saying, if I'm writing Python and advocating unit-tests... even of TypeError exceptions and similar problems that would be avoided by using Golang... it's probably because I know these are common problems in Python/JS/non-type-safe languages, and I probably don't have the power to choose a different language than the one already being used by my company/development organization.

Re: Would you still pick Elixir in 2019?

#245

Earlier quoted context omitted.

I never discounted unit tests. I advocate it as an important feature in a project. I'm saying you need significantly less when you have the types of checks I talk about in place. :) The guy I'm criticizing here is a certain breed of person who advocates unit tests but suffers from a logical flaw in his reasoning. He advocates unit tests like a mad man but he uses an unsafe, untyped language for the entire project. Ja…

I understand your viewpoint, but aren't you assuming that the "guy advocating unit tests" has the option of choosing a type-safe language? In my experience, the programmers rarely have the power to choose the programming language. In fact, they were probably hired because of their expertise in the language already being used. Just saying, if I'm writing Python and advocating unit-tests... even of TypeError exceptions…

For python you can use type annotations with an external type checker such as mypy or flow for js.

To implement type checking in js or python would add a layer of unparalleled safety for a fraction of the development time involved with unit tests.

Yet I would say 90% of developers are unaware of this contradiction and go on piping about the extreme importance of unit tests while completely ignoring type checking. They value safety but are too naive to know what safety means.

Post reply on HN