Crystal: BUG: Unhelpful devs

[stugol]

@asterite No, @ysbaddaden keeps being deliberately unhelpful. And so do you. I've asked for help many times, and many times I've received sarcasm, derision and general stonewalling. I posted asking for help with this issue days ago, and receive no help whatsoever. Well ** you then. Crystal obviously isn't fit for purpose, and you, the devs, HAVE A ** ATTITUDE.

I'll find another language whose devs aren't a bunch of awkward *. Felix perhaps, or Onyx.

[asterite]

No. Look, you are the only one complaining about ZLIB not working because you can't statically link it. Nowhere in the docs of the language we say that statically linking libraries is possible. In #2396 you say "I'm again trying to statically compile code with Crystal". OK, so where's the command line that you are using to compile stuff? Where's the code? How can we reproduce this and help you?

As you can see, you don't provide enough information for us to reproduce the problem. This is not the first time, it's like the tenth time. We get tired of always saying the same things so we decide not to reply to you anymore.

Now, @ysbaddaden has more patience and decides to reply and help you. And you tell him "Do you practice being unhelpful, or do you have a natural talent for it?". Do you really expect him and others to try to help you like that?

[asterite]

Also, understand that we have limited time to spend in this project, and we have to prioritize what to do next. Statically linking libraries is not in our priority list right now.

On the other hand, we did solve many issues you reported, like #2395, #1226 and #2194 (and probably others), which means two things:

• You find interesting bugs in the language
• We fix some of them (the ones we can and think are most important)

Which in turn means two things:

• You are helpful for the improvement of the language
• We are helpful fixing bugs you report

Let's calm down and discuss things without personal attacks, and trying to provide as much information as we can.

[stugol]

If statically linking isn't a priority, what's the point? I need to statically link my code, or I have no use whatsoever for Crystal.

Also, zlib has worked before. And keeps not working. I didn't post my code because it's _the same code I sent you_, and is massive. The errors are not coming from my code anyway - they're coming from libcrypto, which is called from _your_ code. The commandline I'm using has already been described in other issues:

LIBRARY_PATH=/usr/local/lib:/usr/lib/i386-linux-gnu
LD_LIBRARY_PATH=/usr/local/lib:/usr/lib/i386-linux-gnu
crystal build $1 -o $2 --link-flags="-static"

This command _has worked_ before. And doesn't work now.

Try to see things from my point of view. I do the _exact same thing_ that worked before, and it _doesn't work_. So when I ask for help and get either ignored or spat on, I get _annoyed_. This is a normal human response.

[ozra]

I've already mentioned this @stugol, and I can understand you frustration over things working-not working etc. But I think it's important to point out that Onyx is only possible because of all the hard work and efforts put, and continuously so, in to Crystal by the crystal devers. It's a derivation based on "non-Ruby-centric" ideas to offer an alternative. And I think there's only reason to be grateful it's in such a good state today. I do suggest you PR fixes that can enable the static linking if possible, it would directly help Crystal to work as you want, and by derivation also Onyx.

As for me, I appreciate your input and ideas on my "alternative take" on this project, and I hope you can appreciate everyone's hard efforts.

Kind reminder on our place in things.

This is my human response to your outbursts ;-)

[stugol]

I _can't_ do PRs! I have no experience with writing compilers! It's a massively complicated subject that requires a specialised skill set that I simply don't have. For me to help, the devs would need to _explain_ the compiler to me. Not "answer questions", mark you, but "explain it to me". I doubt they have either the time or the inclination.

I would like nothing better than the ability to fix things and add features to Crystal (and Onyx). But I _cannot._ I can probably help out with the stdlib to some extent; but the only thing I reckon it desperately needs is threading; and that's another hugely complicated subject with the potential to horribly break _everything._

I consider myself an accomplished coder in a number of different languages; but you need more than coding experience to write a compiler.

[refi64]

Uh oh...

_ducks for cover_

[ozra]

Yes, these things are hard to solve and time consuming to program - for all of us - compilers aren't a picnic in the park. Hence it takes its time to get things fixed, and hence the need to prioritize. Way of the world and zero-budget :-/

In my view many compilers I've worked on has been structured and worked quite differently. The only reason I personally can work on this particular code base, derived, is because I _took the time and effort to study it_. I printed crystal compiler sources out on paper and spent last summer in the garden reading through, making remarks, etc, realizing that it was a very well structured project, which is why I chose it. "It doesn't come for free" for anyone. It's "just coding". I also spent this time on other compilers. Nim for instance. Which, no offence, is horribly structured and a dead end for expansion _in my opinion_, doesn't make that less of a feat though!

[stugol]

@asterite I've provided additional information. Are you going to help me statically compile or not? If not then I'm gone, because Crystal will be of no use to me.

Reason being, the Crystal dependencies are many and varied; and getting them installed is a right royal pain in the arse. Consider the amount of issues on here that are concerned with _simply getting Crystal to compile!_ I have to build two other projects from source before even starting to compile Crystal; and I need other apt packages besides. Requiring every user of my program to go through this massively complicated process is just insane. An executable must stand by itself, and if you cannot do this, then I must switch languages.

[asterite]

There's no easy way to currently force statically linking a library. We will most probably provide that feature in the future, but not right now. You'll have to switch languages until that. I know Go provides self-contained executables (though I'm not sure what happens if you bind to a library with cgo).

[waterlink]

@stugol As with any public APIs, when:

• something worked before, and
• it is not documented, and
• now it does not work,

Then there is no use complaining, using undocumented features is always upon your own risk, because they can and will break. Usually undocumented features are undocumented because, either:

• they are not intended to be used by users, or
• they are accidentally created.

[waterlink]

BTW, you can always use git bisect to find out the commit that made a feature break. Maybe, even without knowledge about compilers, you will be able to fix that and create a PR, because breaking change is simple to understand.

[asterite]

If it's something related to LIBRARY_PATH I'd try to apply this patch to your crystal bin wrapper and see if it works or has something to do with it.

[refi64]

Side note: remember:

1. When building stuff on Linux, everything that can go wrong will go wrong...twelve times. Few applications I've built that are over 1k LOC have built correctly the first time, with the exclusion of Free Pascal and LLVM. In general, Linux distros like changing so much that it can make certain things a pain in the butt. Just take a look a Python 3's 3k-line build script.
2. Static linking is not widely supported; not even Go has it down. The only language I know that has nailed it 100% is Free Pascal, and it still requires libc if you link with external C libraries.

[nabeelomer]

Wouldn't asking the compiler to generate object files and then manually linking them with ld be an option?

[stugol]

@waterlink I barely understand git to begin with. I have never heard of bisect. I'd be willing to give it a try, except that it seems blatantly obvious here that nobody except me is interested in making static compilation work. Therefore, you guys will presumably continue to break it, and I would have to continue to fix it, until I reached a point where my skill was insufficient. Which is likely to be quite soon, if not immediate, as I have almost zero experience with either git, compilers or linkers. I am not a contributor, I am an end user - not from choice, but because my skills do not include compiler design.

@nabeelomer that was how I initially attempted to statically link Crystal code, and had problems with it. This is when people told me to pass the --static flag instead. Either way, it seems to be an uphill battle.

@asterite it worked before, even with zlib. I don't see how that patch would make any difference. I'm already setting LIBRARY_PATH to the location of the .a files, and it's unable to see libz.a for some reason.

I think I'm done with Crystal. It doesn't support either threads or static linking, and neither of these are a priority for you. In these days of concurrency and 8+ core CPUs, threads are mandatory. Further, you guys find me objectionable, and I find you (with one or two exceptions) to be unhelpful.

I had hoped Crystal was the answer to "coding in C++ is like pulling teeth". Sadly, it lacks so much essential functionality as to make it unsuitable for real-world applications, and - according to what you have said - this is unlikely to change anytime soon.