Why people leaving crystal?

Community
21

I get your point and that

it’s of course wrong. But Linux and osX desktop share is less than 20% combined.
This feels skewed because many more software developers use those 2 systems than “normal” people.
If I want to make a program for myself, I use crystal/ruby/whatever makes sense for the thing i’m doing.
If I write something that I think other people might enjoy/find usefull/or even buy, I write it in a way that is either portable across systems, or works for the largest possible number of users.

I don’t want this to be seen

But i felt the need to argue against the notion that windows support is not important, because people can use crystal on OSX/Linux.

One thing that I like to bring up in this context is that there is a good chance that Ruby could have taken the place that python has today, if it would have been as easy to use on windows, and had the same ability to make windows gui applications (back then).

1 Like
22

I believe that Windows support is significant, but it doesn’t affect me much at all. The only Windows box I have is hooked up to a TV as a gaming console with a controller. I would love to see games developed in Crystal, but, also I have absolutely no idea how to do anything programming for Windows, so I won’t be going out and getting another computer to use as a Windows dev box to do anything about it.

To me, it looks like those who develop on/for Windows and therefore should have the required expertise want those who use Mac/Linux to go make it work for them rather than assist in making it happen. Or that’s the feeling I have gotten from seeing this conversation happen many times before.

I am not saying I am getting tired of seeing it or that people should stop bringing it up. New people join the forums all the time and hopefully someday someone with Windows dev experience will see it and go move it along.
I just want you to know that if you are pinning your hope on a Mac/Linux user volunteering to make it work on Windows then you are likely in for a long wait.

So, if you are a Windows dev who would like to see Crystal work well on Windows, please go help make it happen.

6 Likes
23

If more people start to know Crystal Lang and be interested in it, someone of them will improve Crystal support on Windows.
So maybe introduce Crystal Lang to more people will resolve this!

24

same :D

Maybe, but more probably most people who use crystal just are not using windows for development. Which is not really a surprise, because it just became half way usable on windows a couple months ago (?).
So it’s kind of a chicken/egg problem.

In any case Windows support is progressing, and it’ll be here eventually.

1 Like
25

To be clarify:

I am not blame the window support for Crystal, but, obviously, it delay a lot for others more useful feature.

AFAIK, the younger developer (junior or mid-level), heavy relay on the editor features, they are very happy use VSCode with flutter, go, java which those language-server-protocol support very well language, even rust.

I guess most of younger developer even don’t want to play Crystal more than ten minutes, because let them give up those advantage feature which familiar to in the past is very very hard,

  • they are could not bear the slow compilation speed, because they often write error code, the red/green loop is too long,

  • the expected the smart auto complete feature

  • They hope to jump to source code with just a Ctrl+mouse click.

Those feature SHOULD BE BETTER for a 10 years old programming language, if we can make those feature available(if possible, better 2 or 3 years ago), what will Crystal’s day be like today? Looking at rust, we can consider it have a more steep learning curve than Crystal, but people selecting it.

Crystal is a programming language for senior programmers only, though, it have a really kindly, friendly community here, i never want to leave it since i joined three month ago, but, i really consider we are create a wall to prevent fresh blood, no new starter programmer want to select Crystal, i still don’t know if any improvement(or discuss) on this, this really a depressing news.

2 Likes
26

Lack of ecosystem and slow compile time without hot reload.

For the latter, I’m excited to see the release of the interpreter. I don’t care if it makes everything run 50x slower, as long as I don’t need to compile on each change this will be game-changing at least for my web-centric development pipeline.

For the ecosystem, I think many people came from Ruby and tried to implement a Ruby-like library, with more or less success.
I’m guilty myself with my ORM I find too closely related to ActiveRecord with all its caveats.

I think this will slowly but surely mature.

2 Likes
27

So if I understand this correctly, the thought is that if we didn’t work on Windows support, we could have spent that time working on editor extensions.

Sorry, but that’s not true. Crystal is a language for which doing editor extensions like autocompletion, go to definition, etc., that work in a timely manner, is completely impossible in my mind (believe me: I know how the compiler works)

So what else do you want if we didn’t work on Windows support, and also not on editor extensions? What else are you missing?

28

From the feedback of my team, The biggest issue is editor support for a statically typed language, though, ruby as s dynamic language LSP support not well too, but we can try things quickly in ruby.
because it is executed by the interpreter. this is another issue, Crystal compile speed is really too slow,

ruby jump to definition is quite well when use a REPL like pry, as done by robe, i use it daily with Emacs, so when Interpreter mode is maturely, maybe Crystal can do same things, but for now, can we offer a ripper-tag like tools to generate a TAG file for my project, make jump to definition can work partial? check this, it really easy to create a bash script make update TAGS automate.

Another point, is important too, if release 1.0 a year or two early, with a better linux/macOS support, things probably change a lot.

Take me as a example, I probably join here 2019 instead of 2022/05, there is no doubt we use Crystal for web instead of golang, we create more projects use Crystal even for non-web purpose, and contribute on community more early. In fact, i am waiting a language like Crystal(less magic than ruby, null safety) for a long time, but, if not release 1.0.0, i probably still not use Crystal for now.

sure this is just a personal case, i think there still leave a lot of room for improvement, for linux/macOS, those probably really need the core team to help improve it.

The last but not least, for make Crystal famous. we have to thought where is the killer app for Crystal to work hard in that direction, as Ruby on Rails make Ruby known.

1 Like
29
1 Like
30

I’m curious what the technical explanation for this is and what the tradeoff in designing the language that way entailed.

31

Unlike almost every other language, Crystal doesn’t do modular compilation. That is, if you look at a file, you can’t understand it without possible looking at other files. Well, that happens in every other language too. The problem is that there’s no mention in that file about which other files to look at.

Look at this file:

# file "foobarhello.cr"
FooBar.hello

That’s a perfectly valid Crystal file. Does it work? Sure! If it’s required from this file:

# main.cr
module FooBar
  def self.hello
    puts "Hello"
  end
end

require "foobarhello"

So the first problem is that just by looking at a file and trying to do autocomplete, you can’t know what to autocomplete.

But let’s say we just scan all the files in the project so we see what all the types and methods are (though this requires a bit of semantic to expand macros, and for that you need to know which file to being compilation at.)

Then you have a method like this:

def foo(x)
  x.|
end

Here, x.| is the cursor location. What are the possible autocompletions here? It’s impossible to know as types are not mandatory in method signatures.

So I guess we could do autocompletion if method signatures are present.

But then:

def foo(x : Something)
  x.foo.|
end

Let’s say foo is a method defined on Something, but it doesn’t specify a return type (very common!) Now you lose again: you don’t know what to autocomplete.

So in general, unless you explicitly type everything, autocompletion won’t work.

what the tradeoff in designing the language that way entailed

The tradeoff is that you don’t have to specify types. And also slow compilation.

Ideally for Crystal 2.0 or 3.0 types become mandatory, or at least there’s a clear path toward modular compilation.

7 Likes
32

If this is true, We are lost the joy of crystal simplicity.

2 Likes
33

Okay, then choose one: crystal simplicity but no IDE and slow compilation, or crystal like Go/Java/C# with good IDE and fast compilation.

34

Or some magic thingy like Github Copilot will appear in the future and make good autocompletion possible without mandatory types. :smile:

35

I actually don’t think autocompletion would be any worse than, say, template-heavy C++. That doesn’t prevent people from doing it.

x would be of some top type that defines only the pseudo-methods. (This includes types that do not derive from Object, like LibC.) But that doesn’t matter; if the lack of parameter restrictions fails to deduce a method’s return type, and the presence of them leads to a more specific return type, that in itself should encourage people to be more specific in their APIs. It has worked for dynamically typed languages like TypeScript and Python, and hopefully Ruby 3 once IDE services start to utilize Typeprof.

8 Likes
36

The main problem with actual LSP server for Crystal is memory usage (crystal compiler does not utilize garbage collector, right?, it just eats memory), details here: Memory usage · Issue #23 · elbywan/crystalline · GitHub

So… rather Crystal simplicity, proper memory management for the compiler (major rewrite? is it possible?) and OK, slow compilation.

Maybe is still possible (now) to run LSP server tasks in separate processes (which terminates after each compilation) and then serialize some LSP output to the main LSP process, but i don’t know how complex it is (actual AST objects are not seralizable, right?).

Is proper LSP server really unfeasible? The end?

37

I think the compiler genuinely eats that much memory. It would be garbage collected if it was garbage. But it’s just really heavy to have all variables and methods, their possible types and dependencies in memory.

38

If select both of them is really not possible, i prefer simplicity but no IDE and slow compilation.

2 Likes
39

Having worked on Auto-completion for IC, I know is possible, though it couldn’t work on every case because of missing type annotations, but it could be a best effort auto-completion.

It already works on IC for many cases, even for example:

def foo(x)
  x.responds_to?(:[]) ? x[0] : [x]
end

foo(foo([[0]])[foo(foo(0))]).|  # => ?? (Array(Int32))

It works by parsing then executing the semantics on the code. This solve most cases. For inner of functions, I execute the semantics on the body (without instantiate the def), but use the scope of def. (Arguments are not supported yet, but for that I plane to add manually the vars to the MainVisitor from args, with theirs types if defined).

This solution is fast because I’m in the context of the interpreter, so I reuse the same Crystal::Program that contain all defs and types. But for an IDE, that would need to execute the semantics on whole code, plus the prelude, which is slow.

I thinks what could be done to the compiler is to cache the state after the prelude (prelude types, typed target defs, consts, …). This would greatly speed up the semantics phase, especially for small projects. And it doesn’t pose problem if prelude methods are overridden, the initial prelude state would be just overridden.

That would be a good step for incremental compilation I think.

9 Likes
40

mint-lang seem like supported LSP for VSCode since 2021, at least, hover for document and some completion, so, i consider Crystal can support this officially?

BTW, i guess mint-lang can really benefit from Crystal if compiler can generate web assembly binary in the future.

image
image882×617 63 KB

image
image815×410 42.7 KB