Comment by ChuckMcM | Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

Go's PASCAL. :-)

Interesting language, looks especially interesting for rapidly throwing things together. Add a solid API to a window system toolkit and you've got a logical successor to Visual Basic.

Write an editor, cross compiler for some other language, and a shell in it. That will tell you if it is a good "systems" language.

Write a distributed service, a web application, and a database in it. That will tell you if it is a good "web" language.

Write a physics simulator, a responsive AI, and a real time user interaction model in it. That will tell you if it is a good "game" language.

Write a convolution, a linear regression, and a monte carlo simulation in it. That will tell you if it is a good "modeling" language.

In my Christmas wishlist is a language that I can write a good 3D CAD package in. The current choice is C++ but that can be really clumsy in many ways. Such a language would have a strong linear algebra library and a boolean solids package. Nobody is working in that problem space from a language perspective as far as I can tell.

There are some interesting projects for these

CPU Raytracer https://github.com/l3kn/raytracer

CRSFML multimedia/game library https://github.com/BlaXpirit/crsfml

> Structs in Crystal are are always passed by copy, so modifying them can be problematic. For example, my_struct.x = 7 is fine but array_of_structs[2].x = 5 will not work. To work around this, copy the whole struct, modify it, then write it back. Better yet, avoid the need to modify structs (work with them like with immutable objects).

I can see that becoming problematic for simulations (lots of particles, for example) and games especially. At some point you're going to want pass-by-reference and in-place mutations for better performance (ideally hidden behind some form of encapsulation of course). Is there no way around this?

Crystal has both classes and structs. Instances of classes are passed by reference, while those of structs are passed by value.

What would it need to be a good embedded system or distributed system language?

For embedded, I'd start with the language primitives easily producing efficient primitives of the machine, the cost (esp time/memory) of language primitives must be intuitive (ideally deterministic), be able to size/manipulate variables at the bit level, probably support pointers, have anywhere from tiny to no runtime, probably a good C FFI given existing stuff will be C-based, and ideally support inline assembly for stuff specific to MCU/CPU if not C-based.

Any embedded developers want to add to or dispute anything on that list? It's recent draft of a reference I'm working on to answer this common question.

I think that is a good start, I would add interrupt routines to it. Perhaps interrupt routines, arbitrary memory manipulation on a bit boundary, and tight code.

> language primitives easily producing efficient primitives of the machine

I think crystal already does this well, especially in release mode when llvm gets to optimise the program as a whole. This also seems like something that can be improved without any breaking changes, which is nice.

> the cost (esp time/memory) of language primitives must be intuitive (ideally deterministic)

I'm less sure of this, maybe having dynamic dispatch would be an issue here? I think that release optimisations would make the performance of any code pretty variable depending on what optimisations are applied. Asterite probably knows more about this than me.

> be able to size/manipulate variables at the bit level

Crystal supports bitwise operators for doing bit twiddling, and obviously llvm optimises that very well. As for sizing values at the bit level, unfortunately only the standard Int8, Int16, Int32, Int64 and their unsigned varieties are available for integers in crystal. There also isn't a great deal of fine control over padding and placement in structs, apart from padding on/off. This could probably be easily improved.

> support pointers

Crystal supports both pass-by-reference and pass-by-value structures (class and struct), and all pointer operations available in C should be easily doable in Crystal.

> have anywhere from tiny to no runtime

Crystal has quite a big runtime by default, but fortunately it's really easy to turn it off and import only the bits you want using --prelude=empty, which imports only the bare minimum [0]. You could then build your own standard library built without a GC, or implement a GC module (for example [1] which just uses malloc) which would allow you to reuse String, Array, hash, etc.

> a good C FFI

https://crystal-lang.org/docs/syntax_and_semantics/c_binding...

> support inline assembly

Crystal has this too, used here: https://github.com/crystal-lang/crystal/blob/master/src/fibe... although this too could be improved.

Overall I think Crystal has promise, and could be used for embedded programming without too much hassle, although its not a high priority of the core team. I know someone built a small kernel which just outputted "hello world" on x86 qemu.

[0] https://github.com/crystal-lang/crystal/blob/master/src/empt... [1] https://github.com/crystal-lang/crystal/blob/master/src/gc/n...

A Ruby-like language that's already that close to embedded needs? Wow, Im impressed. Might toy with it sometime in the future.

Linear Algebra is already a solved problem - there's no need to rewrite the many established C/C++/Fortran code that has been optimized for linear algebra over the last 40 years.

Why re-write what has already been done? Stand on the shoulders of giants.

My understanding is you can call C code from Crystal bindings. It doesn't seem like you need to rewrite the wheel :-)

You already have bindings to BLAS, in https://github.com/mverzilli/crystalla , though I'm not certain how mature and full fledged it is.

> Why re-write what has already been done?

Because we can do better. For example, look at Mir GLAS, written in D.

https://github.com/libmir/mir-glas

1000s Kudos for Mir and Dlang. My language of choice.

At a first glance, it looks like the way they're optimizing the BLAS/LAPACK implementations is by making it CPU architecture specific - the same game that IMKL plays. That's probably why they are reaching the same performance as MKL as well.

Good to see they aren't reinventing the wheel, and openly expressing inspiration from Numpy is also a nice touch.

You can the same for any programming language or OR, so why bother creating new things.

Because 10k lines of D is easier to maintain than 20mb of assembler fortran mix. Plus you get all llvm niceties.

Removing compiling issues, keeping everything in one language. Plus, when you do, you find bugs. We've found a bunch in lapack implementing gonum (godoc.org/github.com/gonum/lapack)

not sure if you'll see this but python has some nice CAD packages already

http://www.pythonocc.org/

that's just one, some googling will help you find others

Thanks for the link! I will check it out.

Reply on news.ycombinator.com