8 ms·

For those of you who are interested by Elixir but find the lack of static typing an issue here are somethings to be aware of: 1. Static Typing is planned and c

For those of you who are interested by Elixir but find the lack of static typing an issue here are somethings to be aware of: 1. Static Typing is planned and currently the top priority of the team https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... 2. There is a type checking tool https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir 3. You can go a long way with pattern matching and guides in the meantime and have alot more guarantees that a typical dynamic typed language.

sbjs 3y ago
I'm glad we're in the age of static typing. The age of dynamic typing as a response to incorrect static typing was a necessary evil. We had to take a break from broken languages in order to realize what needed to be fixed in those languages. I'm convinced that JavaScript will eventually be one of the best, fastest, and safest languages, as long as we keep this cycle up of abandoning necessary languages and returning to them with very thorough fixes to much better understood and detailed problems with them.
- hosh 3y ago
  I'm convinced that until Javascript makes it easy to do the right thing by default (instead of its current state of doing many wrong things by default) the Javascript ecosystem will continue to have a lot of low-quality library code intermixed with a few high-quality ones. My neutral regard for JS had rapidly degraded when I had to actually start writing code in it or understanding code others have written.
  - sbjs 3y ago
    What ways does do the wrong things by default? I can't think of a single one. You might say, well, == is broken and you have to use ===, but that's not "the wrong thing by default" unless you assume that == is what ought to be the default operator and === ought to be secondary. But that assumption has to come from somewhere, and probably comes from the fact that other languages do it that way. But there's nothing inherently incorrect about === being the default operator and == being the rare secondary one. I think the same principle applies to any example you might be able to give me: if you assume that another language is objectively right, only then can you say that JavaScript is objectively wrong in comparison to that language which apparently descended from the heavens.
    - david422 3y ago
      Well === was added to make up for deficiencies in == so seems reasonable that saying == is the default that does things incorrectly.
    - wtetzner 3y ago
      I would argue that implicit conversions in a dynamically typed language is a mistake in general. It's the "wrong thing by default" in the sense that it's too easy to write broken code by accident. And I think that's what is usually meant by "wrong thing by default". I think if you really want implicit conversions, then you want to do what Perl does (never thought I'd say that): different operators for different types.
    - mjburgess 3y ago
      You're assuming a certain sort of perspectivalism: the only reasons X could be better than Y is that, from someone's pov, some language has X. This is kinda insane. People can give reasons X is better than Y on grounds of various theoretical virtues of X -- that has nothing to do with a preference for any language. Here's an example virute: Behaviour should be consistent unless specialised. When specialised it should be obvious which specialisation is chosen. (Violation: basically all of js' operators).
    - airstrike 3y ago
      Exhibit A: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
    - claytongulick 3y ago
      It's pretty easy to footgun when you're mixing event/callback based flow with promises/async. It's really easy to forget a closure in an event driven function and to produce difficult to debug, error prone code. A classic example I just screwed up: export function getSFTPConnection(options) { let key = readFileSync(options.keyfile_path, 'utf8'); let ssh = new ssh2.Client(); return new Promise( (resolve, reject) => { ssh.on('error', reject); ssh.on('ready', () => { ssh.sftp((err, sftp) => { resolve(sftp); }); }); ssh.on('close', (err) => { reject(new Error('SSH connection closed: ' + err)); }) ssh.connect( { host: options.host, username: options.username, privateKey: key, } ); } ) } The bug here isn't obvious, at least to me - but it caused me much heartache and pain because I was moving too fast and not thinking - but a good example of unexpected behavior by default. The bug is that there's not a closure around the ssh instance, so if you call this function multiple times it'll actually return the same connection instance. The extra fun part of this bug is that the code worked - but because I was using the same instance, when I'd download multiple files in parallel, it would interleave the data, corrupting the files. And the thing is, I know better. I've been doing js for decades. I love js, but stuff like this is pretty frustrating, and can be a nightmare for new devs.
- frou_dh 3y ago
  Maybe it's just me but there's something fundamentally unappealing about bolt-on static type-systems on top of pre-existing dynamic languages. Sure, what's come about with e.g. TypeScript is pragmatic and very useful, but if imagining a future utopia then TS/JS++ and similar would not feature in the dream.
  - sbjs 3y ago
    Why not? I can't think of anything off the top of my head that I think is fundamentally broken about TypeScript, or even that I strongly dislike about it.
    - LadyCailin 3y ago
      Its type system is apparently Turing complete. That’s a pretty major flaw, imo. Meaning that static analysis isn’t always possible.
      - consilient 3y ago
        Turing complete type systems are extremely common. C#, C++, Java - it's hard to avoid if you have subtyping and generics. In practice it almost never comes up.
    - frou_dh 3y ago
      - Too many statements instead of expressions. - Lacks structural pattern-matching. - Lacks first-class sum-types (although they can be clumsily encoded as objects with "kind" properties). - Static type-checking not directly (or at all) contributing to the execution performance of the code. This is particularly egregious with e.g. CPython. Presence of the first three are the sort of things that people appreciate in Good static languages (as opposed to the status quo static languages you alluded to that Python/Ruby/JS/etc were rebelling against in the 2000s). The last is the dead giveaway of not utopia but rather a bizarre compromised situation.
      - wtetzner 3y ago
deleted 3y ago
[deleted]
rdevsrex 3y ago
Interesting, will check out. I am still evaluating Gleam, a language that's targets beam, but the compiler is written in Rust. It has actual strong typing, and I rather like it's Rust like syntax.
- eggy 3y ago
  I was too until they strayed from the more Standard ML-like syntax to Rust-like syntax all for trying not to alienate the Algol crowd and Rust aficionados. For popularity. I like APL, BQN, and J so I'm not swayed by it.
- bnchrch 3y ago
  I really like Gleam, and I am a huge fan of more being built on the EVM. Personally I want the EVM to (eventually) get the same level of adoption and mindshare as the JVM. And currently wider Elixir use/education seems like the path to that.
  - comex 3y ago
    EVM is the Ethereum Virtual Machine. You mean BEAM, right?
    - yellowapple 3y ago
      EVM stood for "Erlang Virtual Machine" (of which BEAM is one implementation) before Ethereum even existed.
      - octacat 3y ago
        Except majority of people uses BEAM name for the last 13 years. Erlang VM or Erlang Virtual Machine is ok too. EVM name is just super not-popular, idk why.
        yellowapple 3y ago
        Erlang's creators use EVM, which is where I learned it from. Not sure why it didn't catch on, either; I guess for a long-enough while BEAM was the only EVM implementation in common use, so it became the Xerox™ or Velcro™ of Erlang virtual machines lol
arturkane7 3y ago
What’s currently the best static typed language for web development?
- bnchrch 3y ago
  Typescript, by a large and deserved margin.
  - ak_111 3y ago
    Should have added other than Typescript :)
    - bnchrch 3y ago
      Then I would vote Go (best stdlib in the business), then Java.
  - weatherlight 3y ago
    It's not sound :(. Type systems should be bomb proof or get out of the way.
    - deleted 3y ago
      [deleted]
    - mjhay 3y ago
      Typescript's unsoundness isn't a good thing, but it is way down the list of type-unsafe things inherent in the Boschian nightmare that is frontend development. Compile-to-JS languages add a big impedance mismatch when you inevitably need to use JS libs. Typescript's JS + types philosophy helps with this issue (it still sucks though).
- deathtrader666 3y ago
  Rescript
- giraffe_lady 3y ago
  ReScript is excellent. Same type system as ocaml, which is IMO the sweet spot between power and straightforwardness. You lose the "you can represent ANYTHING" capability of TS which is both a pro and a con. In exchange it's much simpler to work with and has excellent type inference for day to day work. The externals binding system for JS libs works well for integrating libraries. And react bindings are included in the standard lib, they also work great. The compiler is fast and produces generally quite reasonable JS. You could argue that it's not "better" than elm in a theoretical sense. But for practical work it's much closer to the mainstream of web dev in mindset and syntax. Easier to learn, much easier to integrate with other frameworks or into existing teams & codebases. And it's less opinionated about rendering: the tooling generally assumes you're using react, but you don't have to and it can emit anything if you do some extra work wiring it up. I have used it with node and even, irresponsibly, deno fresh. Been using it whenever I can for frontend stuff for a year now and haven't enjoyed a language this much since... well... elixir.
choiway 3y ago
I do like me some static typing but it took me a while to realize that the guards and pattern matching provides runtime guarantees and not just compile time guarantees.
- pjerem 3y ago
  In theory, compile time guarantees renders runtime guarantees useless as long as you don’t interact with untyped code.
callamdelaney 3y ago
Everybody knows elixir is ass, just use Erlang.

sbjs 3y ago

I'm glad we're in the age of static typing. The age of dynamic typing as a response to incorrect static typing was a necessary evil. We had to take a break from broken languages in order to realize what needed to be fixed in those languages. I'm convinced that JavaScript will eventually be one of the best, fastest, and safest languages, as long as we keep this cycle up of abandoning necessary languages and returning to them with very thorough fixes to much better understood and detailed problems with them.

hosh 3y ago
I'm convinced that until Javascript makes it easy to do the right thing by default (instead of its current state of doing many wrong things by default) the Javascript ecosystem will continue to have a lot of low-quality library code intermixed with a few high-quality ones. My neutral regard for JS had rapidly degraded when I had to actually start writing code in it or understanding code others have written.
- sbjs 3y ago
  What ways does do the wrong things by default? I can't think of a single one. You might say, well, == is broken and you have to use ===, but that's not "the wrong thing by default" unless you assume that == is what ought to be the default operator and === ought to be secondary. But that assumption has to come from somewhere, and probably comes from the fact that other languages do it that way. But there's nothing inherently incorrect about === being the default operator and == being the rare secondary one. I think the same principle applies to any example you might be able to give me: if you assume that another language is objectively right, only then can you say that JavaScript is objectively wrong in comparison to that language which apparently descended from the heavens.
  - david422 3y ago
    Well === was added to make up for deficiencies in == so seems reasonable that saying == is the default that does things incorrectly.
  - wtetzner 3y ago
    I would argue that implicit conversions in a dynamically typed language is a mistake in general. It's the "wrong thing by default" in the sense that it's too easy to write broken code by accident. And I think that's what is usually meant by "wrong thing by default". I think if you really want implicit conversions, then you want to do what Perl does (never thought I'd say that): different operators for different types.
  - mjburgess 3y ago
    You're assuming a certain sort of perspectivalism: the only reasons X could be better than Y is that, from someone's pov, some language has X. This is kinda insane. People can give reasons X is better than Y on grounds of various theoretical virtues of X -- that has nothing to do with a preference for any language. Here's an example virute: Behaviour should be consistent unless specialised. When specialised it should be obvious which specialisation is chosen. (Violation: basically all of js' operators).
  - airstrike 3y ago
    Exhibit A: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
  - claytongulick 3y ago
    It's pretty easy to footgun when you're mixing event/callback based flow with promises/async. It's really easy to forget a closure in an event driven function and to produce difficult to debug, error prone code. A classic example I just screwed up: export function getSFTPConnection(options) { let key = readFileSync(options.keyfile_path, 'utf8'); let ssh = new ssh2.Client(); return new Promise( (resolve, reject) => { ssh.on('error', reject); ssh.on('ready', () => { ssh.sftp((err, sftp) => { resolve(sftp); }); }); ssh.on('close', (err) => { reject(new Error('SSH connection closed: ' + err)); }) ssh.connect( { host: options.host, username: options.username, privateKey: key, } ); } ) } The bug here isn't obvious, at least to me - but it caused me much heartache and pain because I was moving too fast and not thinking - but a good example of unexpected behavior by default. The bug is that there's not a closure around the ssh instance, so if you call this function multiple times it'll actually return the same connection instance. The extra fun part of this bug is that the code worked - but because I was using the same instance, when I'd download multiple files in parallel, it would interleave the data, corrupting the files. And the thing is, I know better. I've been doing js for decades. I love js, but stuff like this is pretty frustrating, and can be a nightmare for new devs.
frou_dh 3y ago
Maybe it's just me but there's something fundamentally unappealing about bolt-on static type-systems on top of pre-existing dynamic languages. Sure, what's come about with e.g. TypeScript is pragmatic and very useful, but if imagining a future utopia then TS/JS++ and similar would not feature in the dream.
- sbjs 3y ago
  Why not? I can't think of anything off the top of my head that I think is fundamentally broken about TypeScript, or even that I strongly dislike about it.
  - LadyCailin 3y ago
    Its type system is apparently Turing complete. That’s a pretty major flaw, imo. Meaning that static analysis isn’t always possible.
    - consilient 3y ago
      Turing complete type systems are extremely common. C#, C++, Java - it's hard to avoid if you have subtyping and generics. In practice it almost never comes up.
  - frou_dh 3y ago
    - Too many statements instead of expressions. - Lacks structural pattern-matching. - Lacks first-class sum-types (although they can be clumsily encoded as objects with "kind" properties). - Static type-checking not directly (or at all) contributing to the execution performance of the code. This is particularly egregious with e.g. CPython. Presence of the first three are the sort of things that people appreciate in Good static languages (as opposed to the status quo static languages you alluded to that Python/Ruby/JS/etc were rebelling against in the 2000s). The last is the dead giveaway of not utopia but rather a bizarre compromised situation.
    - wtetzner 3y ago

deleted 3y ago

[deleted]

rdevsrex 3y ago

Interesting, will check out. I am still evaluating Gleam, a language that's targets beam, but the compiler is written in Rust. It has actual strong typing, and I rather like it's Rust like syntax.

eggy 3y ago
I was too until they strayed from the more Standard ML-like syntax to Rust-like syntax all for trying not to alienate the Algol crowd and Rust aficionados. For popularity. I like APL, BQN, and J so I'm not swayed by it.
bnchrch 3y ago
I really like Gleam, and I am a huge fan of more being built on the EVM. Personally I want the EVM to (eventually) get the same level of adoption and mindshare as the JVM. And currently wider Elixir use/education seems like the path to that.
- comex 3y ago
  EVM is the Ethereum Virtual Machine. You mean BEAM, right?
  - yellowapple 3y ago
    EVM stood for "Erlang Virtual Machine" (of which BEAM is one implementation) before Ethereum even existed.
    - octacat 3y ago
      Except majority of people uses BEAM name for the last 13 years. Erlang VM or Erlang Virtual Machine is ok too. EVM name is just super not-popular, idk why.
      - yellowapple 3y ago
        Erlang's creators use EVM, which is where I learned it from. Not sure why it didn't catch on, either; I guess for a long-enough while BEAM was the only EVM implementation in common use, so it became the Xerox™ or Velcro™ of Erlang virtual machines lol

arturkane7 3y ago

What’s currently the best static typed language for web development?

bnchrch 3y ago
Typescript, by a large and deserved margin.
- ak_111 3y ago
  Should have added other than Typescript :)
  - bnchrch 3y ago
    Then I would vote Go (best stdlib in the business), then Java.
- weatherlight 3y ago
  It's not sound :(. Type systems should be bomb proof or get out of the way.
  - deleted 3y ago
    [deleted]
  - mjhay 3y ago
    Typescript's unsoundness isn't a good thing, but it is way down the list of type-unsafe things inherent in the Boschian nightmare that is frontend development. Compile-to-JS languages add a big impedance mismatch when you inevitably need to use JS libs. Typescript's JS + types philosophy helps with this issue (it still sucks though).
deathtrader666 3y ago
Rescript
giraffe_lady 3y ago
ReScript is excellent. Same type system as ocaml, which is IMO the sweet spot between power and straightforwardness. You lose the "you can represent ANYTHING" capability of TS which is both a pro and a con. In exchange it's much simpler to work with and has excellent type inference for day to day work. The externals binding system for JS libs works well for integrating libraries. And react bindings are included in the standard lib, they also work great. The compiler is fast and produces generally quite reasonable JS. You could argue that it's not "better" than elm in a theoretical sense. But for practical work it's much closer to the mainstream of web dev in mindset and syntax. Easier to learn, much easier to integrate with other frameworks or into existing teams & codebases. And it's less opinionated about rendering: the tooling generally assumes you're using react, but you don't have to and it can emit anything if you do some extra work wiring it up. I have used it with node and even, irresponsibly, deno fresh. Been using it whenever I can for frontend stuff for a year now and haven't enjoyed a language this much since... well... elixir.

choiway 3y ago

I do like me some static typing but it took me a while to realize that the guards and pattern matching provides runtime guarantees and not just compile time guarantees.

pjerem 3y ago
In theory, compile time guarantees renders runtime guarantees useless as long as you don’t interact with untyped code.

callamdelaney 3y ago

Everybody knows elixir is ass, just use Erlang.