Hacker News Reader

> crashes all the time with segmentation faults

We would very much appreciate any bug reports, even if you don't have the time to reduce (if you have filed under another username, thank you!).

> Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious.

I've seen a lot of Julia used in real world scenarios at companies and this is a pretty surprising claim. Segfaults are very rare – much rarer than in code written in C or C++. You may either have a messed up build of Julia or you could be using packages that call C libraries and do so incorrectly – that would certainly cause segfaults.

Sorry for not being clear on this. I was not talking about Julia code crashing. What I meant was when playing around with it, the julia binary would segfault here and there.

echo "print(3)" > boot.jl

julia --compile=all -O --inline=yes --check-bounds=no --output-o foo.o

Stefan can tell me if my hunch is right but check-bounds=no might turn off protections against out-of-bounds, memory access. If so, then that command is straight up telling it to segfault.

That's true, but it shouldn't segfault unless you do an out-of-bounds memory access, which this code isn't doing.

However, there seems to be a misunderstanding about how --compile=all (an experimental feature on the development branch of Julia) works. You can't run an impure operation like print during compilation. In the future, we may have a `julia-compile` command that translates a given Julia program into a binary equivalent, which seems to be what @fredmorcos expects, but that's not how the --compile=all flag works.

If you use Julia in the normal manner like you would Python, it's very reliable and stable. If you use experimental features and use them wrong, you can get segfaults. See these posts for more information about and some examples of using the Julia's experimental static compilation features:

http://juliacomputing.com/blog/2016/02/09/static-julia.html

http://juliacomputing.com/blog/2016/03/10/j2c-announcement.h...

That makes a lot of sense. Yeah, you should consider renaming it to something more clear. Maybe even change it into several commands with better names. Your docs frame the issue as whether it allows dynamic/JIT stuff or not. So, static-only, allow-dynamic, or allow-jit come to mind.

> Maybe even change it into several commands with better names.

That's what I've been pushing for – I don't think it make sense to continue to have all these compilation-related flags baked into the interactive `julia` command.

"There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code."

It is pretty straight-forward. However, Modula-2 and Pascal's are even more so as you can represent everything with a simple BNF grammar. There's more consistency, less corner cases, and so on. Every change they make is specifically designed to improve it while maintaining simplicity. The most complicated and modern one can be described fully in around 30 pages [1]. The uppercase and declarations throw people sometimes but keep in mind people used text editors w/out syntax highlighting.

http://www.oberon.ch/pdf/CP-Lang.pdf

re mutually exclusive. Nah, there's still tradeoffs you can make. Cyclone and Rust both do that with better design decisions to allow safe, manual management. At some point, you have to choose one or the other though. Your language design matters at this point where the compiler has to know it can remove a check. C's design is so rough and allows so much unpredictable behavior that this is an ongoing research problem for it. Whereas, it happened with Modula-3 libraries in one academic project and happened for Ada with SPARK.

Re Modula. Oh yeah, it's not updated anymore. I was just illustrating a language as lean and efficient as C that was safer & easier to compile. A better foundation. It was rejected by C users when it did have compilers. Plus, there's a Modula-2 to C compiler floating around the net.

Re Free Pascal and Lazaurus. Interesting feedback. I'll look into that to see if I or developers could remedy it. Except for Emacs: Lazarus is the IDE and better suited. Emacs support might stay dead. Re D. Yes, it's more like C++ but can be used where C is many times. I see you're looking for simple stuff, though. Re Cyclone. It's not simple but not hard either. Remember C is deceptively simple: using it safey is HARD. Cyclone is slightly more complex but way easier to use. Unmaintained, yes, but people (esp GCC or LLVM types) could pick it up any day... if they weren't glued to C. Good call on the Rust connection.

https://doc.rust-lang.org/reference.html#appendix-influences

re Julia. That's not good... re Ocaml. I think you're focusing too much on complexity of semantics vs complexity of effective use. It's worthwhile to increase learning curve a bit to boost productivity, safety, and maintenance. re Haskell. That reaction surprised me and you're the first to call it simple. Ive been holding off cuz it seemed ridiculously hard and different. What did you use to learn it? Btw, I agree fast Haskell is usually ugly but look up Tolmach's Habit programming language. It's on hold right now cuz he had a better project.

Thanks :) You've given me a lot to go through over the weekend.

Regarding Haskell, I used LYAH and the standard library documentation.

I agree that Haskell is not easy to learn and that the libraries require a lot of foundation before becoming understandable and/or usable (eg, Monoids -> Applicatives/Monads vs. "I just want to read the contents of this file into a string"). The language "proper" is built on extremely simple and straightforward concepts.