5 ms·

Last year's discussion for those interested: https://news.ycombinator.com/item?id=10014178 https://news.ycombinator.com/item?id=10014178 This language definite

Last year's discussion for those interested: https://news.ycombinator.com/item?id=10014178 https://news.ycombinator.com/item?id=10014178 This language definitely deserves your attention. It's fast, it's easy on the eyes, and it produces native code. A real workhorse language. Want Go's speed but hate Go's if err nil verbosity? Check out Crystal.

stcredzero 10y ago
How is the debugging story?
- RX14 10y ago
  Unfortunately its a compiled language so you can't drop into a pry repl like ruby. It does emit debug symbols, and both gdb and lldb work with it, I just haven't gotten around to working out if they're useful for more than printing backtraces on segfault. Puts debugging works great though!
  - stcredzero 10y ago
    What if you also targeted a virtual machine with a Ruby meta-level? Some care would need to be taken to ensure that the two were equivalent, but this should be commensurate with ensuring JIT and bytecode execution in some existing environments is equivalent.
AstralStorm 10y ago
Does it even have built in concurrency?
- pjmlp 10y ago
  Go's built in concurrency is oversold. If the language is powerful enough in the expressiveness it offers for building libraries that provide the same features as builtin types, that is also achievable. This is the path being trailed by the languages more expressive than Go.
  - fzzzy 10y ago
    I don't agree. Having an event loop built in to the core of the language is a major advantage. Look at Python and async io: Twisted has been around for over 15 years now. asyncore even longer. Tornado exists because apparently Twisted and asyncore weren't good enough. I'm not even sure I know how many incompatible "coroutine" libraries are built on top of generators. node.js may have a language and standard library that isn't nearly as nice as Python, but it has a built-in event loop. This sidesteps an entire universe of problems. Unfortunately node still has another, similar problem: Does the library use callbacks? Promises? Generator-based coroutines? async/await? If it doesn't use the same style as what your codebase currently uses, you're going to spend a lot of time converting between continuation styles. Languages like Go and Erlang simply don't have any problems like this. Now, one might argue that leaving it up to libraries allows greater exploration of the problem space and that blessing a concurrency method stifles innovation, and that might be right. But having a consistent concurrency story built right in to the language is a large advantage.
    - brightball 10y ago
      I was getting ready to post the exact same thing. The built in event loop is major. Go did a lot of modelling from Erlang, but made tradeoffs that kept it closer to a C-style programming model. It's a great language and the limits of its concurrency model aren't something that will really be apparent to you if you haven't learned Erlang/Elixir. For most people, it provides a concurrency model that's a cut above everything else out there. The main differences in Go and BEAM languages (Erlang/Elixir) are cooperative vs prescheduling, shared memory vs immutable message passing, general garbage collection vs heap per process, and lastly general runtime vs isolation. Cooperative scheduling means that the scheduler has to have control relinquished back to it (such as with I/O events), while prescheduling will take back control. Cooperative means that you can get better end-to-end performance for a benchmark but you run the risk of a code taking over the processor. Prescheduling will allow consistent performance for all operations in the run time without allowing anything to overtake it. That's one of the ways that it's possible to reliably run a database within the runtime alongside the rest of your code on BEAM. Shared memory with pointers is pretty standard and definitely provides some performance perks, especially when dealing with large data structures. The flip side means that native clustering doesn't work. With BEAM languages that lack shared memory and rely on message passing, you can just as easily call a function on a different server in another data center as you can a function in your current heap space. This makes it possible to smoothly distribute everything without having to worry about updating shared memory on a specific machine or having the state get out of sync. The channels model helps to avoid this, but by even including shared memory in the language you make the trade off of losing natural clustering for distribution. With shared memory comes garbage collection and GC pauses, although the Go team has done great work optimizing this. With BEAM every new process (equivalent to a go routine) gets it's own heap meaning that it can be independently cleaned up without pausing the entire stack. This also makes hot deployments possible, so doing things like deploying an update to a codebase with millions of active websocket connections can be done without trigger millions of simultaneous re-connections. The general runtime vs isolation means that a goroutine that blows up and crash the entire system if it's not properly handled at the point of the problem. When writing Go code you find yourself writing a line of error handling for every line of functionality. With BEAM isolation, processes are kicked off with id's and the processes are so inexpensive that the standard method is to create two - one as a supervisor and one as the process. If the process ever crashes for some reason, the supervisor just restarts it immediately. This creates a granular level of isolation and reliability. There is a library for Go that I remember seeing that seems to create a supervisor pattern for reliability though (http://www.jerf.org/iri/post/2930 http://www.jerf.org/iri/post/2930). Go will win benchmarks because of it the choices the language made, but the benefits for long term run time, reliability, distribution and performance consistency in the face of bad actors will be in favor of Erlang/Elixir. That said, the steps that Go took toward implementing the closest thing to Erlang-like concurrency makes it the winner by far among the non-BEAM languages.
- RX14 10y ago
  Crystal has an excellent concurrency story built into the stdlib which is on by default. All io is evented by default, with events being fed into the fiber scheduler. The nice thing is that the concurrency and evented io is built just using the stdlib in crystal itself, so it's readable and shows that crystal is quite powerful. You can read more here: https://crystal-lang.org/docs/guides/concurrency.html https://crystal-lang.org/docs/guides/concurrency.html
  - AstralStorm 10y ago
    Lack of parallelism will cause similar problems to what python faces due to global interpreter lock, killing performance. It is 2017 (almost), parallelism should be available in any new programming language.
    - asterite 10y ago
      Yes, it will be available before 1.0. It's on the roadmap.
    - RX14 10y ago
      Parallelism isn't easy, so the core team is expending time to get it done correctly and released before 1.0. Crystal doesn't have anything like the GIL, and the compiler already enforces some simple rules, like type flow not being available on instance variables because they could be changed on another thread. You can't expect the world from any new project straight away.
    - fzzzy 10y ago
      Parallelism is available to any language through fork().
  - JohnStrange 10y ago
    But its concurrency uses green threads only, no proper multicore support? That's such a pity. Lack of built-in parallel programming facilities is a big problem of many otherwise nice languages, many scheme implementations have this limitation, too. A relatively new programming language should really use all cores, ideally it should distribute the green threads across the available cores with its own scheduler automatically and have synchronization primitives like channel work across them.
Xeoncross 10y ago
I am very happy with Go, but I love having Crystal and Rust around to keep up innovation for modern, compiled languages. Looks easy enough to jump between the three (though Crystal isn't quite ready on the lib front). A unicode core, useful core packages (MIME, ECC/RSA, Templates, etc...), and easy parallelism are so nice coming from 90's scripting land. Oh, and I love Go's err bubbling (keeps libs from dropping important messages) after years of Exception catching.

stcredzero 10y ago

How is the debugging story?

RX14 10y ago
Unfortunately its a compiled language so you can't drop into a pry repl like ruby. It does emit debug symbols, and both gdb and lldb work with it, I just haven't gotten around to working out if they're useful for more than printing backtraces on segfault. Puts debugging works great though!
- stcredzero 10y ago
  What if you also targeted a virtual machine with a Ruby meta-level? Some care would need to be taken to ensure that the two were equivalent, but this should be commensurate with ensuring JIT and bytecode execution in some existing environments is equivalent.

AstralStorm 10y ago

Does it even have built in concurrency?

pjmlp 10y ago
Go's built in concurrency is oversold. If the language is powerful enough in the expressiveness it offers for building libraries that provide the same features as builtin types, that is also achievable. This is the path being trailed by the languages more expressive than Go.
- fzzzy 10y ago
  I don't agree. Having an event loop built in to the core of the language is a major advantage. Look at Python and async io: Twisted has been around for over 15 years now. asyncore even longer. Tornado exists because apparently Twisted and asyncore weren't good enough. I'm not even sure I know how many incompatible "coroutine" libraries are built on top of generators. node.js may have a language and standard library that isn't nearly as nice as Python, but it has a built-in event loop. This sidesteps an entire universe of problems. Unfortunately node still has another, similar problem: Does the library use callbacks? Promises? Generator-based coroutines? async/await? If it doesn't use the same style as what your codebase currently uses, you're going to spend a lot of time converting between continuation styles. Languages like Go and Erlang simply don't have any problems like this. Now, one might argue that leaving it up to libraries allows greater exploration of the problem space and that blessing a concurrency method stifles innovation, and that might be right. But having a consistent concurrency story built right in to the language is a large advantage.
  - brightball 10y ago
    I was getting ready to post the exact same thing. The built in event loop is major. Go did a lot of modelling from Erlang, but made tradeoffs that kept it closer to a C-style programming model. It's a great language and the limits of its concurrency model aren't something that will really be apparent to you if you haven't learned Erlang/Elixir. For most people, it provides a concurrency model that's a cut above everything else out there. The main differences in Go and BEAM languages (Erlang/Elixir) are cooperative vs prescheduling, shared memory vs immutable message passing, general garbage collection vs heap per process, and lastly general runtime vs isolation. Cooperative scheduling means that the scheduler has to have control relinquished back to it (such as with I/O events), while prescheduling will take back control. Cooperative means that you can get better end-to-end performance for a benchmark but you run the risk of a code taking over the processor. Prescheduling will allow consistent performance for all operations in the run time without allowing anything to overtake it. That's one of the ways that it's possible to reliably run a database within the runtime alongside the rest of your code on BEAM. Shared memory with pointers is pretty standard and definitely provides some performance perks, especially when dealing with large data structures. The flip side means that native clustering doesn't work. With BEAM languages that lack shared memory and rely on message passing, you can just as easily call a function on a different server in another data center as you can a function in your current heap space. This makes it possible to smoothly distribute everything without having to worry about updating shared memory on a specific machine or having the state get out of sync. The channels model helps to avoid this, but by even including shared memory in the language you make the trade off of losing natural clustering for distribution. With shared memory comes garbage collection and GC pauses, although the Go team has done great work optimizing this. With BEAM every new process (equivalent to a go routine) gets it's own heap meaning that it can be independently cleaned up without pausing the entire stack. This also makes hot deployments possible, so doing things like deploying an update to a codebase with millions of active websocket connections can be done without trigger millions of simultaneous re-connections. The general runtime vs isolation means that a goroutine that blows up and crash the entire system if it's not properly handled at the point of the problem. When writing Go code you find yourself writing a line of error handling for every line of functionality. With BEAM isolation, processes are kicked off with id's and the processes are so inexpensive that the standard method is to create two - one as a supervisor and one as the process. If the process ever crashes for some reason, the supervisor just restarts it immediately. This creates a granular level of isolation and reliability. There is a library for Go that I remember seeing that seems to create a supervisor pattern for reliability though (http://www.jerf.org/iri/post/2930 http://www.jerf.org/iri/post/2930). Go will win benchmarks because of it the choices the language made, but the benefits for long term run time, reliability, distribution and performance consistency in the face of bad actors will be in favor of Erlang/Elixir. That said, the steps that Go took toward implementing the closest thing to Erlang-like concurrency makes it the winner by far among the non-BEAM languages.
RX14 10y ago
Crystal has an excellent concurrency story built into the stdlib which is on by default. All io is evented by default, with events being fed into the fiber scheduler. The nice thing is that the concurrency and evented io is built just using the stdlib in crystal itself, so it's readable and shows that crystal is quite powerful. You can read more here: https://crystal-lang.org/docs/guides/concurrency.html https://crystal-lang.org/docs/guides/concurrency.html
- AstralStorm 10y ago
  Lack of parallelism will cause similar problems to what python faces due to global interpreter lock, killing performance. It is 2017 (almost), parallelism should be available in any new programming language.
  - asterite 10y ago
    Yes, it will be available before 1.0. It's on the roadmap.
  - RX14 10y ago
    Parallelism isn't easy, so the core team is expending time to get it done correctly and released before 1.0. Crystal doesn't have anything like the GIL, and the compiler already enforces some simple rules, like type flow not being available on instance variables because they could be changed on another thread. You can't expect the world from any new project straight away.
  - fzzzy 10y ago
    Parallelism is available to any language through fork().
- JohnStrange 10y ago
  But its concurrency uses green threads only, no proper multicore support? That's such a pity. Lack of built-in parallel programming facilities is a big problem of many otherwise nice languages, many scheme implementations have this limitation, too. A relatively new programming language should really use all cores, ideally it should distribute the green threads across the available cores with its own scheduler automatically and have synchronization primitives like channel work across them.

Xeoncross 10y ago

I am very happy with Go, but I love having Crystal and Rust around to keep up innovation for modern, compiled languages. Looks easy enough to jump between the three (though Crystal isn't quite ready on the lib front). A unicode core, useful core packages (MIME, ECC/RSA, Templates, etc...), and easy parallelism are so nice coming from 90's scripting land. Oh, and I love Go's err bubbling (keeps libs from dropping important messages) after years of Exception catching.