4 ms·

I don’t want to build in a language without types, but low code is even less types than Rails. I’ve just never worked on a public app that was simple enough for

by jitl 2y ago

I don’t want to build in a language without types, but low code is even less types than Rails. I’ve just never worked on a public app that was simple enough for Rails to feel good - Airbnb was rails but by the time I got there it was very much not simple. Internal tools in rails though, that is okay.

darepublic 2y ago
I expect low code that can be translated into typed clean code. The low code side of it is just with more assumptions baked in. And with llms you can perhaps have a lot of leeway to in fact customize and allow low or no coders to specify somethinf exportable to readable typed code
ajayvk 2y ago
This is what I am trying to solve for with https://github.com/claceio/clace https://github.com/claceio/clace. Allow internal tools to be built with regular frameworks, while making it easy to add gitops, SSO, secrets management etc which are required for internal tools.
wordofx 2y ago
[flagged]
Zambyte 2y ago
Ruby is strongly typed. Dynamic typing and inferred typing are not the same as typeless. B and Forth are examples of typeless languages.
- lolinder 2y ago
  "Strongly typed" is not a well defined term—it basically means "I'm personally comfortable with the level of guarantees offered by the language", which is a purely subjective measurement. In context it's obvious that what OP meant is that they wouldn't want to build in a language without statically-checked types. That there are languages that provide even fewer statically-analyzable guarantees than Ruby does not make Ruby a suitable candidate.
  - cies 2y ago
    > "Strongly typed" is not a well defined term True. But it has boundaries. Strongly typed cannot be used for langs with implicit nulls. You need to do better than stock C, C++, Java or Go to be able to use the term. Rust, Elm, Haskell, Kotlin and OCaml come to mind.
    - lolinder 2y ago
      No, that's also entirely subjective. You feel that way, others don't.
    - lelanthran 2y ago
      > True. But it has boundaries. Strongly typed cannot be used for langs with implicit nulls. You need to do better than stock C, C++, Java or Go to be able to use the term. That's, frankly, an insane boundary. According to you, all mainstream languages are untyped? Seriously?
  - Zambyte 2y ago
    > In context it's obvious that what OP meant is that they wouldn't want to build in a language without statically-checked types. They should say that then. "Dynamically typed language" is not much harder to say or write than "typless language", but is correct instead of being incorrect. And that is a well defined term :)
    - lolinder 2y ago
      Most academics would agree with them that dynamically typed languages are a misnomer and in fact have no type system. And whether you want to use the colloquial term that counts dynamically typed languages or the academic one that doesn't is a subjective decision, and one where their choice was clear from context. More generally, advocates of dynamically typed languages seem to want their languages to be considered typed because there's a developing consensus that typed is better. Unfortunately for said advocates, that consensus was not developed in contrast to languages like Forth, it was developed in contrast to languages like Ruby, so changing the definition of a type system to accommodate Ruby doesn't actually get you credibility in the new "cool kids club". You're better off arguing why dynamic is better than static than you are trying to enforce a particular definition of types. No one is going to be persuaded that Ruby meets their needs just because you made them use your definition.
stephen 2y ago
> don't want to build in a language w/o types Yep; that's the only reason I don't use Rails. I'm building "ActiveRecord but with type(script)" at https://joist-orm.io/ https://joist-orm.io/ and have our own internal "kinda Rails w/GraphQL" going internally--so far we're at ~450 tables and still "feeling good" (no n+1s ever!), but definitely a long way to go before AirBNB-sized problems.
- cies 2y ago
  I hate ORMs, as you still need to break out to SQL regularly: why bother? I'd go with Kotlin/SqlDelight or Rust/sqlx (or even jOOQ) these days to avoid having to deal with the overhead of an ORM.
mattmcknight 2y ago
Ruby has types.
- nicce 2y ago
  In runtime. Basically you lose most of the benefits.
  - fulafel 2y ago
    Before lightly using this argument I recommend using a language that really doesn't have types. The difference between getting your errors at runtime / compile time is much much smaller than the difference between those and not getting errors at all.
    - lelanthran 2y ago
      > Before lightly using this argument I recommend using a language that really doesn't have types. I am curious now: which language doesn't have types but has a separate compile-time?
      - fulafel 2y ago
        I don't know that having separate compile-time is relevant for the experience. But Forth, assembler, B and BCPL. TCL also seems to have a compiler: https://www.tcl.tk/software/tclpro/compiler.html https://www.tcl.tk/software/tclpro/compiler.html
  - mattmcknight 2y ago
    Not just at runtime.
- jitl 2y ago
  Whenever I google to see if people are enjoying Sorbet or RBS I find articles like this that basically say “no, no one seems to be enjoying this and it’s going nowhere” https://brandur.org/fragments/ruby-typing-2024 https://brandur.org/fragments/ruby-typing-2024 In my opinion RBS files are a horrible design decision and split the Ruby community between a typing system that people actually want to use (Sorbet) and a typing system we’ll tolerate because it’s official but a pain in the ass (RBS), leaving both ecosystems to whither. Sad :-(

by jitl 2y ago

darepublic 2y ago

I expect low code that can be translated into typed clean code. The low code side of it is just with more assumptions baked in. And with llms you can perhaps have a lot of leeway to in fact customize and allow low or no coders to specify somethinf exportable to readable typed code

ajayvk 2y ago

This is what I am trying to solve for with https://github.com/claceio/clace https://github.com/claceio/clace. Allow internal tools to be built with regular frameworks, while making it easy to add gitops, SSO, secrets management etc which are required for internal tools.

wordofx 2y ago

[flagged]

Zambyte 2y ago

Ruby is strongly typed. Dynamic typing and inferred typing are not the same as typeless. B and Forth are examples of typeless languages.

lolinder 2y ago
"Strongly typed" is not a well defined term—it basically means "I'm personally comfortable with the level of guarantees offered by the language", which is a purely subjective measurement. In context it's obvious that what OP meant is that they wouldn't want to build in a language without statically-checked types. That there are languages that provide even fewer statically-analyzable guarantees than Ruby does not make Ruby a suitable candidate.
- cies 2y ago
  > "Strongly typed" is not a well defined term True. But it has boundaries. Strongly typed cannot be used for langs with implicit nulls. You need to do better than stock C, C++, Java or Go to be able to use the term. Rust, Elm, Haskell, Kotlin and OCaml come to mind.
  - lolinder 2y ago
    No, that's also entirely subjective. You feel that way, others don't.
  - lelanthran 2y ago
    > True. But it has boundaries. Strongly typed cannot be used for langs with implicit nulls. You need to do better than stock C, C++, Java or Go to be able to use the term. That's, frankly, an insane boundary. According to you, all mainstream languages are untyped? Seriously?
- Zambyte 2y ago
  > In context it's obvious that what OP meant is that they wouldn't want to build in a language without statically-checked types. They should say that then. "Dynamically typed language" is not much harder to say or write than "typless language", but is correct instead of being incorrect. And that is a well defined term :)
  - lolinder 2y ago
    Most academics would agree with them that dynamically typed languages are a misnomer and in fact have no type system. And whether you want to use the colloquial term that counts dynamically typed languages or the academic one that doesn't is a subjective decision, and one where their choice was clear from context. More generally, advocates of dynamically typed languages seem to want their languages to be considered typed because there's a developing consensus that typed is better. Unfortunately for said advocates, that consensus was not developed in contrast to languages like Forth, it was developed in contrast to languages like Ruby, so changing the definition of a type system to accommodate Ruby doesn't actually get you credibility in the new "cool kids club". You're better off arguing why dynamic is better than static than you are trying to enforce a particular definition of types. No one is going to be persuaded that Ruby meets their needs just because you made them use your definition.

stephen 2y ago

> don't want to build in a language w/o types Yep; that's the only reason I don't use Rails. I'm building "ActiveRecord but with type(script)" at https://joist-orm.io/ https://joist-orm.io/ and have our own internal "kinda Rails w/GraphQL" going internally--so far we're at ~450 tables and still "feeling good" (no n+1s ever!), but definitely a long way to go before AirBNB-sized problems.

cies 2y ago
I hate ORMs, as you still need to break out to SQL regularly: why bother? I'd go with Kotlin/SqlDelight or Rust/sqlx (or even jOOQ) these days to avoid having to deal with the overhead of an ORM.

mattmcknight 2y ago

Ruby has types.

nicce 2y ago
In runtime. Basically you lose most of the benefits.
- fulafel 2y ago
  Before lightly using this argument I recommend using a language that really doesn't have types. The difference between getting your errors at runtime / compile time is much much smaller than the difference between those and not getting errors at all.
  - lelanthran 2y ago
    > Before lightly using this argument I recommend using a language that really doesn't have types. I am curious now: which language doesn't have types but has a separate compile-time?
    - fulafel 2y ago
      I don't know that having separate compile-time is relevant for the experience. But Forth, assembler, B and BCPL. TCL also seems to have a compiler: https://www.tcl.tk/software/tclpro/compiler.html https://www.tcl.tk/software/tclpro/compiler.html
- mattmcknight 2y ago
  Not just at runtime.
jitl 2y ago
Whenever I google to see if people are enjoying Sorbet or RBS I find articles like this that basically say “no, no one seems to be enjoying this and it’s going nowhere” https://brandur.org/fragments/ruby-typing-2024 https://brandur.org/fragments/ruby-typing-2024 In my opinion RBS files are a horrible design decision and split the Ruby community between a typing system that people actually want to use (Sorbet) and a typing system we’ll tolerate because it’s official but a pain in the ass (RBS), leaving both ecosystems to whither. Sad :-(