Hacker News Reader

Comment by nemothekid | Hacker News Reader

I'm pretty sure, as far as type systems go, Elixir is strongly typed as well as fairly functional (It's built on BEAM after all).

I think it has to do more with the latter. To me, Scala is too powerful - it rivals C++ in complexity, despite being half it's age. It almost feels like every Scala codebase is written in a different language, and I always felt I spent more time parsing Scala than understanding the code. It's a powerful language to write, but hard to read - almost the complete polar opposite of Go. As a result it can be very hard to bring new engineers up to scala, and even engineers that know Scala have to learn "your flavor" of Scala.

View on HN

I know what you mean. Even things like error handling in Scala have divergent paradigms, to the point where we had one Scala consultant at the company I worked for using exceptions, and another trying to use Eithers.

I have to say though, coming from a C++ background, Scala still feels much more beautiful, clean, and safe than C++... but then, almost everything does ;)

Elixir is dynamically typed, just like Erlang and the BEAM. Strong typing is a most requested feature from outside the community, seldom from inside. (EDIT correct, strong typing is not static typing. Does anyone make weakly typed languages anymore?)

According to wikipedia, Erlang/Elixir is strongly typed. I guess you and the other poster mean static typing?

https://elixir-lang.org/getting-started/typespecs-and-behavi...

Elixir is a dynamically typed language, so all types in Elixir are inferred by the runtime.

You may be confusing strongly and statically typed.

There's no reason a language can't be both strongly and dynamically typed (like Elixir or Python) or statically and weakly typed (like C). :)

Strongly typed meaning that Elixir/Erlang don't allow:

  1 + "some string" + [A,List,Of,Somethings]

Compared to javascript where:

  1 + "2" == "12"

Statically typed means that variables and functions hold or return specific types which can be determined before execution.

Type coercion does not equal weak typing -- I submit JS and Perl as examples where types are strong but there is a coercion protocol dependent on which types an operator expects around it.

Fair, C may have been a better example. Where nearly everything is actually just a block of bytes of various lengths and can be intermingled fairly freely with minimal effort to get anything past the compiler.

Sometimes useful, but the type system ends up offering few meaningful protections as a consequence.

The types of values and legal conversions between them are well defined in C -- the assumption that everything is just a block of bytes and hence may be casted freely between types is explicitly incorrect (and is what may lead to bad/invalid C code).

However, C does allow you to write code that can not proven to be legal with respect to the formal system of the language and get it to compile, I think that is what you are referring to.

But just because you can write an invalid program does not mean the type system doesn't exist or is flawed. I can also write an invalid Haskell program.

The difference between these two would be that the haskell program can be proven to contain only operations that map to well-defined operations in the formal language model by an automated process, while the same can not be done for C in the general case.

However, just because you can not always prove conformance to a formal model using automated means, doesn't mean that no formal model exists (because it does!).

If we are being pedantic, what is going on here is not type coercion.

If it were type coercion, we would expect the add function to have either of these two behaviours:

  - coerce the input arguments to strings, i.e. implicitly accept two strings and return another string

  - coerce the input arguments to integers, i.e. implicitly accept two integers and return an integer

However, that is not what is happening here.

Of course, in Javascript it is implemented as a function that takes the theoretical "Any" type and decides what do do at runtime. But in a statically type language, the equivalent mechanism would be dynamic/multiple dispatch (or a static overload, possibly in combination with a generic/template method) -- not type coercion.

The result add(1: Int, "2": String) -> "12": String can be achieved in any language, regardless of how strict the type system is. All your example shows is that in elxir no such `add(int, string)` operation is provided as part of the standard library/environment, while in javascript, it is.

The "+" (operator) case is only special in languages that do not implement operator overloading -- it is completely orthogonal to the type system.

> Does anyone make weakly typed languages anymore?

I don't think anybody ever did. The definition of "strong" and "weak" seem to be entirely subjective; and of course everybody considers their favourite language to be "strongly typed". It's like a reverse no-true-scotsman.

Reply on news.ycombinator.com