On 1/6/20 2:55 PM, Martin Vidner wrote: > On Fri, Jan 03, 2020 at 11:31:48AM +0100, Josef Reidinger wrote: >> V Fri, 3 Jan 2020 11:14:15 +0100 >> Ancor Gonzalez Sosa <an...@suse.de> napsáno: >>> See more details at https://github.com/ancorgs/y3storage >> >> Hi, this is quite interesting. Especially similarities in testing looks >> nice. I have few questions: >> >> 1. do you compare speed? Is really crystal significantly faster then ruby? >> And what about size? >> 2. how is crystal supported in SLE? Can we easily use it for speed critical >> parts of yast? >> 3. how works bindings to C++? I expect FFI should work fine, but C++ is not >> much FFI friendly. > > Oh, interesting! Thanks for sharing, Ancor. > > Among the motivations why one would be interested in Crystal, I also > care about better type safety. https://crystal-lang.org/ says: > >> Crystal is statically type checked, so any type errors will be >> caught early by the compiler rather than fail on >> runtime. Moreover, and to keep the language clean, Crystal has >> built-in type inference, so most type annotations are unneeded. >> >> All types are non-nilable in Crystal, and nilable variables are >> represented as a union between the type and nil. As a >> consequence, the compiler will automatically check for null >> references in compile time, helping prevent the dreadful >> billion-dollar mistake. > > Are you interested in this?
Definitively, that is one of the most interesting features of Crystal. You can use nil wherever it makes sense, but you should never get a nil in places where you didn't expect it. > Have you found any problems/benefits during the porting so far? I have needed to modify some small things here and there to make obvious for the compiler that some variables can never be nil. But nothing too big so far. Also related to types but not to nil, one of the main changes is that we need to be very explicit about the exact size of the integer variables we use. In particular the ones we used to represent the size of devices (which we always represent internally in bytes). Ruby can represent integers of any size and it will adapt automagically the variable from int32 to int64 or even beyond as the number stored in that variable grows. With Crystal you have to declare the variables as Int64 or UInt64 since the very beginning if you expect those numbers to grow. Again, not a big deal. After my short experience, the type system of Crystal feels like an almost perfect balance between dynamic and static typing. On one hand, the usage of union types gives you a lot of the Ruby's flexibility without going as far as pure duck-typing. On the other hand, the built-in type inference system removes the hassle usually associated to static languages. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscr...@opensuse.org To contact the owner, e-mail: yast-devel+ow...@opensuse.org
