D4no0

D4no0

Great post!

Yeah I’ve noticed this too. I’ve had an interview for a golang position a few years ago, where they told me that they use kubernetes for fault tolerance and scaling, when they asked me what I used at my job, I just said I don’t have to use anything, the VM was handing all of that for me, they looked at me like I was the last idiot on earth…

I think the concept of what we say is wrong OOP states: encapsulation shakes hand with mutability and side-effects.

What I find more baffling than all of this, is how errors are treated as a separate entities. A typical example:

try {
      File myObj = new File("filename.txt");
      if (myObj.createNewFile()) {
        System.out.println("File created: " + myObj.getName());
      } else {
        System.out.println("File already exists.");
      }
    } catch (IOException e) {
      System.out.println("An error occurred.");
      e.printStackTrace();
    }
  }

This approach enforces defensive programming, somehow groups multiple parts of code handling together, and introduces a new type of completely different results from the function, not to mention that it reminds me of goto style programming. My only explication for this implementation is either an afterthought or the actual limitation of the type system, because you need to have these polymorphic types that can have different values like Ok, and Error that we use as a convention both in elixir and other languages.

What is strange to me is the fact that haskell was released before languages like java, yes haskell is more focused on academic use, however a lot of concepts that were whacked together as an afterthought were already implemented correctly previously.

So to articulate correctly, namely inherent bad design of features around OOP make the languages complex and hard to learn, not only the actual OOP specific features like inheritance, etc.

2
Post #12
dimitarvp

dimitarvp

Your post is excellent but IMO the sarcasm about statically strongly typed languages detracts from it:

You and @sodapopcan (to whom I already gave an example about what they bring to the table :stuck_out_tongue: but he still seems to wonder what are they good for) seem to underestimate the ability to refactor via a checklist that the compiler is literally handing you, as opposed to crudely searching for certain texts in the codebase and assuming that’s enough – and to be fair to all sides it usually is, which makes the cases where it is not enough all the more dangerous and confusing (some codebases pass modules around and use them dynamically, others use protocols, yet others use apply, and let’s not even mention those that import or alias stuff so it’s not trivial to find even for LSP sometimes etc.).

That, plus the ability to strongly statically type and enforce data structures in important places – like configs, a good amount of which are a trap in Erlang land, a mish-mash of nested keyword lists, just lists and various tuples – actually saves time. I already gave example to @sodapopcan about HTTPoison / hackney and a few others whose e.g. SSL configs are one of the things I’ve seen people get wrong no less than 50 times in the last 7 years and a few months I’ve been contracting with Elixir.

Also you’ll need to clarify on the “can’t adequately test” part because for years of writing Golang and Rust I am just not seeing that to be true.

So I propose: let’s argue OO vs. FP without sarcastic jabs at the expense of static strongly typed languages because (1) it’s a different discussion entirely and we’re muddying the topic and (2) I don’t feel that most detractors have made an effort at understanding “the other side”.

I’ve been at both sides and while I agree static strong typing system won’t add much value to Elixir in particular because pattern-matching already allows you to both assert on data shape and the types of [certain parts of] it, I would still posit that some better typing system will reduce certain commonly happening WTFs per minute and will especially remove a whole class of deployment problems where you have to make a release (or force-rerun of a CI/CD action) just to curse “frak, where is that keyword list value supposed to go in the config of this library exactly?”.

0
Post #13
adw632

adw632

Yes, shakes hand, and then some.

BEAM languages also enables a form of “mutability” for process state (basically these are the OO BEAM objects) through recursion, when passing the new state into a tail call within whatever function that is performing the process “receive loop” or “runloop”. Noting we don’t actually have loops in functional languages, only recursion, code is always “moving forward”, never backward, so loops or branching backward are impossible in valid Erlang bytecode.

This approach has other benefits at a VM level for safe and preemption (soft realtime) and guarantees of always terminating and cleaning up process state that other languages and VMs can never get. Even when other languages try to adopt the Erlang actor model, they can’t preempt safely to get the Erlang determinative response time, they can only flag well behaving code to please be nice and yield, please be nice and die, but a thread can be running any code anywhere as state is just floating about, the thread may be in the middle of updating a shared data structure, or using log4j, or stuck in a hard loop and can never safely yield or be killed by the VM with the only way out being a hard restart of the OS server process at that point.

The difference with the BEAM vs other languages is that in other langues objects are divorced from the execution context. Whilst in one sense a traditional OO object may be “owned” through an object relationship (e.g. a manager object), they are not owned by a single execution context. Objects “float around” for use by an execution context (eg a thread) often many threads at a time as program state is not bound to threads which are usually OS based if you want actual parellism and use of all cores. This thread and object promiscuity often leads to race conditions and faulty state management that spreads through the program state, often a kind of creeping death that eventually results in a crash or misbehavior much later on because there is just no way to clean up and recover from faults in a pragmatic way. This is what Joe Armstrongs research and thesis pioneered:

“The central problem addressed by this thesis is the problem of constructing reliable systems from programs which may themselves contain errors. Constructing such systems imposes a number of requirements on any programming language that is to be used for the construction. I discuss these language requirements, and show how they are satisfied by Erlang.”

My view is that unless you believe you and your team have zero defects, infinite sigma quality, 100% perfect, the BEAM really is for you and your users.

In BEAM languages the objects exist with their lifecycle bound to the execution context, the object and its state cannot be mutated by all and sundry in a non serialised way, only the owning process has the state and only it evolves the process/object state in a serialised manner. In other languages it is left up to the programmer to solve the hard synchronisation problems, and they can’t.

Exception handling was tacked onto C++ as an afterthought. It was seen as a necessity because of the horrible C++ constructor approach, as an error in the constructor was nasty, and objects had to initialise their super classes outside the constructor body. This led to two phase object construction where it was bad to do anything that may fail.

The other motives for exceptions was the coding effort for detection of errors and propagation of errors “up” to another code block, method or object, which has not the means to do much about it either without violating all of the encapsulation and understanding what else another object may have done before the exception.

Almost any operator could raise an exception in C++ and the nightmare of exceptions in exception handlers was soon realised.

But they had the similar idea to “let it crash” with “let it throw”, but in reality every code path had to be concerned with cleaning up, and cleaning up differently depending on where and what exception occured when, because the state is divorced from the execution context the code must attempt to maintain valid state every step of the way in the face of goto like exception handlers whilst other threads may also hit the same pot hole or pull the rug out whilst the first thread is in the middle of handling the exception. The combinational explosion of root causes in such systems is frightening and so are the debugging costs.

1
Post #14
sodapopcan

sodapopcan

Ah, thanks, I wasn’t sure so I shouldn’t have speculated.

Very nice post, though, thanks!

I’m one of those “full stack” generalists who really enjoys both frontend and backend work. I’ve been incidentally more backend focused in my career, but that is more incidental than intentional. I never bought into the Angular/React hype (though I thought JSX was a really good idea from the get-go, but I digress) because it made more sense to me, and still does, to favour to the server. I say this because when I was working in Rails, I’d always grab a frontend ticket to avoid doing any work that involved concurrency. When I would have to do it, it was always pretty light stuff, so I’d re-read up on mutexes and semaphores, get the ticket done, then pretty much forget anything I learned by the time I got home. I mean, that’s a bit of a joke, I understand how locks work, but, well, all the things you said are wrong them—it never sat right with me (though, yes, I was not trying too hard). Then I was working on a more heavily concurrent application a few years ago built in a Rude Goldberg mismash of ModernTech™. It was a scheduling application which is already a pretty tough problem that required multiple people to be able to work on the same schedule! That’s around when I started playing with Elixir (though full disclosure, it was LiveView that really got me there) and I was able to prototype a better version of the concurrent part of our app in half a day! TL;DR, your post resonates :slight_smile:

2
Post #15
sodapopcan

sodapopcan

Oh come now, @dimitarvp, you can’t make a jab like that, even in good nature, and not expect me to get dragged back to talking about types :upside_down_face: I absolutely understand the value of types, the only reason I’ve been talking about it so much lately is because this is the first time I’ve felt comfortable talking about it on the internet. Perhaps you were unaware that there are a lot of angry software developers out there :sweat_smile: If you say “I’m ok with dynamic typing because I’ve never really felt any pain” on somewhere like Hacker News, people respond in the extreme to the point that it feels like they’re saying: “Oh, so I guess you also support murdering children, because that’s no worse than not using types.” So I’ve generally stayed out of it.

I’ve also never been able to quite articulate what I enjoy about writing in dynamic languages and a lot of the arguments in favour of dynamic typing I’ve come across online have been really weak. That is, until a recent thread on this forum where there were suddenly a bunch of actual intelligent arguments in favour of it! So that has felt good so I’ve been a bit noisy about it lately. Also the fact that I came to Elixir happy that it was dynamic, and now that is maybe going to change (though I know it’ll be a while).

Do I think string replacement is a better experience than simply hitting “refactor” and filling out some fields? No, of course not. But the verbose way I write code (which I would still want to do even if I had types) makes renames quite fast—I can be finished with a few vim commands, largely thanks to abolish.vim. It’s certainly not as fast as a refactor button, but still pretty fast. I’ve also already said that I find being able to type structs useful!

2
Post #16
dimitarvp

dimitarvp

Haha :003: Okay, fair! Be the kid in the candy store! :heart:

That’s kind of my point, I want us to avoid falling into camps where neither side feels the need to explain well what they like and dislike about their chosen tech while looking down on the other side, and feeling all high and mighty about it. This forum does not stand for that so if I detect a trace of that I call it out. I hope that’s seen as fair as well. Sorry if I projected, I am mostly a pessimist.

On topic, Elixir draws a ton of value from:

  • Pattern-matching;
  • Guards.

Combining these two can nearly eliminate the need for strong types. The problems however are that MANY apps and libraries don’t utilize these well enough so as to properly parse / validate their inputs so we’re back to the eternal dilemma of “if you don’t make something mandatory people will always skip it”.

The balance I found when working with Elixir was to not try-hard everywhere; like, I don’t feel the need to add @spec-s to 99% of the Phoenix files and modules; this stuff is well-known and if you make a mistake you’ll find out about it pretty damn soon.

At the other side of the spectrum though, you have 3rd party API clients where you have to be fairly thorough and make sure you get the right HTTP code, recognize HTTP 429 and back off, make sure the string format you are forced to parse adheres to what you already know so your mini-parser better be coded with the facility to bail early and give detailed explanation as to why, and also you have to make sure you have a mechanism to retry 3 times, and have your custom structs that are being filled after parsing/validating the external data be well-typed and have good constructor function(s) etc. etc.

I was in projects where we had like 10% coverage of @spec-s and we encountered 3 runtime errors in 6 months and 2 of them were because of a junior being onboarded, and the last 3rd was because our upstream API provider figured they’ll sneak a change without telling anyone. We called them out, they fixed their docs, the bug was fixed by my PR something like 40 minutes after their email.

Do strongly statically typed languages help here? Not much, they might not even help at all. At best you’d just make a good parser and serializer using Rust’s amazing serde library/ecosystem and that’s it. You still have to write basically 99% the same code at runtime.

So yeah, Elixir is in a perfect spot: you can opt in to some stricter checks where you truly feel they are needed, and leave the rest alone. And even though I advocate for strong static typing I still write 80% of everything I do in Elixir (though that figure was 90% not that long ago, 2-3 months).

1
Post #17
D4no0

D4no0

I think we have to make a clear distinction when we talk about types here also. Because types in languages like Java and Rust while are same static types, they are inherently different in their core principles, I could even argue that we talk about 2 completely different typing systems from the logical point of view.

There are several reasons I see from my current standpoint:

  1. Types in languages that implemented a correct type system, never mix behavior with data - typing is strictly used to enforce a contract. Languages from Java category use types for classes also, witch enforces a contract over something that contains data as well as behavior, moving to an entire different concept.
  2. Mixing behavior and data, leads to implementation details to leak into the type system - this is most probably where everyone posts about hard to test code, this leads to creation of multiple detached classes in the process, increasing the code size dramatically, this is exactly the reason that you have to use those design patterns in those OOP languages.
  3. Complex tools to deal with the problem - the tools additionally introduced to support for these typed classes, like inheritance, inherently :joy: introduce complexity, because they solve a problem that never needed to be solved in the first place if the concept was constrained correctly.
3
Post #18
dimitarvp

dimitarvp

Yeah, strong agree here: Rust does OOP much better than Java in many ways but mostly those you enumerated: it doesn’t mix behavior and data that much (you still have methods but it’s nowhere near the craziness of inheritance in Java), and the need to use various stuff like factories and dependency injection to deal with deficiencies of the language / the runtime.

1
Post #19
D4no0

D4no0

The rust, golang methods (if they can be called like that) are actually the same as extension methods in languages like java, static functions that receive the reference to base data structure in the parameters, and IMO are more of syntactic sugar for people used to write OOP code, the implementation is a pure function.

0
Post #20
dimitarvp

dimitarvp

Yep. It’s more like a syntactic sugar and an opt-in convenience at best.

The one and true thing Golang and Rust need methods for is their breed of duck typing which works pretty well in both. (Especially Rust traits and Golang’s invisible “if you implement these exact two methods you are now implementing contract / interface X” policy).

0
Post #21