Scala is the the first I used and I like it a lot. If I had more time I'd love to give ocaml a decent try but I don't think I can get into it these days.
this post was submitted on 05 Oct 2024
79 points (93.4% liked)
Programming
17135 readers
400 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
Java
Elm, which is the loveliest language ever.
But I'm not sure if compiles to javascript counts as compiled, in which case haskell, which is considerably less lovely but still good.
Roc isn't finished, but it might turn out lovely, I don't know.
Transpiles :)
I started learning Go about 3 months ago and it quickly became one of my favorite languages. It feels like C with a bunch of Python niceties thrown in. And performance isn't super critical in my work so being garbage collected is fine with me.
purescript if you count “compile to js” as compiled.
Otherwise Haskell
After months of no practice, I forget quite a lot of stuff about them, regardless of language; therefore, none
EDIT: None of them is memory safe, that is
Nim. Small compiler, small executables, easy to understand (except the macros, I still can't get my head around them).
FreePascal. Yeah yeah, Pascal's dead, etc etc, but it being so verbose and strict certainly help programmers (or at least me) keeping things somewhat tidy.
Also shoutout to V
C# is good too. If you havent heard of lobster you should look into it.
load more comments
(4 replies)
Nim
Rust
With no context, this could be an honest attempt to learn about different tools, a thinly veiled set-up to promote a specific language, or an attempt to stir up drama. I can't tell which.
It's curious how such specific conditions are embedded into the question with no explanation of why, yet "memory safe" is included among them without specifying what kind of memory safety.
Yeah, arguably the only answer to this question is Rust.
Java/C#/etc. are not fully compiled (you do have a compilation step, but then also an interpretation step). And while Java/C#/etc. are memory-safe in a single-threaded context, they're not in a multi-threaded context.
Arguably modern c++ ( aka if you don't use raw pointers), fits all categories.
I don't know much about C++, but how would that do memory safety in a multi-threaded context? In Rust, that's one of the things resolved by ownership/borrowing...
Or are you saying arguably, as in you could argue the definition of the categories to be less strict, allowing C++ as well as Java/C#/etc. to match it?
Because you would be using std::shared_ptr<> rather than a raw pointer, which will automatically deallocate the memory when a shared point leaves the scope in the last place that it's used in. Along with std::atmoic<shared_ptr> implements static functions that can let you acquire locks and behave like having a mutex.
Now this isn't enforced at the compiler level, mostly due to backwards compatibility reasons, but if you're writing modern c++ properly you wouldn't run into memory safety issues. If you consider that stretching the definition then I guess I am.
Granted rust does a much better job of enforcing these things as it's unburdened by decades of history and backwards compatibility.
C# has native compilation capability, thanks to Native AOT
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
I mean, yeah, valid point. JVM languages also have GraalVM for that purpose.
But I'm playing devil's advocate here. 🙃
Arguably these don't count, because they're not the normal way of using these languages. Reflection isn't properly supported in them, for example, so you may not be able to use certain libraries that you'd normally use.
These also still require a minimal runtime that's baked into the binary, to handle garbage collection and such.
Personally, I enjoy fully compiled languages, because they generally don't lock you into an ecosystem, i.e. you can use them to create a library which can be called from virtually any programming language, via the C ABI.
You cannot do that with a language that requires a (baked-in) runtime to run.
But yeah, obviously someone just specifying "compiled" probably won't have all these expectations...
load more comments
(6 replies)
load more comments
(1 replies)
<?php
declare(strict_types=1)
😏 😁
🏃♂️💨
Crystal, but only because I’m a full time Ruby on Rails (and sometimes Hanami!) programmer.
It’s fantastic, and I had an excuse to use it at work when we needed to gather PHP Watchdog logs from a MySQL database and format, output them to STDOUT in a Kubernetes environment. (This was necessary for our log monitoring tools expecting data in a standard way, AKA not connecting to a database. 🤦♂️)
I know there are perhaps better options out there (Go, Rust, etc.) but from a Rubyist’s point of view Crystal gives you that “flow” from working in a beautiful language but with the performance boost of compiled software.
I'm anxiously waiting for Crystal to be able to compile for Windows so game development with it can get a kickstart
I’m kind of sad to say that I don’t think it’s going to reach the adoption level of Ruby but I hope I’m wrong.
🦀
C++, with some Skill
/s
but seriously, I don't know any language with a good, C/Cpp-like Syntax (so not Rust), with a good compiler (again not Rust). So I'm sticking to Cpp.
You should check out zig, its compiler can even be used for c/c++. If you have time to listen to an interview, this developer voices interview on zig explains some of the advantages of this: https://www.youtube.com/watch?v=5_oqWE9otaE&t=3970s
Thinking about zig for some stuff.
Mostly because those rusticles are pissing me off.
You forgot that beauty - "undefined behavior"!
Memory-safety can guarantee only so much safety! C++ can still blow up in your face, even with all the alleged memory-safety built into C++, thanks to all the UB traps in C and C++.
Rust is the closest language that has no such "gotchas".
That is a very specific subset
Not that specific tbh, most newer native languages these days are compiled and memory safe (Rust, Swift, Go, Kotlin Native, etc)
Garbage collection is still allowed, and technically JIT languages are still compiled so it really isn't that restrictive
C++ with -Wall -Werror, and no pointer diddling.
Its definitely best to try and avoid raw pointers, but even if you try really hard I found it's not really possible to get a Rust-like experience with no UB.
Even something as simple as std::optional - you can easily forget to check it has a value and then boom, UB.
The C++ committee still have the attitude that programmers are capable of avoiding UB if they simply document it, and therefore they can omit all sanity checks. std::optional could easily have thrown an exception rather than UB but they think programmers are perfect and will never make that mistake. There are similar wild decisions with more recent features like coroutines.
They somehow haven't even learnt the very old lesson "safe by default".
If I wanted memory unsafety I think I would consider Zig instead of C++ at this point.
As others have said, Haskell and Rust are pretty great. A language that hasn’t been mentioned that I REALLY want to catch on, though, is Unison.
Honorable mention to my main driver lately: Purescript
Tell us more about unison
Hard to describe in one phrase other than to say:
NixOS is to Linux as Unison is to Haskell
Content-addressing used in the context of programming languages in the service of solving the problem of distributed systems and their inability to share code across time and space.
Haskell has a content-addressed module that was perhaps influenced by Unison.
Here’s an excellent interview with one of the authors of Unison:
view more: next ›