Earlier quoted context omitted.
Well, a Java developer isn't going to want to give up the JVM, their type safety, and great tooling, for a start. I get being interested in Erlang if you're doing Python. But interested in doing Python as a Java dev? Probably not.
Seriously, why doesn't python have a maven equivalent yet? And no fat-binaries. Nor self executing binaries. It's just as old and having em basically just boils down to enforcing conventions. But nope, nothing. There have been attempts by some such as shiv, but really... None are even remotely as usable as maven is.
Ask HN: Who regrets choosing Elixir?
301–310 of 340 posts
Re: Ask HN: Who regrets choosing Elixir?
#302Earlier quoted context omitted.
One would think they could just avoid mentioning Lisp. I still don't understand their reasoning.
The reasoning is simple: if someone thinks something would look bad on their resume, they probably don't want to spend time on it, either. For example, I wouldn't want PHP or Fortran on my resume, and, consistently with that, I avoid them. I don't have an opportunity to actively avoid them, but that defense mechanism would leap into action, if called upon. However, I know a thing or two about these; I'm not simply ap…
Re: Ask HN: Who regrets choosing Elixir?
#303Earlier quoted context omitted.
To be fair, if you’re rewriting an Erlang system in Python/JS and you don’t feel like you’re losing much, Erlang was the wrong choice from the beginning. The cases were Erlang shines are very hard to replicate in these languages.
> The cases were Erlang shines are very hard to replicate in these languages. I'm just beginning to get interested in the Erlang ecosystem. Could you please add more color to this and give some examples where Erlang shines? IIRC, Whatsapp backend used to be on Erlang.
Used to be? I know WhatsApp switched from FreeBSD to Linux and swapped hundreds bare metal servers to thousands of VMs. I dont think WhatsApp ever swapped / rewrote their system in another language under Facebook.
Re: Ask HN: Who regrets choosing Elixir?
#304Earlier quoted context omitted.
>when using keyword lists for function options Proplists should be replaced with maps pretty much everywhere. >Also mocking was difficult in tests Interesting, what exactly was difficult? You just replace one function with another.
> Interesting, what exactly was difficult? You just replace one function with another. I'm not the person you're asking, but iirc, that replacement is global - so once you replace function/module X with MockX, you can't test X itself, nor anything else that relies on X.
Inside `with_mock` code will only access mocked function. In case you want to call original function in some condition - you have `passthrough` available inside a new function which will call the original one. So what is the problem exactly?
Re: Ask HN: Who regrets choosing Elixir?
#305Earlier quoted context omitted.
> Interesting, what exactly was difficult? You just replace one function with another. I'm not the person you're asking, but iirc, that replacement is global - so once you replace function/module X with MockX, you can't test X itself, nor anything else that relies on X.
This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang). It's a pity that the elixir community doesn't make this clearer…
I never used that Mox and never had a need to. I just use `Mock` which allows `passthrough` as I stated in another comment, what other clarity is needed I don't understand. Can you give any example of the problem you can not solve instead of pitiness?
Re: Ask HN: Who regrets choosing Elixir?
#306Earlier quoted context omitted.
Our adoption of TypeScript led to a significant reduction in defects, and it definitely isn't killing productivity. Most of the time we take advantage of existing types so if anything it speeds things up in the long run.
You are misunderstanding what I mean. Through I haven't be to clear I think. What I mean is code which not only uses types and takes advantage of the type system but overdoes it. In many languages with a powerful type system you can encode much more then just basic types and this is useful to reduce possible error cases. But if you overdo it the type system part becomes too complex, type error messages too unreadable…
With simpler, more gradual designs like what are in Typescript or Haxe or even static, native-code languages like D, you have more escape hatches available, so you can iterate on the specification a few times and get code running quickly but also aim to make it tighter over time.
Re: Ask HN: Who regrets choosing Elixir?
#307Earlier quoted context omitted.
You are misunderstanding what I mean. Through I haven't be to clear I think. What I mean is code which not only uses types and takes advantage of the type system but overdoes it. In many languages with a powerful type system you can encode much more then just basic types and this is useful to reduce possible error cases. But if you overdo it the type system part becomes too complex, type error messages too unreadable…
I think I understand this one. I would restate it as "Powerful static type systems usually encode more constraints than you can easily reason about." And that's good(it catches your errors) and bad(you start to fight the compiler instead of solving the problem). With simpler, more gradual designs like what are in Typescript or Haxe or even static, native-code languages like D, you have more escape hatches available,…
Re: Ask HN: Who regrets choosing Elixir?
#308Earlier quoted context omitted.
> The cases were Erlang shines are very hard to replicate in these languages. I'm just beginning to get interested in the Erlang ecosystem. Could you please add more color to this and give some examples where Erlang shines? IIRC, Whatsapp backend used to be on Erlang.
>IIRC, Whatsapp backend used to be on Erlang Used to be? I know WhatsApp switched from FreeBSD to Linux and swapped hundreds bare metal servers to thousands of VMs. I dont think WhatsApp ever swapped / rewrote their system in another language under Facebook.
Re: Ask HN: Who regrets choosing Elixir?
#309Earlier quoted context omitted.
That's why you don't market yourself as a generalist problem-solver. You market yourself as an expert in C# AND Python AND Swift AND... whatever else you know how to use. With appropriate signalling to communicate your experience levels with each. There are lots of senior roles that require oversight of multiple projects that are working with different tech stacks. Some companies specialise in a single language. But…
"Javascript" though isn't Javascript. I mean it could be, but it's worthless in that context because what you actually need to be productive is familiarity with the browser DOM, current frameworks for frontend or backend, and basic project structures. For Java it might be enterprise Java, it might be Android, in which case you need familiarity with those frameworks to be productive. For Swift it'll be iOS. No one's "…
I mean, I've certainly been expected to at previous jobs (my background being backend and frontend web). It was a steep learning curve, but in retrospect it was also an excellent learning experience.
> Are you an "expert" in all those things? I doubt it.
No, but give me time. I'd consider myself an expert at frontend JavaScript/TypeScript and backend JavaScript/PHP. I have a decent amount of experience (enough to get a job an X developer, not enough to call myself an expert) in a number of other technologies (e.g. Python, Rust). And at my current day job, I'm responsible for a React-Native project through which I'm getting exposed to a lot of the quirks of the Android and iOS platforms.
Go I've not used. But Go's a relatively small ecosystem to learn. I don't put Go on my CV, but I'd be confident applying to a Go job. C++ I've done a little of, but I'm absolutely not an expert. Although Rust experience means that I understand most of the low-level concepts and best-practises that aren't C++-specific. Still, I absolutely don't advertise that on my CV either. One day though maybe. I'd like to do some embedded stuff at some point.
> In fact the worst possible thing you can generally write anywhere is that you're an expert in C++ which at this point is oh-so-many subdialects.
C++ is a bit of a special case there though. Because
1. C++ is huge: it takes a lot longer to master C++ than it does other technologies.
2. C++ is wildly unsafe. Therefore the consequences of not knowing what you are doing with C++ are much greater. You'll likely end up with a crashy program riddled with security holes.
In contrast, I wrote a production Rust project with no prior experience, and all the things that would have been crashes or security issues in C++ were compile errors. So the only consequence of my lack of experience was that it took longer to complete the project.
Re: Ask HN: Who regrets choosing Elixir?
#310- Elixir and the Phoenix framework is perfect when building concurrency systems. Our company had made a ticketing system, solving the tickets for "Cirque du Soleil - Hongkong 2018". During two months of the event, our system (one Elixir/Phoenix server - scale up to two - one load balancer) can handle more than 5000 tickets per second. We were so excited. Unfortunately, the client's company closed after that. So the project was closed too.
- The second project was a product of a finance startup. Not so much thing I can share in this project, but the main feature is chatting. We used the Phoenix Channel and Graphql Subscription for this feature.
- In the side project, one member of the team used Phoenix Liveview to build a Coup game (board game).
So, in general, when I work with Elixir, I see a few pros and cons:
Pros:
- Fast. Functional programming is really fun. I love pattern matching.
- Not so hard to write tests. It's easy to mock external APIs. (Check out this blog: http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-...)
- Easy to deploy. After dockerize the application, I can run it anywhere. The ticketing system was run on AliCloud, and the second project was run on Kubernetes (AWS).
Cons:
- Lack of supported libraries for external services. Sometimes, our team has to write a wrapper library to call directly to external services' APIs.
- Not easy to hire an Elixir developer in Singapore. Our team tried to hire Ruby on Rails developers and train them. But they were not feeling interesting in learning Elixir, so they left the team.