Seriously guys, why aren't you learning Crystal...

>Compiled only is everyone's preference

literally who's?

Compiling gives a free speed boost for most languages.

>It's Ruby but modern and fast!
Missing the point of why Ruby is dead. Ruby is so bad people would rather use Node.

Let that sink in for a minute.

youre supposed to be shilling PHP, remember? you get confused by your own bullshit dont you?

He's not shilling Node. Are you illiterate?

>Compiling gives a free speed boost for most languages.
you didnt answer the question, did you? because theres literally is no one who wants a compiled-only scripting language, is there?

PHP didn't kill Ruby though. Back in the day they were simply competitive. Both got killed by Node when it really started to take off in 2012.

All three are shit. They could be as fast as optimized C and they'd still be shit.
>Why are they shit user?
It's hard to make a project in them that's larger than a couple thousand lines of code if you're not a very experienced developer who self-enforces good practices. The language designs of all three give you the option of writing really shitty code, and that option is very tempting. Node is simply the most popular of the three now because you aren't switching languages between the back and front ends, and brainlet kode kamp devs are such beginners that juggling two languages is a real challenge.

>Not as fast as the C language
Seems to be pretty much as fast to me

You can execute crystal source files as scripts just like any scripting language.

Attached: Screen Shot 2018-06-24 at 10.58.46 PM.png (396x721, 67K)

it's not compiled only you retard, there's an interpreter as well

it has literally none of the downsides of ruby

Lisp is not commonly taught in school, it's hard to get new hires up to speed

>Lisp is not commonly taught in school, it's hard to get new hires up to speed
I remember when schools taught Scheme, not Java and Python

>You can execute crystal source files as scripts just like any scripting language.
but not in Crystal, in Ruby, right?

No, there is an interpreter that can accept Crystal source code.

but its not a Crystal interpreter, is it?

Attached: Screen Shot 2018-06-24 at 11.10.52 PM.png (188x110, 9K)

but thats not running an interpreter, is it?

For the thousandth time yes Crystal can be interpreted. There is a Crystal interpreter being developed alongside the compiler. Jesus Christ.

Bullshit bench detected. No way you're beating C in memory usage and lagging less than 2% behind it in execution speed for general tasks.

Cry more

Attached: Screen Shot 2018-06-24 at 11.27.42 PM.png (937x598, 100K)

Redpill me on Crystal. I just put Linux on one of my thinkpads for the first time. I know that Crystal only compiles on Linux for now. I'm interested in learning it. Especially if it's rivaling C in efficiency.

I know some Haskell, JS, and C++, but no C.

Why the fuck are you posting partial screenshots. Link to the actual data.

It also compiles on macOS fyi.

Crystal isn't really a C replacement as far as the types of tasks you'll be conquering, e.g. Crystal is not designed for embedded or low/assembly level tasks.

Crystal is however designed for writing fast software quickly. Crystal binaries are fast and the syntax is easy allowing you to write more quickly. The last thing I'd like to note is Crystal bundles all dependencies (Shards, basically the equivalent of Ruby's gems) in the binary. This results in larger binaries but you and your users get to avoid dependency hell.

github.com/drujensen/fib

Good to know, but I don't have access to a Mac. Will keep that in mind though. I appreciate the rundown. I really like that it bundles dependencies. I do webdev in my day job and that shit is just a nightmare. What sort of tasks can Crystal solve well? Or is it more general propose?

It's pretty general purpose. Crystal can be used for webdev, CLI tools, GUI tools, data processing, pretty much whatever you want as long as you don't need to work at a really low level.

I'm super paranoid about GitHub repos for dependencies just disappearing so the fact that the binaries include all of them is super nice for me.

Okay. It's some random guy's repo. I'm sure the data is totally reliable. I'm not about to check all the code and run it locally to prove a point on fucking Jow Forums, but benchmarking is notoriously difficult to do right. You have to make sure your implementation in each language is as fast as possible, which requires having very intimate knowledge of each lang and it's runtime. Then you have to make sure the environment is the same across each language, but also take into account the expected environment for a given language to perform well. The numbers in this bench simply don't look right. He's done something wrong. Probably a lot of somethings wrong.

Compare the results in that repo with a benchmark that's had thousands of man-hours put into it by very, very smart people. Even so, the people behind this openly state that their benchmark is only casually useful because benchmarking languages is mostly an exercise in jerking off.
benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html

they don't provide windows binaries.

Different user but are there any GUI libraries available already? Also, I think I read about being able to use straight C in Crystal, wouldn't that solve the low level problem?

>using windows for software dev

I haven't explored using the C FFI, but possibly yes.

GUI shit: crystalshards.xyz/?filter=gui

I don't know anything about Crystal, but who gives a fuck. Type the filename and the program runs.

Pretty much. Just from looking at it looks like it's benchmarking each compiler's implementation of print more than anything.

Sounds pretty cool! I'll check it out.

I mean, it's just an implementation of recursive Fibonacci function. It's intentionally not optimized (as in the most obvious case, with iteration).

Compared to the benchmark games, this is mostly pointless as a benchmark, as even the best languages are absurdly slow (taking 5+ seconds to compute fib(46) is awful) for something fairly simple for a computer.

>Not everything needs to be as fast as C
opnion discarded

That's my point. The cost of that print system call (maybe more than one depending) is going to be huge compared to adding 1 to a total around 50 times. It's like racing cars through a city and waiting for all the stoplights.

>C++
>6.265s
>not using constexpr to get 0s
rigged

why aren't you learning haskell?

user said it like an idiot, but I believe he meant "overhead is acceptable if the benefit can be fully justified". That's definitely true.

?

I really don't understand the point you're making. The print call is minimal or, certainly, negligible. You're making the mistake that fib(46) is a big number -- it's just under 3 billion. The bigger cost of time is the recursion: yes, it's just "adding 1", but it's not happening 50 times. It's happening about 5.9 billion times, assuming absolutely no performance techniques are used.

>hey guys why aren't you learning the newest meme language
Because my time is valuable. Unless it's doing something that has never been done before, it's already been done better elsewhere.

The point is the algorithm is so trivial that every language should basically score as startupTime+C where C is close to constant between languages. It might as well be testing printing "hellow world" then sleep for five seconds.

If everytime fib is called it returns a value greater than one, how do you call it 5.9 billion times and wind up with under 3 billion?

A recursive fibonacci calls itself twice every time

Is there really anything to learn? Looks just like a ruby with static typing for me.

>The point is the algorithm is so trivial that every language should
>should
yes, but they don't. hence differences in the performances between any two compilers/interpreters.

Good question. Here's an example: consider Fib(4), using Fib(0) = Fib(1) = 1 as seeds. Fib(4) = 5 (easy to calculate).

The question is, if Fib(4) = Fib(3) + Fib(2), how many calls to Fib are made? Well, it's simply the number of calls to Fib when calculating Fib(3) plus the number of calls to Fib when calculating Fib(2) -- plus 1, from calling Fib(4) itself.

Let's define "number of calls to Fib when calculating Fib(n)" to be #calls(n). Then #calls(n) = #calls(n-1) + #calls(n-2) + 1. Not only does it look like another Fibonacci sequence, it starts with similar format: #calls(0) = #calls(1) = 1.

You can calculate the rest yourself: #calls(2) = 3, #calls(3) = 5, and #calls(4) thus ends up being 9, even though Fib(4) is 5.

That's not how you're supposed to do it. Calling .to_s is significantly slower than using string interpolation. You want to change your program to
puts "2 + 2 is #{2+2}"

as this invokes an io that concarnates the strings for you

The differences between the languages will come down to micro optimizations which requires an expert to account for. If the benchmark author is slightly more competent in one language then that will be represented as bias in the results. There's no control here, it's not a rigorous scientific experiment.

It's fibonacci, a trivial numbers benchmark.
With static semantics and escape analysis it's easily possible to be as fast as C, in particular if you use LLVM correctly.

I wrote an interpreter in it, but I'm still waiting for a 1.0 release in order to invest more time into it.
You can spin it on their homepage, though.
>scripting language
It's not a scripting language, btw.

As fast as C for the actual program loop. Startup costs will be different. That's why earlier I said the bench might as well be "hello world" with a sleep for five seconds for how useful it is.

Well, fibonacci benchmarks are questionable anyway.

It doesn't actually matter whether it's as fast as C or not.
The important part of C programming is that it's an established player with good tooling support that programmers are already familiar with. Everyone knows C and everyone can get a job writing C. If there are faster languages, big deal. C will catch up soon enough anyway.

>with good tooling support
>everyone can get a job writing C
Those are somewhat questionable, though.

No they're not. C is the canonical programming language. When you think of programming, you think of C. It's true that most jobs will ask for other languages but if you get in there and implement the important parts in pure C you are guaranteed the same kind of glory as if you were a god.

Nah, that would be great in some ideal universe where engineers write flawless code and management aren't fucking retarded. What really happens is you get hired for whatever is on your CV and then instead of that you're writing some awful homebrew/proprietary java framework on a 20 year old out of date jvm on a VM guest that was imported from a 40 year old server where all the original maintainers died decades ago.

Because haskell is for men fat tiddies

>Everyone knows C and everyone can get a job writing C.
user, I...

github.com/crystal-lang/crystal/blob/master/CODE_OF_CONDUCT.md
all I needed to see
into the trash

>well shit, this hammer was made by a faggot, I can hardly beat nails in with this!

Well obviously the nails won't go in straight.

You're wrong.
You were hired for writing C++, sh and Python, and then once you're in the door they switch to suddenly exclusively using enterprise Java.