Earlier quoted context omitted.
That's generally decided by the experience of the existing team members.
... whom an inexperienced hiring department entirely trust when they assure that the technologies they are already familiar with are the best fit for the company, let's hire only people who think the same?
Ask HN: Who regrets choosing Elixir?
331–340 of 340 posts
Re: Ask HN: Who regrets choosing Elixir?
#332Earlier quoted context omitted.
With regard to mocking, I’ve found that it works better to swap in a fake process rather than a fake module. If you have a FooClient genserver that makes RPC calls to a service or database, make a FakeFooClient that responds to the same kinds of genserver calls and returns canned responses. Or even implement a simplified version of the external service in the genserver.
I did this and I found that as I increased the paralellism of my tests, the genserver got bottlenecked and the test suites started throwing heisenbugs, which is not what you want. You should really be using the Mox library, which I don't believe suffers from this problem.
Re: Ask HN: Who regrets choosing Elixir?
#333Earlier quoted context omitted.
alright, just to clarify, from the comment that introduced expressive power into the discussion: > Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does. i understand that as "the ability to describe/enforce the domain's rules". now, i guess i made a bit of leap, jumping to runtime typechecking. my thinking was that while modelling your d…
Well, let's be clear here: the code already expresses that height and width are numeric. You read the code and knew they were numeric; QED. In fact, if you think a bit deeper, you probably know a few more things about the type of those variables: they're positive, for example. And if you're using a mainstream statically typed programming language, you probably aren't actually going to express that it's a numeric usin…
i just wanted to make a point about how checking types at runtime doesn't mesh well with generics and functions, so it's always going to be limited on that axis. and perhaps there's a dynamically typed nirvana where you just handle that differently, but it's a problem i personally had
[edit: removed unnecessary snarkiness]
Re: Ask HN: Who regrets choosing Elixir?
#334Earlier quoted context omitted.
> My question isn't whether you can test enough to catch all bugs. My question is whether time spent wrangling types gets you more value than time spent writing tests. Yes, by a tremendous amount, in my experience. > Are they? How so? Tests are only as good as the person writing them. I could see a model working where the person that wrote the code isn't the person that writes the test, but that's definitely not how…
> > My question isn't whether you can test enough to catch all bugs. My question is whether time spent wrangling types gets you more value than time spent writing tests. > Yes, by a tremendous amount, in my experience. Well, then I'd have to ask what your experience is that causes you to believe this? I don't mean years, I mean what languages, and what, more specifically, you observed. > Tests are only as good as the…
Probably 20 Rails developers across 3 companies
> So? "Catching everything" isn't a thing
The "everything" I'm referring to is less about "all bugs", and more about "Type errors, spelling mistakes, missing imports, etc". All code has bugs. Not all languages allow remedial spelling errors to make it into a build.
> shrug Okay... To be clear, "runtime" doesn't mean "in production".
It sure does not. I'm not sure that changes anything. It seems like being difficult for the sake of it to argue that it's the same value to catch potential bugs now vs. later. Obviously the answer is now.
Re: Ask HN: Who regrets choosing Elixir?
#335Earlier quoted context omitted.
... whom an inexperienced hiring department entirely trust when they assure that the technologies they are already familiar with are the best fit for the company, let's hire only people who think the same?
I'm not sure if you're being obtuse. But rewriting your stack in a language no one on the team knows because someone on HN said it's a better fit for your usecase is something no good engineers/managers would think is a good idea. If a potential hire thought that was a reasonable thing to do, that would be a major red flag - a sign this person lacks experience, and any kind of business understanding.
Re: Ask HN: Who regrets choosing Elixir?
#336Earlier quoted context omitted.
> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.
This, twice. Back in the day people would balk at hiring Python programmers saying, "there are so many more Java programmers", and I used to say, "Why would you hire a Java programmer who was unwilling or unable to learn Python?" Same logic applies here: Why would you hire a Python programmer who was unwilling or unable to learn Erlang? (Especially if you're going to pay them to do it!) If you can't switch languages…
Re: Ask HN: Who regrets choosing Elixir?
#337Earlier quoted context omitted.
What do you mean it's fairly strong? Not challenging you, I'm just trying to get my head around all the type stuff.
As hwayne said, most of the time Python won't do implicit type coercion. What this means is, if you try to do something that doesn't make sense based on the types, it will throw an error rather than go on. For example: ~/$ python Python 3.7.4 (default, Oct 12 2019, 18:55:28) [Clang 11.0.0 (clang-1100.0.33.8)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> hello = 'Hello, world' >…
Re: Ask HN: Who regrets choosing Elixir?
#338Earlier quoted context omitted.
I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…
I agree, but I think it’s a common misconception. Having used many languages, both for very large and small projects, languages with compile time static type checking and run time dynamic type checking, I find it’s easy to rely too much on static type checking. I think what happens for a lot of programmers is that static type checking uncovers a lot of basic bugs and typos, so they feel like it has a major advantage…
Re: Ask HN: Who regrets choosing Elixir?
#339Earlier quoted context omitted.
At the end of the day, it’s about can you deliver that project on time and with limited bugs. Everyone’s experience will be different, so maybe accept that different programmers work better with different systems. I can tell you with 20 years of programming experience that static type systems don’t make me more efficient... and I’ve used them all. And just because I can see the reply coming, I’ve worked with programm…
Put frankly: I’m not going to “accept” that because I’ve watched programmers with twenty years of experience (woe betide me and my mere thirteen!) tank projects through this kind of arrogance. And it is arrogance, to dress up the limitations of a meatbag as a positive against the tireless specificity of the machines. Then those meatbags realize that they have to refactor their code and the world ends. The computer is…
Re: Ask HN: Who regrets choosing Elixir?
#340I tried implementing an algorithm for tracking multiple objects based on graph-cuts using Elixir. I was disappointed in the lack of strict typing in the language, since this is one of the things that made me want to try functional programming. In order to tell the type of various method signatures, it seems like you have to go looking at other areas of your program. I’m aware that it’s possible to annotate method sig…
Why would you "try to implement" stuff in a language that is clearly dynamically typed and then be disappointed about lack of types? It's like trying Python and being disappointed about it lacking types. Do you often try languages without even googling for a basic description and then are disappointed because it's not like other programming language or what you expected?
It’s easier to recognize that a feature (dynamic typing) is an issue in some applications after trying it for a while rather than just taking a theoretical view. I’ve sometimes misunderstood how a feature works in practice by relying too much on my theoretical understanding.
Also, because Elixir allows type annotations, I was thinking that I might not need static typing. It turned out (at least for me) that I would prefer to have a language that insists on type annotations by default rather than allowing them as options.