Inspired by @fasterthanlime's rants about how Go sucks, I've been looking into other new(ish) languages that target sorta similar use cases...

Follow

The most promising of these IMO is Crystal. Its syntax is inspired by Ruby, but it's statically typed and ahead-of-time compiled with LLVM. Unlike Go, it has sum types which are used to represent nil-able values, like Rust's Option<T>. Like Go, it has a garbage collector, and uses green threads and channels for concurrency.
crystal-lang.org/

Nim is another new ahead-of-time compiled language with garbage collection. Like Vala, it gets transpiled to C then compiled with a C compiler. Curiously, it has multiple options for garbage collectors, or the garbage collection can be selectively disabled for manual memory management.
nim-lang.org/

Then there's Zig, which isn't memory safe and has C's (lack of a) concept for strings where strings are just a blob of arbitrary bytes with no associated meaning, so, uhh... I don't care. ziglang.org/

Julia is really neat. Like Crystal, it is built on LLVM, but it is JIT compiled. Julia excels in math-intensive use cases including machine learning, scientific analysis, and data visualization, where Python has historically been used but Julia is much faster. It's dynamically typed and uses multiple dispatch, making it really nice for generic coding.
julialang.org/

Researching other languages got me thinking: what is it that makes Rust so awesome? It's not one or two features, but the synergy of many great features that makes Rust so awesome. But it's not just that, it's also the way Rust combines low level capability with expressive high level, zero cost abstractions that make it nice to organize large projects. It scales from embedded, bare metal firmware and kernel drivers to complex, cross platform GUI applications.

@be have you looked at Jai? I keep hearing very good things about it, the downside is that it's still beta and not released as FLOSS yet (the author and main developer has strong opinions about releasing stuff When It's Ready™).

@rysiek I had not heard of Jai before. There isn't a lot of information available about it yet. Based on this...

github.com/Jai-Community/Jai-C

I'm not clear what it's going to be good for. It targets similar use cases as Rust, but lacks many of Rust's benefits.

@be you'd need to talk to @smarimc / @smari about the specifics. But my rough understanding is that where Rust errs on the side of safety/security, Jai errs on the side of speed, without falling into C's traps.

The main developer is a game developer by trade, so that makes sense.

Relevant:
internals.rust-lang.org/t/jai-
jai.community/t/comparison-wit

Anyway, just putting it on your radar.

@be I'm excited to splice it into my Linux From Scratch study schedule! Looks like quite the elegant language!

@Alamantus V does look really interesting. It seems like a simplified Rust. Time will tell if it can really match the memory safety and concurrency features of Rust. Of all these languages, V looks like the only one I might choose over Rust. But I am concerned that V is trying to put too much into the language and standard library. A language-level ORM is cool... but does that really belong in the language?

@Alamantus I appreciate that V is taking inspiration from Rust and Swift on how to avoid tracing GC.

@be @Alamantus I removed it from the list of languages to care about after reading this series¹ by @cadey

¹ https://christine.website/blog/series/v

@eriol @Alamantus @be yeah, I'd highly suggest looking into not V. Anything but V. The whole saga has really made me rethink how I want to treat forward looking statements.

As for a language to play with, I'd suggest Rust or Go. Both are equally capable of serving production grade traffic and are both used by very large companies in ways that stress out machines to hell and back.

Just pick something at random and write a project with it, like a Mastodon bot that uses a SQLite database somehow.

There's also the blog engine strat: christine.website/blog/new-lan

@eriol @Alamantus @cadey That blog is so obnoxiously pedantic and nothing in it seems like a big deal IMO.

@be @eriol @Alamantus Here are the big parts that I think are worth pointing out:

1. They are overpromsing (even if by omission!) and vastly underdelivering
2. The author is willing to ban people from the community for calling them out on the misleading claims

Overall, there is nothing exciting about V. It exists. It is a thing you can reasonably use for programming. I just really wouldn't suggest you do that. It's probably fine but overhyping things like it's the next coming of sliced bread really isn't the most productive idea in my book.

Also if my articles sound overly inflammatory or the like I welcome you to compare the claims in the documentation vs the observable behavior of the project in action. Be even more skeptical if your reaction to this message is one of revulsion or the like because it sounds like I am being a "hater". I am not trying to come out and be negative about this in an effort to harm the reputation of the V team or whatever. I am speaking the observable truth that I have seen through lived experience taking an honest look at it.

Just don't expect it to be an untold revolution to the fundamental state of programming as a science. At least it's an interesting take on a minimalistic compiler to see what you can really discard before things stop working the way you want.

@be @eriol @Alamantus At the least I'd expect a pre-1.0 language ty say things like "will", "aims to" or "is planned to" instead of "is" or "does" as was observable during the time that those articles were written.

Whatever though. Make your own choices.

@be It's not new, but Haskell deserves to be on this list. Well suited to compute-heavy work, not so much for I/O!

@alcinnz @be Idris seems like an interesting ML-like language as well.

@be As a primarily embedded dev, most new hot languages leave me very not interested, rust sounds pretty good.

@LovesTha Yep, AFAIK the only other language comparable to Rust that scales from bare metal embedded use cases to massive userspace applications is C++, and, well... I don't think I need to expand on that. C technically can be used for that, but who wants to write C for a big, complex project?

@be Yeah, C has it's limits. And when you hit them you should have switch to at least C++ a long time ago.

@be And C++ when it launched was good, modern C++ as actually used by sane companies is also pretty good (not the 'sane' bit means you don't use lots of what is possible in C++)

@LovesTha Yes, you can simply not use lots of C++'s crap, but that will not get you memory safety nor safety from data races.

@LovesTha @be My experience with C++ to date has been that sanity is quickly lost as you add external dependencies to the project. Exceptions, generics, RTTI, etc. all are "viral" in the sense that once one compilation unit uses them, it infects the interfaces it exposes, which means client code has to use them, etc.

@vertigo @LovesTha @be nearly all codebase of big size (game engine) I worked had pretty limited external dependencies. Even part of the language that most people would consider as "safe" and good such as vectors, string, functors were reimplemented.

The biggest reason for "reinventing the wheel" being portability as once you introduce new compilers and new platforms you start getting enough problems that recreating your data structures actually make sense. Clang hegemony helps in this regard.

@skenizen @vertigo @be safety critical things go that way too. Easier to implement memcpy than it is to prove stdlib is safe.

@skenizen @LovesTha @be That must have been a right pleasure to work with. I envy you. My experience is with commercial software, and is quite different. "Here's our coding conventions, which you must abide by, except when dealing with these dependencies." And, of course, is never have to deal with them directly, only transitively.

If I could quickly generate a meme, I'd make the one with Buzz Lightyear, saying, "BOOST ... BOOST as far as the eye can see!!" I still have nightmares.

@vertigo @LovesTha @be One downside of having custom logic for most things is that you can't rely on common "wisdom".

I remember at the beginning of Stack Overflow (pre-C++11), any question on C++ was basically : use this part of BOOST, upvoted hundred times and sometime if lucky one person giving the actual answer with 2-3 upvote totally down the stack!

@alcinnz @LovesTha But GNOME doesn't anymore. What GNOME projects started in the last 5 years are using C? They're using Rust or Vala now.

@be @LovesTha True. I like Vala!

It'll be interesting to bridge over from Haskell to Vala in order to comfortably wrap my browser engine in a GTK widget...

@alcinnz @be @LovesTha IIRC, Gnome only wanted the libraries to be in C; I don't think they care about the applications per se.

@vertigo @be @LovesTha True. They did go out of their way to allow apps to be written in any language!

@LovesTha @be Can confirm; we are using Rust at my job for embedded programming. There are some rough edges, but they're more the fault of running out of resources than a problem with the language itself.

@be I'm pretty flexible about language syntax but I've grown to enjoy the tough love of the Rust compiler. Other compilers let me get away with so much bad behavior!

@be did you discover any more detail about the speed vs python?

Most serious numerical ops in python use numpy, which calls out to C afaik

@silico_biomancer @be I think in any situation where you're using only numpy operations python, Julia, R, etc will all have similar performance because they're all calling the same BLAS operations. As soon as you want to do something that's not supported by numpy you either need to start writing C++ or accept python's normal performance. Julia tries to solve this problem.

@hasnep @be that's what I would have assumed. Can you think of examples where you would need to compute a lot outside of those areas?

Joining tables on keys perhaps?

Seems like for the most part it just comes down to which glue language you like the smell of best

@silico_biomancer @be Joins in python can be done with pandas. The first thing that comes to my head that numpy can't do is have matrices with elements of any type. If you want to invent a new type and define multiplication of two matrices of that type you can do it in Julia and it'll be fast.

@be Julia is very good. Fast and powerful with many functional programming features. Multiple dispatch is excellent for generic programming and multi-processing capabilities are also very good.

@be I've been using nim for a while now, and I really enjoy it, at least for personal projects :)

@be Yeah, the type system of Crystal seems neat, it what made me interested in it, sadly I didn't end up having to use it.


Also did you look into https://harelang.org/ ? I should make a blog post about it at some point.

@lanodan @be I'd love a good comparison between Zig and Hare

I'm very curious about the difference in principles and how this plays out in practice

They both seem like "a better C" as far as I can tell

I imagine Zig's fallible allocations will become part of the kernel-dialect of Rust, which is probably the only safety feature that Zig has that Rust currently lacks

@jokeyrhyme @lanodan Like Zig, Hare is not memory safe. I don't think the world needs any more memory unsafe languages.

@be @lanodan I'm inclined to agree, trying to stop using anything written in a memory-unsafe language where feasible

But, there's some innovation and experimentation in this space that might, at least, make safer languages even better

Sign in to participate in the conversation
FLOSS.social

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).