Crystal seems to offer us a preview of what life might be like with a typed Ruby. Types in Crystal are mostly unobtrusive. Performance is nice too. I'm really liking what I see. It's not yet mature and lacks a REPL still but Crystal offers a serious Rubyesque option that I could see gaining some steam.
Consider Static Typing in Ruby
21–30 of 37 posts
Re: Consider Static Typing in Ruby
#22Earlier quoted context omitted.
The bad things about Ruby are mostly Ruby cultural norms, like willy nilly metaprogramming often done by unskilled people, published as a gem, and used by many others, some of whom create useful gems. Static typing would be a benefit. I think Matz realizes that with the rise of Javascript transpilers Ruby is going to have to fight hard to remain relevant. Give Swift a few more months and there is already a pretty sol…
Ruby obviously competes with Node, but is there any chance of Ruby and Swift competing directly? Go or would probably be better examples.
Perhaps you are correct (though I'm curious which languages you'd nominate as more likely contenders).
Re: Consider Static Typing in Ruby
#23So much of what makes Ruby Ruby is based on dynamic types. Is this going to be optional? I've been moving away from Ruby a bit over the years specifically because I want static typing, but I can't imagine that the majority of Ruby devs feel this way. Also isn't Crystal basically a compiled, statically typed version of Ruby?
I've been doing C# after years of Ruby, and every time I find myself needing or wanting to do 'duck typing', what falls out is an interface and then using generics. After years of Ruby, this is so handy because you end up formalising 'on the side' the commonalities of your modelling. I had no idea what generics were for, and I thought interfaces were mostly for over-abstraction but lo, I was wrong. They are very hand…
I completely agree with everything you wrote, that's been my experience as well. I'm also a Ruby guy who's moving a lot of my projects over to .Net. F# is actually what attracted me, but I'm really enjoying C# as well.
Re: Consider Static Typing in Ruby
#24Earlier quoted context omitted.
On Dart's type system: https://www.dartlang.org/articles/optional-types/ https://www.dartlang.org/articles/why-dart-types/
Dart has dynamic typing. Code will not fail on compilation step and in runtime, if type mismatch expectations. You can try to get warnings (at least warnings) with "checked" mode, but it works only with primitive cases, not with closures (no static analysis), so it's mostly useless and better to forget about it. It's only hinting for autocompletion in IDE (although autocompletion is a big thing). Even PHP 5 has stron…
Dart has static analysis as well. There is a server that reports errors and warnings in an IDE, and you can also run it as a batch job using the dartanalyzer command if you like. You can run dartanalyzer in a test, parse the output, and treat warnings as errors, and some people do.
The question is whether the existing static analysis is enough. Some people think it isn't, and the Dart team has a couple of projects to improve on it. See the Dart Development Compiler [1] and linter [2].
The DDC project in particular plans to implement a subset of Dart that makes it easier to check types statically.
This is all supposed to be integrated into the analysis engine using a plugin architecture so that these errors will show up in IDE's and anywhere else you want to display errors.
It's work in progress, as are some of the other type checkers.
[1] https://github.com/dart-lang/dev_compiler [2] https://github.com/dart-lang/linter
Re: Consider Static Typing in Ruby
#25That's really interesting to me. One of the things I like about Ruby its pliability. It's what I'll turn to when I'm just hacking something together, exploring a problem/solution space. But that very pliability becomes an issue when I'm trying to write something that's reliable. There, I'll often use something like Scala, which yells at me when it detects fuzzy thinking on my part. My general approach here is to thro…
In a few years from now we will expect this from every mainstream programming language/platform.
Dart allows you to use gradual typing in production right now, PHP and Python are in the process of adding support for it as well.
Re: Consider Static Typing in Ruby
#26I wish Ruby would focus in immutability before this. As things stand, the language is built in a way that you've no guarantee that any object you hold as variable won't change without you knowing. The net result is you either ignoring the problem entirely (until you runinto a bizarre bug introduced by a new library) or (more rarely) you re-inventing the wheel by being extremely verbose in all accessors where it matte…
Ruby has the .freeze and .clone methods on many types, but in general Ruby expects developers not to monkey with other objects without knowing the consequences.
Re: Consider Static Typing in Ruby
#27As a 10 years Rubyist I'm conflicted about this. First, if I wanted to use a static typed language I have plenty of them to chose from, when I started using Ruby and more right now. One of the reasons I'm using Ruby is that it works well enough without having to tell types to the interpreter (which is already pretty strict about them because - example - it doesn't automatically cast strings and numbers into each othe…
> but if the price to pay is to start declaring types like I did in C and Java, no thanks Modern type systems have such good inference that you won't need to declare types "everwhere."
I know, but I think it's difficult to make static type inference when you can build both the class and the method dynamically. Examples: object.send(expression) or Class.send(expression) are hard enough, building the value of Class at runtime adds extra complication, adding that method only to that object is further along the way of complication. And I'm probably only scratching the surface.
So, either Ruby 3 is so different from Ruby 2 in a way that Python 3 hasn't been from Python 2 or its static typing will be limited to some scenarios. If you do too much metaprogramming you give up using it. Something like using a subset of a language to get some bonus features (example: JS and ASM.js
Re: Consider Static Typing in Ruby
#28I find it interesting that almost all dynamic programming languages eventually get some kind of static type system or type annotations, but very rarely the other way around, C# is the only one i can think of, although i've never seen anyone actually use the dynamic keyword there. PHP, Perl, Python, JS(via typescript or other preprocessors) all got it after years of arguing.
Re: Consider Static Typing in Ruby
#29Earlier quoted context omitted.
Dart has dynamic typing. Code will not fail on compilation step and in runtime, if type mismatch expectations. You can try to get warnings (at least warnings) with "checked" mode, but it works only with primitive cases, not with closures (no static analysis), so it's mostly useless and better to forget about it. It's only hinting for autocompletion in IDE (although autocompletion is a big thing). Even PHP 5 has stron…
Dart has static analysis as well. There is a server that reports errors and warnings in an IDE, and you can also run it as a batch job using the dartanalyzer command if you like. You can run dartanalyzer in a test, parse the output, and treat warnings as errors, and some people do. The question is whether the existing static analysis is enough. Some people think it isn't, and the Dart team has a couple of projects to…
I have quite opposite information from one of Dart authors, as response to my bug report: https://code.google.com/p/dart/issues/detail?id=23148
Sorry for offtopic, ruby devs :)
Re: Consider Static Typing in Ruby
#30As a 10 years Rubyist I'm conflicted about this. First, if I wanted to use a static typed language I have plenty of them to chose from, when I started using Ruby and more right now. One of the reasons I'm using Ruby is that it works well enough without having to tell types to the interpreter (which is already pretty strict about them because - example - it doesn't automatically cast strings and numbers into each othe…
I know this is off topic, but I'm genuinely curious why people refer to themselves in such isolated bins like Rubyist and Pythonistas? Why do you refer to yourself in that way, instead of, say, a developer or programmer or software engineer?