Towards Crystal 1.0
crystal-lang.org
crystal-lang.org
- global inference is more trouble than its worth. some way to opt sections of code out of global inference in exchange for faster compile times and better type error messages would be wonderful
- conflicting/duplicate C bindings in libraries aren’t easy (or even possible sometimes) to reconcile
- a lot of standard library interfaces to system stuff (e.g. sockets) are hard to extend for additional uses. there’s a number of reasons for this, but among them: enums wrapping simple integer based enums, but not actually covering all the values.
- parser is hard to reuse outside of the compiler itself, which is an impediment to making neat tools.
- some strange choices around co/contra-variance when dealing with arrays
I think this is long-gone isn't it? It's local now.
> parser is hard to reuse outside of the compiler itself
A problem we repeat again and again!
module Example
def self.some_method
"string"
end
class Foo
getter :var1
def initialize
@var1 = SomeUtilities.something
end
end
module SomeUtilities
def self.something
Example.some_method
end
def self.do_something_with_string(input : String)
puts input
end
end
end
Example::SomeUtilities.do_something_with_string(Example::Foo.new)
If you change Example.some_method to return :symbol, you now get a type error on the final line.I tried it a few months ago and scry was not giving me any autocomplete in vs code.
I really like the experience working in python in pycharm, mainly for the integrated debugger.
It would be great to see an open source editor for Crystal with proper Debugger support and code reference lookup.
For the last couple of years I've lived pretty much exclusive in the Ruby/RubyMine, Python/PyCharm, Scala/IntelliJ worlds.
However, I recently finished a medium-sized Crystral project only using VSCode. For debugging, I wrote unit tests and kept Sentry running. The compiler pretty much catches everything else. The combination worked out very well.
However "we integrated a CI for Windows to ensure we continue moving steadily forward" sounds like a good compromise for limited resources.
We're also running some rather old code (w old versions of ruby) - and that's obviously not great - but also somewhat worse on windows than on Linux.
All that might make it sounds like ruby on windows is tricky - but it really has gotten quite great, especially after 2.4.
How far away are we from a Windows that can run Unix/POSIX out of the box?
The Windows developer community at large, just like Apple developers, isn't that much into UNIX compatibility layers.
That said, crystal being new, and wsl 1/2 being a thing... I'm à little surprised for the demand for a windows version.
OTOH being able to create a gui rad ide like Lazarus or Delphi, that is cross-platform, compiles to native executables and uses crystal in place of Pascal would probably be great.