Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

T-Ruby is Ruby with syntax for types

type-ruby.github.io

Post reply on HN
Print view View original

111–120 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#111

Post by [deleted] »

sroerick wrote: post #71
shevy-java wrote: post #13

def greet(name: String): String "Hello, #{name}!" end Yep - looks like utter s... I understand that many programmers come from languages where their brain has been adjusted to necessitate and depend on types. And they get help from the compiler in capturing some errors. But it is the wrong way to think about programs and logic. I'd wish these guys would stop trying to ruin existing languages. Go add types somewhere e…

I'm sad you're getting downvoted. This is objectively uglier Ruby code. Ruby is a gorgeous language, and aesthetics is seemingly not allowed in the conversation. I'm not convinced that the time savings of types exist at all, but even if it took twice as long to do anything with types, there is a completely valid argument that "it's worth it to look at nicer code".

[deleted]

Re: T-Ruby is Ruby with syntax for types

#112

Post by bloovis »

pansa2 wrote: post #49
exabrial wrote: post #44

Worth mentioning is Crystal lang: Ruby, with types!

How alike actually are Ruby and Crystal? I’ve heard the similarity is only skin-deep: similar syntax but quite different semantics. In other words, isn’t describing Crystal as “Ruby with types” similar to describing C++ as “JavaScript with types”?

As others have mentioned, Crystal is close to Ruby in many ways, such that some simpler code will port straight over. I've managed to port a large Ruby application (the sup email client) to Crystal, and a lot of the code just worked, but I still had tweak just about everything else to get it to compile. The hardest bits were the places that used Ruby's dynamic nature, e.g., constructing method names at runtime and then calling them with send, or creating methods on the fly, or data structures that mixed up types freely.

Crystal's intent, as I see it, is very different from Ruby's. Because it compiles down to machine code in a single executable, it's good for making things that are fast and easy to deploy. I've used it to make small web services as well as the bigger thing I mentioned above.

Re: T-Ruby is Ruby with syntax for types

#113

Post by michaelbuckbee »

zingar wrote: post #84
ivell wrote: post #73

Earlier quoted context omitted.

One of the big advantages of types is documenting what is *not* allowed. This brings a clarity to the developers and additionally ensure what is not allowed does not happen. Unit tests typically test for behaviours. This could be both positive and negative tests. But we often test only a subset of possibilities just because how people generally think (more positive cases than negative cases). Theoretically we can do…

Just to clarify, are you saying SQLLite is a good example that we should emulate?

SQLite is known for having a lot of testing. Per their docs around 600x as much test as application code.

https://sqlite.org/testing.html

Re: T-Ruby is Ruby with syntax for types

#114

Post by rurban »

ReflectedImage wrote: post #85
matteotom wrote: post #5

Earlier quoted context omitted.

At least for Python (since I'm more familiar with Python code and the Python ecosystem): progressive typing lets you incrementally add typing to an existing Python codebase. So you can have at least some of the benefits of typing for new or updated code without needing to re-write in a new language.

Gradual typing is the worse of both worlds. You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.

Nonsense. You get the simplification and faster development times of knowing some variable types statically, plus the performance improvements for the compiler which can move the type checks from runtime to compile-time. Plus all the new optimization possibilities.

Common Lisp showed you the way. But almost none looked at it. Only PHP did.

Re: T-Ruby is Ruby with syntax for types

#115

Post by vidarh »

mrinterweb wrote: post #62
shevy-java wrote: post #18

Earlier quoted context omitted.

> the best point for developer productivity IMO. That is a fair opinion. My opinion is different, but that's totally fine - we have different views here. What I completely disagree with, though, is this statement: > Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. I have been writing ruby code since…

The times I've been bitten by type safety issues is far less than the hassle of maintaining types. Seriously, it is a much smaller issue than people make it out to be. I will say that I do get bitten by the occasional `NoMethodError` on `nil`, but it really doesn't happen often. Since ruby is very dynamic it is hard to say how many of those errors would be caught even with type annotation. I also don't find myself ne…

I would strongly oppose mandatory typing for these reasons, but I'm very happy to have stable low level libraries add type annotations.

Re: T-Ruby is Ruby with syntax for types

#116

Post by Fire-Dragon-DoL »

torben-friis wrote: post #3

Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?

It is desirable to have types at the entrypoints and at IO usually. Even rails has validations and SQL has schemas , or there are file formats

Re: T-Ruby is Ruby with syntax for types

#118

Post by dajonker »

shevy-java wrote: post #18
MGriisser wrote: post #7

Earlier quoted context omitted.

(I'm not sure if this still holds under a world where LLMs are doing the majority of writing code but this is my opinion from prior to LLMs) From someone who has worked mostly in Ruby (but also Perl and TypeScript and Elixir) I think for web development, a dynamic language with optional types actually hits maybe the best point for developer productivity IMO. Without any types in a dynamic language, you often end up w…

> the best point for developer productivity IMO. That is a fair opinion. My opinion is different, but that's totally fine - we have different views here. What I completely disagree with, though, is this statement: > Without any types in a dynamic language, you often end up with code that can be quite difficult to understand what kinds of objects are represented by a given variable. I have been writing ruby code since…

Well said. There are many problems you have to deal with when writing code and type annotations only solve one particular kind. And even type annotations can be wrong: when you're dealing with data from external sources, dynamic languages like Python, JavaScript and Ruby will happily parse any valid JSON into a native data structure, even if it might not be what you specified in your type hints. Worse yet, you may not even notice unless you also have runtime type checks.

The kind of messy code base that results from (large) numbers of (mediocre) developers hastily implementing hacky bug fixes and (incomplete) specifications under time pressure isn't necessarily solved by any technical solution such as type hints.

Re: T-Ruby is Ruby with syntax for types

#119

Post by Hasnep »

ReflectedImage wrote: post #82
pie_flavor wrote: post #77

Earlier quoted context omitted.

This is junk. Writing a type annotation takes basically zero time, then saves you time by preventing the runtime error because you forgot which variable was which, then saves you more time by autocompleting the correct list of valid methods when you hit dot. Acting like Go is comparable to JS is ridiculous; Go's type system is the only kind of type system needed in Ruby. Rust is a staggering outlier in complexity. An…

Making the type annotations pass restricts you to writing more bloated and verbose programs in general. Stating that A is an integer isn't much of a issue but once you get a reasonably complex program and A now has a compound type made of 5 parts, it really does slow you down and it really does make you write considerably worse programs for the sake of passing a type checker. Any commercial code will need to be unit…

It seems like your main gripe is that writing the type annotations slows you down, so I'd be interested to know what you think of languages like OCaml, Elm, Gleam or Roc. These are languages which never (or almost never) require any type annotations because the compiler can always infer all the types. Most people using these languages tend to add type annotations to top-level functions anyway though.

It seems to me that this is equivalent to a language without a type checker that automatically generates a unit test for every line of your program that tests its type.

Re: T-Ruby is Ruby with syntax for types

#120

Post by honeycrispy »

rauli_ wrote: post #89

I remember a time in early 2000s when everybody seemed to be raving about duck typed languages and how awesome they are. Now we have separate tools for the same languages to implement typing.

We were raving about new atheism too. Bad ideas come and go.
Post reply on HN