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

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

Post reply on HN
Print view View original

321–330 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#321

Post by [deleted] »

kerkeslager wrote: post #293
pavel_lishin wrote: post #99

Earlier quoted context omitted.

> if you test all the behavior you care about, then you don't care if there are type errors, because they only occur in situations where you don't care. If I test all the situations I care about, the one situation I thought I didn't care about is going to fuck me in production.

If you test all the situations you care about and statically type check, the one situation you thought you didn't care about and that wasn't caught by the type checker is going to fuck you in production. It's not useful to talk about a binary "bugs versus no bugs", because "no bugs" isn't plausible in most codebases. It's also not useful to talk about "more bugs versus fewer bugs" because that's only part of the pict…

[deleted]

Re: Ask HN: Who regrets choosing Elixir?

#322

Post by pavel_lishin »

kerkeslager wrote: post #286
alexbanks wrote: post #103

Earlier quoted context omitted.

Exactly

Analogies are a great way to explain things, but not so much a great way to prove things. If you're writing software that's life and death critical like wearing a seatbelt, you should absolutely be using a strong, statically typed language, because catching errors at runtime is completely unacceptable. But incidentally, none of the proponents of static types on this thread have talked about any languages that I would…

> Analogies are a great way to explain things, but not so much a great way to prove things.

What are we proponents of static types being asked to prove?

> But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical.

I would argue that catching bugs at compile time, before you ship them, is vastly preferable to catching them at run time.

Re: Ask HN: Who regrets choosing Elixir?

#323

Post by kerkeslager »

pavel_lishin wrote: post #322
kerkeslager wrote: post #286

Earlier quoted context omitted.

Analogies are a great way to explain things, but not so much a great way to prove things. If you're writing software that's life and death critical like wearing a seatbelt, you should absolutely be using a strong, statically typed language, because catching errors at runtime is completely unacceptable. But incidentally, none of the proponents of static types on this thread have talked about any languages that I would…

> Analogies are a great way to explain things, but not so much a great way to prove things. What are we proponents of static types being asked to prove? > But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical. I would argue that catching bugs at compile time, before you ship them , is…

> What are we proponents of static types being asked to prove?

Your arguments for why you think static types are better.

> I would argue that catching bugs at compile time, before you ship them, is vastly preferable to catching them at run time.

I would argue that you're only doing the benefit part of a cost-benefit analysis, which isn't very useful.

Re: Ask HN: Who regrets choosing Elixir?

#324

Post by p_l »

kenhwang wrote: post #250
alex55 wrote: post #80

I work for a Ruby on Rails shop and we used Elixir for two projects about a year or two ago when it was getting a lot of good press. The first project was an API that was intended to serve as a middleman between a few legacy services. Basically the company that hired us was building a new JSON API but didn't want to rewrite all their old code and our job was to consume the output from their ugly legacy APIs and produ…

You experience pretty much match mine. My boss really wanted to use Elixir. Our CTO said he could only if he could convince 3 senior engineers and one ops person to agree to work on and support it. So he flew a whole team of us to ElixirConf. He organized a hackathon team around it. We rewrote some non-critical some services in it. All on company time and money. At the end, none of the engineers could sign off on usi…

I'd say that it sounds like you made an informed choice, with proper upfront research on it. That's commendable, even if my fanboying over Erlang would like to steer elsewhere :)

My big problem is with companies that don't do any exploratory work like that. Write a prototype in new language/framework with the explicit idea enforced in project management that it's going to be a throwaway. Do a study through hackathon etc like your team did.

Don't just go on meme-driven development, which covers "CTO read a fancy shmancy content marketing piece in colourful magazine while on the flight"

Re: Ask HN: Who regrets choosing Elixir?

#325

Post by kerkeslager »

_t0du wrote: post #296
kerkeslager wrote: post #283

Earlier quoted context omitted.

> Yeah. You formulated my opinion much more elegantly than I could've - in my experience it's always the "Well if the tests didn't catch this, we just aren't testing enough." Which in my experience is a losing strategy, you'll never test "enough" in languages like Ruby. Maybe someone is saying that, but I didn't say that. My question isn't whether you can test enough to catch all bugs. My question is whether time spe…

> 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 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 most development orgs work. If a dev is good enough/capable of writing comprehensive enough tests to accurately test the correctness of their code, that's great, but almost none are (I say almost because I actually mean "actually none" but am leaving room for my own error).

Static types are also only as good as the person writing them. C's type system, for example, lets through a wide variety of type errors. And users of a type system can easily bypass a type system or extend it poorly: I've written a lot of C#, and while C# has a type system which, when effectively used, can be extremely effective, I've also seen it used with dependency injection to cause all sorts of tricky bugs.

I don't think we can conclude much from bad programmers doing bad things except that good programmers are better, which is practically tautological.

> If you're an average dev, you'll write average tests (neither of these are insults), but that means you still won't catch everything (by a lot).

So? "Catching everything" isn't a thing--if you're talking about that, you're not talking about reality. There are two systems I've ever heard of which might not have any bugs--and in both cases an absurd amount of effort was put into verification (far beyond static types), which, even late in the process, still caught a few bugs. Static types aren't adequate to catch everything either.

> > But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical.

> I couldn't possibly disagree more with this statement.

shrug Okay... To be clear, "runtime" doesn't mean "in production".

Re: Ask HN: Who regrets choosing Elixir?

#326

Post by RMPR »

411111111111111 wrote: post #260
winrid wrote: post #249

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.

PyInstaller Nuitka PyOxidizer To name a few.

Re: Ask HN: Who regrets choosing Elixir?

#327

Post by RMPR »

jonnytran wrote: post #301
411111111111111 wrote: post #260

Earlier quoted context omitted.

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.

Have you tried Nuitka? https://github.com/Nuitka/Nuitka

In the same vein there's also PyInstaller and PyOxidizer, not to mention platform-specific binaries generators (Py2app, ...)

Re: Ask HN: Who regrets choosing Elixir?

#328

Post by ProZsolt »

PragmaticPulp wrote: post #191
ProZsolt wrote: post #184

Earlier quoted context omitted.

You don't give it to 3 random people. You give it to a team which depends on it. It's not a side project because if that breaks your project breaks.

My least favorite part about HN is trying to share advice based on real-world experience, only to people show up and armchair quarterback the situation with solutions that sound easy on paper. You'll have to trust me that we didn't just throw our hands up in the air when dealing with the Erlang situation. We tried a lot of the suggestions here and more. Erlang is one of those languages that, for whatever reason, lull…

Sorry if I wasn't clear. I'm not questioning why you switched from an otherwise unused technology. Sometimes it's the best way forward. My comment is meant for this sentence:

> Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory.

I like to maintain and improve legacy systems and usually happy to do it. When I got a separate side-project I had constantly fight with my team why I should work on project X instead of contributing to our core project. If it was my whole team responsibility they were happy that somebody does it. Also, they wanted to invest enough time so it won't break.

Re: Ask HN: Who regrets choosing Elixir?

#329

Post by kerkeslager »

uryga wrote: post #311
kerkeslager wrote: post #288

Earlier quoted context omitted.

> i've used various Python libraries for runtime type-checking (based on `typing` annotations) like `typeguard`. Let's just stop right there, since it's immediately clear you aren't answering the question I asked. You're talking about type checking, not descriptive and expressive power. The topic is whether dynamic types are suitable for domain modeling, not whether dynamic types provide static type checking. We all…

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 using the type system. 90% of the time someone will just throw `int` on there and call it a day, and that type expresses a bunch of lies about the height and width: it says it can be negative, and it says it can't be a decimal, and it says it can't be greater than the INT_MAX of you machine. `unsigned long` and `double` are both a little better, but are still expressing a bunch of lies. And that's if you are in a more modern language: in C, for example, you're telling the compiler that it's totally cool to add the side_length to a char* and (depending on you settings) not even warn about it.

So I have to ask, where exactly is this expressive power you're talking about? You're only gaining the ability to express things to the compiler, not humans, and it doesn't actually give you the ability to express what you want to express to the compiler. You've eliminated the narrow class of bugs where:

1. The code passes in a non-numeric.

2. The bug occurs on a path not traversed in normal testing.

And you've done this at the cost of your code not being able to handle a lot of the numeric values you might want to be able to handle.

Re: Ask HN: Who regrets choosing Elixir?

#330

Post by gfodor »

toyg wrote: post #159
gfodor wrote: post #157

Earlier quoted context omitted.

If you see your identity as an engineer to be one grounded in the languages you use, you have commoditized yourself, or are at least very junior. Programmers solve problems, usually with a mix of deep skill sets revolving around domain knowledge or knowing how to use computation, systems, etc to solve them. Competency in a specific programming language is far down the list of what defines the value of a specific indi…

Well, that’s not how programmers are recruited in the real world though. Java shops will hire Java programmers, C# shops will hire C# hands, etc etc. Marketing yourself as a generalist problem-solver will get you, at best, in one of those nightmare scenarios where you’re the only programmer in a non-tech company.

I specifically was referring to your identity as a programmer, not how you market yourself. Those are separate things.

The OP said "I'm a python programmer", and discounted the value of learning something new like elixir because it would undermine this due to the opportunity cost, which implies they may be falling into the trap I mentioned. All other things being equal, someone who is reasonably competent at both Python and Elixir is going to probably solve many problems in a better way than someone who didn't have a broader perspective. (In part because learning Elixir stretches well beyond learning a programming language, it is an introduction to an entire distinct continent of distributed systems knowledge and technology - OTP, BEAM, etc.)

Post reply on HN