Hacker News Reader

Comment by jitl | Hacker News Reader

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.

View on HN

This is what I am trying to solve for with 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.

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

Ruby has types.

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

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 :-(

In runtime. Basically you lose most of the benefits.

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.

> 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?

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

Not just at runtime.

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

"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.

> 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 :)

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.

Incredible, I disagree with just about every point you made. We're not going to make any progress, have a good day.

> "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.

No, that's also entirely subjective. You feel that way, others don't.

> 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?

> 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/ 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.

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.

Reply on news.ycombinator.com