Hacker News Reader

Comment by catnaroek | Hacker News Reader

The really important questions in any modern language:

(0) Does Crystal have a lot of undefined behavior like C?

(1) Does understanding Crystal programs require a lot of trial and error just like in Ruby?

(2) How good a job does Crystal do at preventing me from shooting myself in the foot?

A language isn't to be judged just by the amazing programs you can write in it. (Turing-completeness and I/O facilities have that covered.) Far more important are the totally stupid programs that you can't write in it.

View on HN

You could've answered those questions yourself if you actually looked into the language, but you didn't. You instead offered facile and superficial judgement. If you have complaints, state them. Speaking in generalizations just sounds like whining.

To be clear, I have no strong opinions about Crystal and will probably never use it. But comments like yours are simply grandstanding and it's annoying that they are confused for contribution.

I'd love for you to elaborate on (2). I don't think that's a criticism of Ruby I've heard before.

(2) wasn't particularly aimed at Ruby, although some “creative” uses of metaprogramming can be very hard to debug. But languages designed for systems programming typically have features that, when used wrong, result in totally catastrophic modes of failure.

Well, you don't have runtime eval or send in Crystal, so some variants of metaprogramming can be ruled out.

However, there are compile time versions of method_missing, delegates and instance_exec available (usually with slightly different naming due to not having the exact same semantics as the ruby counterparts), so it is still possible to do some magic.

Is undefined behavior a thing outside of C? Is that really something you should question rather then just assume that modern language have no undefined behavior?

What happens if you try to mutate a shared object from two threads, without using mutexes and locks, in languages without either Rust's compiler-enforced ownership or a global interpreter lock?

ConcurrentModificationException?

That's hardly any better than undefined behavior. It's not the program you want to write, under any possible circumstance, and the language should tell you so.

Pedantically, it's defined behavior, and doesn't use an interpreter lock.

Granted, I'm completely head over heels for Rust, and I agree completely that ConcurrentModificationException is a crappy answer, but it is defined behavior (AFAIK).

It's true that throwing exceptions is defined behavior, but it's not defined in a way you'd actually want to use. For your actual purposes, it's undefined.

It's not defined. The library/VM is very good at throwing ConcurrentModificationException in practice, but it's specified as a best-effort thing, not to be relied upon.

It is significantly better than undefined behaviour, as it results in a noisy failure rather than silently incorrect results. Compile-time failures are best, sure, but I'll always take an exception over what is essentially data corruption.

> It is significantly better than undefined behaviour, as it results in a noisy failure rather than silently incorrect results.

This might be true in a deterministic setting, since the likelihood that a test suite will find the error is very high. But in a non-deterministic concurrent setting, throwing an exception that might be only caught once in a blue moon is just as bad as not doing anything about errors.

Corrupting data with no warning or visible signs is far, far worse than crashing the application.

Data corruption is possible even in memory-safe languages, anyway. For instance, invariants of data structures might be violated.

If you're really serious about data integrity, ask yourself - does any language even attempt to describe data structures stored on disk?

An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time - it's much easier to notice in the first place, and as long as you have one instance of the exception you have a stack trace to start from. And in practice the JVM/standard library throws ConcurrentModificationExecption pretty reliably.

> An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time

The fundamental problem still remains, that in neither case can I use the language's semantics to guide the design of my program.

> and as long as you have one instance of the exception you have a stack trace to start from

Oh, really? How am I supposed to find what the problem is in the general case, from just a single exception stack trace that I might or might not get?

I think a stack trace and an exception would help most people with a modicum of debugging skills.

> I think a stack trace and an exception would help most people with a modicum of debugging skills.

What if the error is difficult to reproduce in the first place? This isn't too uncommon in concurrent programming.

You can look at the code, see why you can't prove it correct, or work backward to see how the code could have gotten to such a state. Like I said, debugging skills.

> You can look at the code,

Of course I can look at the code. Trust me the reason why I introduced the bug wasn't because I was looking at something else at the moment.

> see why you can't prove it correct,

Realistically, this is because the language and the program's design conspire to make proving anything about the program an uphill battle. If the language could perform basic sanity checks (e.g., no attempting to use objects after ownership has been transferred to someone else), then at least I could have a fighting change to manually prove more interesting properties.

> or work backward to see how the code could have gotten to such a state.

Doing this on a per case basis is an incredibly mind-numbing task.

The stack trace tells you where one of the concurrent accesses happened. As opposed to data corruption where (if you even manage to witness it in the first place) all you know is that one of the things that accesses that memory got it wrong.

??? Ask any C programmer if they could wave their magic wand and turn every single undefined behavior in their programs into a segfault how much better their life would be. It's not a small improvement it's a huge improvement.

Thats simply not true.

UB is simply the latest stick to hit C with. In day-to-day working nobody worries about UB at all as you generally don't notice it.

Same with lack of a GC; this is a plus point for C for most applications, not a negative.

(and yes, I do have plenty of experience in it, I've been using it for the past 20 years, have you?).

> UB is simply the latest stick to hit C with.

Honest question, which is the case?

(0) You find it easy to determine, by visual inspection, whether a piece of code has undefined behavior.

(1) Your coding practices make it difficult to accidentally introduce undefined behavior in the first place.

> Same with lack of a GC; this is a plus point for C for most applications, not a negative.

Agreed. C addresses use cases for which GC (or any other feature requiring heavy runtime support) is simply unacceptable.

Its a combination of both.

The vast majority of all code you write will not invoke UB, most people tend to stick to an 'easy' subset of syntax, unlike say C++ where everyone uses a different subset of features making it in effect multiple languages.

A combination of testing the known edge cases, wraparound issues, size issues, static analysis and tooling means running into an example of UB is extremely rare in most cases.

It used to be that people used dynamic memory allocation to beat C with, but that is just a resource management issue. TBH, this is not rocket science. If you need dynamic memory allocation, you had damn well better know how to use it properly.

Its an example of laziness and people ignoring the machine.

Another example is performance; saying that a language comes within a factor of 2 of C's performance and therefore is fast is absolutely ridiculous. a factor of 2 is huge.

You have to remember that people who write C are dealing with machine-specifics day-in, day-out. we're bit-fiddling and writing MPU code and drivers, etc.

Basically, we're much more aware of the machine than higher-level softies, so what would normally be UB is actually DB in most cases, its defined by the compiler and hardware that we're intimately familiar with.

...and that isn't to say that you can't write high level abstracted code in C, the simplicity of the language lends itself to (properly) efficient implementation, not efficient in the sense of Java or Ruby ;o)

> The vast majority of all code you write will not invoke UB

That's a bit like saying “the vast majority of the haystack doesn't contain any needles”.

> most people tend to stick to an 'easy' subset of syntax

I'm not sure I understand what you mean. Undefined behavior has nothing to do with syntax. It's strictly a semantic issue.

> It used to be that people used dynamic memory allocation to beat C with, but that is just a resource management issue. TBH, this is not rocket science.

If I understand correctly, the objection isn't that it's rocket science, but rather that you get little help from your tools if you do it wrong. Memory debuggers will only tell you about memory management bugs that manifest themselves in a particular program run. If a bug will only manifest itself under conditions that are hard to replicate, you're out of luck.

Of course, none of this is an indictment of manual memory management per se, or suggests that garbage collection is a universally good solution. But manual memory management has usability issues, which fortunately being addressed in more modern language designs like Rust.

> If you need dynamic memory allocation, you had damn well better know how to use it properly.

Sure, but are better compile-time diagnostics too much to ask for? Notice that compile time diagnostics don't introduce any runtime performance penalty.

> Another example is performance; saying that a language comes within a factor of 2 of C's performance and therefore is fast is absolutely ridiculous. a factor of 2 is huge.

No disagreement here.

> so what would normally be UB is actually DB in most cases,

As far as I can tell, the trend among C and C++ compiler writers is to optimize programs very aggressively under the assumption that UB simply will never happen, rather than to turn UB into DB.

> its defined by the compiler and hardware that we're intimately familiar with.

Well, “works on this machine” isn't good enough for most of us.

You're correct.... the vast majority of the haystack doesn't contain any needles, thats the point. And you also know where the needles tend to be and stay away from that area.

I'm not implying that UB doesn't exist, simply saying that using C is a different mindset.

If you use C, you dont just use the language, you use the language, the toolchain and the machine, you're familiar with the whole stack, quite often down to the metal.

The point about memory management is that memory management is just case of the general problem, i.e. resource management. resource management is a skill you need to have if you're a softie and making it easier in one specific case (RAM) is not a generic solution. Better that you learn how to do it properly then apply that knowledge in all situations (files, RAM, power, etc). e.g. where is the GC-equivalent for power management? or file handles? its the same problem in a different domain.

> The point about memory management is that memory management is just case of the general problem, i.e. resource management.

Wholeheartedly agree. I'm aware that GC is no solution for this problem. But I'm not arguing in favor of GC - I'm arguing in favor or making manual resource management safer, for example, like Rust does. Resource management is every single bit as manual as in C - the only difference is that the compiler yells if you do it wrong.

> The vast majority of all code you write will not invoke UB, most people tend to stick to an 'easy' subset of syntax, unlike say C++ where everyone uses a different subset of features making it in effect multiple languages.

Even integer addition very easily leads to undefined behaviour.

> It used to be that people used dynamic memory allocation to beat C with, but that is just a resource management issue. TBH, this is not rocket science. If you need dynamic memory allocation, you had damn well better know how to use it properly.

If you're going to solve a quadratic equation you should damn well know how to do it properly, by completing the square. But once you know that you should use the formula, because it makes it a lot easier. If you complete the square every time out of pride, you're just wasting everyone's time.

> A combination of testing the known edge cases, wraparound issues, size issues, static analysis and tooling means running into an example of UB is extremely rare in most cases.

Sure. You can do enough work to eliminate it. Or you can use a language where you don't need to.

> Its an example of laziness and people ignoring the machine.

Laziness is one of the cardinal virtues of a programmer

> Another example is performance; saying that a language comes within a factor of 2 of C's performance and therefore is fast is absolutely ridiculous. a factor of 2 is huge.

A factor of 2 is irrelevant most of the time. If you're growing exponentially, a factor of 2 will let you put off the point where you have to start scaling out by maybe a few months. If you're not growing exponentially, you probably won't hit performance limits at all.

> Basically, we're much more aware of the machine than higher-level softies, so what would normally be UB is actually DB in most cases, its defined by the compiler and hardware that we're intimately familiar with.

Until the compiler adds new optimizations. Sure, if you're never going to upgrade the compiler maybe you can get away with C.

> ...and that isn't to say that you can't write high level abstracted code in C, the simplicity of the language lends itself to (properly) efficient implementation, not efficient in the sense of Java or Ruby ;o)

Without native tagged unions you won't get far up the abstraction ladder. You can write your own with macros sure, but they won't interoperate with anyone else's or any libraries you'd want to use.

> UB is simply the latest stick to hit C with. In day-to-day working nobody worries about UB at all as you generally don't notice it.

I agree that in day-to-day working nobody worries about it, and I see odd behaviors all the time because of it. In particular as fewer applications are using C, a much higher fraction of C becomes systems and embedded where you are more likely to accidentally run afoul of choices that were made to compete with FORTRAN on numerical performance.

A read from NULL will crash on most unixen, but will not crash on some targets without an MPU and when running in kernel mode, so may be left lurking (see the linux kernel).

The C89 aliasing rules in particular are completely at odds with a lot of kernel and device driver code, and in addition where the int size was 2 bytes previously but is now 4 bytes you can have signed overflow where before the behavior was well defined:

    UINT2 x; // 16 bit integer
    ...
    x+=2;    // addition mod 2**16 on 16 bit targets, undefined behavior on 32 bit targets.

These are some real-world bugs I've dealt with.

> (and yes, I do have plenty of experience in it, I've been using it for the past 20 years, have you?).

I've been using it professionally for only about 15 years, but I started using C at home in '92.

[edit]

> Same with lack of a GC; this is a plus point for C for most applications, not a negative.

This is a bit of a non-sequitur, as I didn't mention memory management at all. C doesn't need a GC. It could use more memory safety though. There's been plenty of academic research on improving C's memory safety without significant runtime overhead; a lot of those techniques were used in rust. There are plenty of tools that can catch a large fraction of memory errors at compile time, which is a good thing.

Java's collections don't (and can't, without high cost) make any guarantees that they will throw such an exception whenever they are modified concurrently... for one, data races can have weird consequences that aren't easy to detect. On that point, data races in Java are not undefined behaviour, they just have very weak guarantees about what happens (basically isolated loads and stores do reasonable things, and no fancier operations are available) which is another alternative to the Rust approach and the GIL approach.

> they just have very weak guarantees about what happens (...) which is another alternative

Not a very usable one. It means that atomicity is something you have to fight very hard to actually get, and very easy to accidentally destroy.

Thats not really what peole refer to in C when they talk about undefined behaviour.

(0) It does not. It has a GC, and all features you'll likely use are memory-safe. You can of course use unsafe methods and raw pointers, but those are documented that they are unsafe and are usually only used for writing bindings to a C library. Macros for example are evaluated and constructed at compile-time, so no undefined behaviour can come from those. Most methods have different behaviour. For example, one method may throw an exception, another return an error, and another simply return Nil. You know if you are using `hello!` `hello?` or `hello`, so no undefined behaviour there.

(1) Not at all, look at the source implementation of their language implementation. For example, the lexer: https://github.com/crystal-lang/crystal/blob/master/src/comp... Seems pretty clear to me.

(2) Not entirely sure what you mean since that is such a broad case, but as stated, Crystal stdlib is mostly safe.

> (0) It does not. It has a GC, and all features you'll likely use are memory-safe.

Nice.

> (1) Not at all, look at the source implementation of their language implementation. For example, the lexer: https://github.com/crystal-lang/crystal/blob/master/src/comp.... Seems pretty clear to me.

How am I supposed to learn the language's semantics from a lexer?

> (2) Not entirely sure what you mean since that is such a broad case, but as stated, Crystal stdlib is mostly safe.

Consider this use case: I spawn five fibers. Can I send the same mutable object to all five? If so, can they attempt to mutate the object without properly taking turns? (e.g., using a mutex)

> How am I supposed to learn the language's semantics from a lexer?

Not what I wanted to achieve, but the lexer contains some frequently used methods and is fairly simple and straight-forward, but if you want to learn the semantics why not just go to their docs? https://crystal-lang.org/docs/syntax_and_semantics/index.htm...

> Consider this use case: I spawn five fibers. Can I send the same mutable object to all five? If so, can they attempt to mutate the object without properly taking turns? (e.g., using a mutex)

Taken from the docs:

Crystal has Channels inspired by CSP[1]. They allow communicating data between fibers without sharing memory and without having to worry about locks, semaphores or other special structures.

...

Because at this moment there's only a single thread executing your code, accessing and modifying a global variable in different fibers will work just fine. However, once multiple threads (parallelism) is introduced in the language, it might break. That's why the recommended mechanism to communicate data is using channels and sending messages between them. Internally, a channel implements all the locking mechanisms to avoid data races, but from the outside you use them as communication primitives, so you (the user) don't have to use locks.

[1] - https://en.wikipedia.org/wiki/Communicating_sequential_proce...

> but if you want to learn the semantics why not just go to their docs? https://crystal-lang.org/docs/syntax_and_semantics/index.htm...

Yep, fair enough. I'm somewhat worried about how abstract classes work: https://crystal-lang.org/docs/syntax_and_semantics/virtual_a...

Apparently, Crystal can infer the methods of an abstract class from the methods of its subclasses. In the Animal/Dog/Cat example, what happens if, in a separate module, if define a Snake class that doesn't have a `talk` method? There are several possibilities, sadly all pretty bad:

(0) Does the type checker retroactively decide that not all Animals can talk?

(1) Does the type checker decide that Animal subclasses can't be defined in a separate module?

(2) Does the type checker decide that, if an Animal subclass is defined in a separate module, it must have all the common methods to all Animal subclasses defined in the same module as Animal?

(3) Is type checking not modular?

> That's why the recommended mechanism to communicate data is using channels and sending messages between them.

I'm asking about the errors that the language prevents, not the community's conventions.

> In the Animal/Dog/Cat example, what happens if, in a separate module, if define a Snake class that doesn't have a `talk` method? There are several possibilities, sadly all pretty bad

The abstract class defines which methods every class that inherits from it must define by using abstract methods. If you write a class that inherits from an abstract class, and you do not define a method that the abstract class says that you absolutely must define, the compiler will raise an error for you. You can inherit from classes between modules.

> I'm asking about the errors that the language prevents, not the community's conventions.

I haven't actually tried it, definitely something I'll check out another time. I understand your concern though!

> The abstract class defines which methods every class that inherits from it must define by using abstract methods.

In their example, the type checker can infer that Animal has a `talk` method, even if it's never explicitly defined:

    abstract class Animal
      # no talk method here!
    end
    
    class Dog < Animal
      def talk
        "Woof!"
      end
    end
    
    class Cat < Animal
      def talk
        "Miau"
      end
    end
    
    class Person
      getter pet
    
      def initialize(@name : String, @pet : Animal)
      end
    end
    
    john = Person.new "John", Dog.new

In their own words, “Now the code compiles:”

    john.pet.talk #=> "Woof!"

Now, what happens if, in a separate module, I define a Snake subclass of Animal, without a talk method? What happens in this corner case isn't documented anywhere.

Type system design is very serious business, and can't be done by mindless trial and error. When a type system has a safety hole, patching it is pretty much guaranteed to break other people's code.

It will simply stop compiling the code and it will say "undefined method 'talk' for Snake". You will get a similar error if `talk` is defined as an abstract method in the base abstract class. So abstract methods are just a standard way to document this and to improve error messages. There's no safety hole here.

So the behavior of a subclass of an abstract class depends on whether both classes are defined in the same module or in different ones:

(0) If Snake is in the same module as Animal, the error is that “john.pet.talk” is a call to a nonexistent method.

(1) If Snake is in a different module from Animal, the errors is that Snake doesn't have a talk method.

This isn't nice.

I can't seem to reply to your reply to this, but the error message has nothing to do with where a class is defined.

You can't compile a part of your application in crystal, there are no linked crystal libraries. You compile your whole app, will all class definitions. The compiler then will have all the type information to know if a method is missing in a subclass, when that method is used from a parent class.

Well, that's even worse. Whole-program compilation has positive aspects to it, like enabling more aggressive optimizations, but it should be strictly opt-in.

For future reference: The easiest way to reply to a message that doesn't have a “reply” link below, is to click on the “X minutes ago” link above.

Thank you! I didn't know that easy way to reply.

The compiler does some incremental compilation for the generated object files, so compile times are kept relatively small. Other than that, I don't think it makes a big difference for a developer except saving compile times. On the other hand, in this way you can't have a compiled library conflict so you have to "clean and rebuild" when this happens.

For example in Ruby there's no such thing as pre-compiling a gem, and every time you run an app the whole app is "analyzed" (parsed and converted to VM instructions), and so you can think in Crystal it's the same (except that it's compiled to native code)

Incremental compilation isn't a good alternative to actually separate compilation. If I implement a module Foo that depends on another module Bar, the only information I need is the interface Bar exposes, so I shouldn't have to wait until Bar is actually implemented to begin implementing Foo.

> I'm asking about the errors that the language prevents, not the community's conventions.

My understanding is that, at the moment, the language doesn't have native threads yet. The design of multi-threading behavior and errors the language prevents is still being worked out.

Reply on news.ycombinator.com