Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Crystal is the most promising programming language of 2018

medium.com

Post reply on HN
Print view View original

91–100 of 109 posts

Re: Why Crystal is the most promising programming language of 2018

#91

Post by kjeetgill »

projectramo wrote: post #81
kjeetgill wrote: post #80

Earlier quoted context omitted.

I don't know your experience so I'll do my best to draw on examples _I suspect_ you might be familiar with. I'll try to keep this simplified but deep enough. I'm taking a shot in the dark and hoping you're more familiar with the one of the python/node/ruby world. You should worry about it when you want to do something faster than you are already or want to do more things at once. Maybe someone's framework/service has…

Great answer. You should post that on a blog if you have one. This was the best part if you want to expand on it in a longer post: "You should worry about it when you want to do something faster than you are already or want to do more things at once. Maybe someone's framework/service done it for you maybe not. For a web api, the workload _usually_ looks like: {database call} -> {do some work} -> {maybe more calls} ->…

Thanks, I'm glad it was helpful! I don't have a blog yet, but I started commenting a month back to build up some writing chops so I'm especially happy to hear it.

Re: Why Crystal is the most promising programming language of 2018

#92

Post by kazinator »

singularity2001 wrote: post #76
wsgeek wrote: post #57

Earlier quoted context omitted.

Lisps are all very, very cool -- you basically get to build your own world. And the macros -- so powerful. But the parens! Not the number of them, as that is about the same as other langs, but the placement of them: Sample factorial function: (define fac (lambda (n) (if (= n 0) 1 (* n (fac (- n 1)))))) ; And with Clojure, you don't have proper tail recursion, so you'll have to add some Clojure-only thing in there to…

yes, lisp is a fossil of a time before precedence was invented. what I dream of is a Lisp with an additional mechanism to define precedence of functions/operators. And infix operators. Almost like Haskell.

> mechanism to define precedence

Read syntax:

https://en.wikipedia.org/wiki/CGOL [1973!]

https://www.cliki.net/infix

Macros:

https://stackoverflow.com/questions/25434538/define-function...

Re: Why Crystal is the most promising programming language of 2018

#93

Post by geezerjay »

RX14 wrote: post #55
ecshafer wrote: post #37

Earlier quoted context omitted.

I think not having a parallelism first mindset will be the killer of the language. It's too important in today's world to not have that be an essential part of the language from the beginning. Rust and go for example we're 100% designed around parallelism.

I think you're getting confused by concurrency and parallelism. Crystal is concurrency-first and uses the same concurrency model as go. Expanding that to run fibers on multiple cores is just an implementation detail. A difficult implementation detail, but it shouldn't affect the core of the language.

You posted a message that's essentially hand-waving. Discussing semantics means nothing if the language supports neither parallelism nor concurrency.

Re: Why Crystal is the most promising programming language of 2018

#94

Post by kazinator »

wsgeek wrote: post #57
jgh wrote: post #54

Earlier quoted context omitted.

I'm similar to you. An every-day / almost every day C++ user. I've been using Clojure for a personal project and I really enjoy the much-reduced overhead imposed by the language. Unfortunately it runs on the JVM so that's not something I'm super stoked about. But this language seems interesting. The interoperability with C libs gives it a head start. The syntax seems much nicer than Rust. Too bad about the parallelis…

Lisps are all very, very cool -- you basically get to build your own world. And the macros -- so powerful. But the parens! Not the number of them, as that is about the same as other langs, but the placement of them: Sample factorial function: (define fac (lambda (n) (if (= n 0) 1 (* n (fac (- n 1)))))) ; And with Clojure, you don't have proper tail recursion, so you'll have to add some Clojure-only thing in there to…

How do we know that

  def fac(n): n
is the whole function? Maybe someone snipped

  def fac(n): n
One of the parentheses you have there come from having an unambiguous, complete, top-level form. We know nothing has been cut off; any characters after the last closing parenthesis are not part of this form. Curly-brace languages agree with this and do the same.

One level of parentheses comes from using a dialect which uses a variable definition and lambda to define a function, instead of having function-defining syntax like defun.

   n
requires knowledge of the ternary operator and its precedence. Someone who has no clue about the ternary operator will not make heads or tails out of this. The Lisp is impossible to mis-parse, even by a programmer who doesn't know Lisp. You might not know how if works, but you can't miss the fact that (if ...) is a unit, which is enclosing four things: if, (= n 0), 1, and (* n ...).

You've loaded the readability dice by writing it on one line. To help with the readability issues in both languages, we can use multiple lines and indentation:

   def fac(n):
     n

Re: Why Crystal is the most promising programming language of 2018

#95

Post by captainbland »

crypto-jeronimo wrote: post #72
captainbland wrote: post #27

Earlier quoted context omitted.

This is a big advantage of Nim ( https://nim-lang.org/ ), which on the face of it is a pretty similar kind of language with a more Python-like syntax. Nim supports real threads with message passing channels (similar to Go).

> Nim supports real threads with message passing channels (similar to Go). Could you specify what are the differences from Go, in this regard are, please?

Sure - I'm no expert in concurrency in programming languages as such but here's my understanding: so Nim supports what are essentially native operating system threads but with a difference from most languages being that each thread has its own garbage collected heap. Nim supports shared memory if you so choose to use it with a shared heap. Nim also supports a channel based communication system similar to Go's.

Nim also supports lighter-weight parallelism with the `spawn` (unsafe, unstructured parallelism which schedules a procedure to run in a thread pool) and `parallel` (lets you use a subset of the Nim language to create concurrency safe tasks) keywords which pass tasks to thread pools in the background. You can read more about Nim's concurrency here: https://nim-lang.org/docs/manual.html#parallel-spawn-spawn-s...

Go has Goroutines which use less resources than threads on most operating systems while also taking advantage of multicore CPUs (I assume they must run in a thread pool running in the background?). It also supports a select case statement which is a nice bit of syntax sugar for managing multiple channels, which Nim doesn't support (although its macro system is pretty powerful, so you could plausibly come up with an equivalent). Go does not support shared memory communication as a language feature, although some libraries apparently give you that option.

Re: Why Crystal is the most promising programming language of 2018

#96

Post by ModernMech »

tome wrote: post #73
ModernMech wrote: post #60

Earlier quoted context omitted.

And yet I got downvoted.

Because it's not correct.

The correct response to a wrong post is to correct it, not to drive by downvote. Explain where I'm wrong and then we have the basis for a discussion on the merits. Otherwise you're not adding anything.

Re: Why Crystal is the most promising programming language of 2018

#97

Post by ModernMech »

lispm wrote: post #77
ModernMech wrote: post #12

Earlier quoted context omitted.

The main difference between compiled and static languages is that compiled languages go through a phase of "checking your work", where it compares parts of your program to other parts before running it. For example, if you misspelled a name, the compiler will look everywhere in your program for that name before you run it, and tell you it can't find the name. That's why we like compiled languages. By contrast, dynami…

Really? SBCL: * (defun foo (a) (+ a 42)) FOO * (defun bar (b) (foo 10 20)) ; in: DEFUN BAR ; (FOO 10 20) ; ; caught STYLE-WARNING: ; The function was called with two arguments, but wants exactly one. ; (SB-INT:NAMED-LAMBDA BAR ; (B) ; (BLOCK BAR (FOO 10 20))) ; ; caught STYLE-WARNING: ; The variable B is defined but never used. ; ; compilation unit finished ; caught 2 STYLE-WARNING conditions BAR

That's not the point. You can run static languages in a REPL. Some easier than others. You've chosen a particularly easy static language to write REPLs for as a counterpoint. LISPs and other homoiconic languages are especially well suited for interpreters because they're especially well designed languages.

Languages like C which require header files and a pre-processor are much harder to write REPLs for. You can try to do it and you can build a thing that works kind of like a REPL (look I type code and press enter and it evaluates, yay), but the experience always falls short of using a dynamic language in a REPL. It's just not even close, and that's just due to the simple fact you're trying to use something in a way it's not intended. Compiled languages simply are not designed with a tight development loop as a major design goal.

Re: Why Crystal is the most promising programming language of 2018

#98

Post by lispm »

ModernMech wrote: post #97
lispm wrote: post #77

Earlier quoted context omitted.

Really? SBCL: * (defun foo (a) (+ a 42)) FOO * (defun bar (b) (foo 10 20)) ; in: DEFUN BAR ; (FOO 10 20) ; ; caught STYLE-WARNING: ; The function was called with two arguments, but wants exactly one. ; (SB-INT:NAMED-LAMBDA BAR ; (B) ; (BLOCK BAR (FOO 10 20))) ; ; caught STYLE-WARNING: ; The variable B is defined but never used. ; ; compilation unit finished ; caught 2 STYLE-WARNING conditions BAR

That's not the point. You can run static languages in a REPL. Some easier than others. You've chosen a particularly easy static language to write REPLs for as a counterpoint. LISPs and other homoiconic languages are especially well suited for interpreters because they're especially well designed languages. Languages like C which require header files and a pre-processor are much harder to write REPLs for. You can try…

SBCL is compiled, dynamic and supports REPL based programming.

Re: Why Crystal is the most promising programming language of 2018

#99

Post by RX14 »

geezerjay wrote: post #93
RX14 wrote: post #55

Earlier quoted context omitted.

I think you're getting confused by concurrency and parallelism. Crystal is concurrency-first and uses the same concurrency model as go. Expanding that to run fibers on multiple cores is just an implementation detail. A difficult implementation detail, but it shouldn't affect the core of the language.

You posted a message that's essentially hand-waving. Discussing semantics means nothing if the language supports neither parallelism nor concurrency.

But crystal support concurrency, and it supports it very well. That's why it achieves about 100,000 HTTP requests per second per core, you just can't get that kind of performance on a single core without using evented IO.

Re: Why Crystal is the most promising programming language of 2018

#100

Post by RX14 »

captainbland wrote: post #95
crypto-jeronimo wrote: post #72

Earlier quoted context omitted.

> Nim supports real threads with message passing channels (similar to Go). Could you specify what are the differences from Go, in this regard are, please?

Sure - I'm no expert in concurrency in programming languages as such but here's my understanding: so Nim supports what are essentially native operating system threads but with a difference from most languages being that each thread has its own garbage collected heap. Nim supports shared memory if you so choose to use it with a shared heap. Nim also supports a channel based communication system similar to Go's. Nim al…

All the goroutines share the heap, so go does support shared memory, it's just you're encouraged to use channels instead because they're easier to get right.
Post reply on HN