- zcd ( @zcd@lemmy.ca ) 44•2 months ago
🦀
- mox ( @mox@lemmy.sdf.org ) 37•2 months ago
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.
- Ephera ( @Ephera@lemmy.ml ) 9•2 months ago
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.
- starman ( @starman@programming.dev ) English7•2 months ago
C# has native compilation capability, thanks to Native AOT
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
- Ephera ( @Ephera@lemmy.ml ) 4•2 months ago
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…
- nous ( @nous@programming.dev ) English4•2 months ago
How are they not memory safe in a multi-threadded context?
- unique_hemp ( @unique_hemp@discuss.tchncs.de ) 4•2 months ago
There’s nothing to prevent data races. I myself have fallen into the trap of using the same list from multiple threads.
- nous ( @nous@programming.dev ) English10•2 months ago
I don’t think data races are generally considered a memory safety issue. And a lot of languages do not do much to prevent them but are still widely considered memory safe.
- Ephera ( @Ephera@lemmy.ml ) 4•2 months ago
Yeah, that is why I prefixed that whole comment with “arguably”.
I feel like the definition of memory safety is currently evolving, because I do think data races should be considered a memory safety issue.
You’ve got a portion of memory and access to it can be done wrongly, if the programmer isn’t careful. That’s what memory safety is supposed to prevent.Rust prevents that by blocking you from passing a pointer for the same section of memory into different threads, unless you use a mutex or similar.
And because Rust sets a new safety standard, I feel like we’ll not refer to Java and such as “memory-safe” in twenty years, much like you wouldn’t call a car from the 90s particularly safe, even though it was at the time.- Saizaku ( @Saizaku@lemmy.dbzer0.com ) 5•2 months ago
There’s a reason why data races aren’t considered a memory safety issue, because we have a concept that deals with concurrency issues - thread safety.
Also for all it’s faults, thread and memory safety in java aren’t issues. In fact java’s concurrent data structures are unmatched in any other programming language. You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it’s a bit of a moot point.
- Ephera ( @Ephera@lemmy.ml ) 4•2 months ago
Oof, I guess, you’re not wrong that we’ve defined data races to be the separate issue of thread safety, but I am really not a fan of that separation.
IMHO you cannot cleanly solve thread safety without also extending that solution to the memory safety side.
Having only one accessor for a portion of memory should just be the n=1 case of having n accessors. It should not be the other way around, i.e. that multiple accessors are the special case. That just leads you to building two different solutions, and to thread safety being opt-in.That’s also the major issue I have with Java’s solution.
If you know what you’re doing, then it’s no problem. But if you’ve got a junior hacking away, or you’re not paying enough attention, or you just don’t realize that a function call will take your parameter across thread boundaries, then you’re fucked.
Well, unless you make everything immutable and always clone it, which is what we generally end up doing. - arendjr ( @arendjr@programming.dev ) 2•2 months ago
You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it’s a bit of a moot point.
In Java it isn’t always clear when something crosses a thread boundary and when it doesn’t. In Rust, it is very explicit when you’re opting into using
unsafe
, so I think that’s a very clear distinction.Java provides classes for thread safe programming, but the language isn’t thread safe. Just like C++ provides containers for improved memory safety, and yet the language isn’t memory safe.
The distinction lies between what’s available in the standard library, and what the language enforces.
- Saizaku ( @Saizaku@lemmy.dbzer0.com ) 4•2 months ago
Arguably modern c++ ( aka if you don’t use raw pointers), fits all categories.
- Ephera ( @Ephera@lemmy.ml ) 2•2 months ago
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?
- Saizaku ( @Saizaku@lemmy.dbzer0.com ) 5•2 months ago
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 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.
- arendjr ( @arendjr@programming.dev ) 1•2 months ago
Modern C++ does use references, which can also reference memory that is no longer available. Avoiding raw pointers isn’t enough to be memory safe.
- Buttons ( @Buttons@programming.dev ) English4•2 months ago
The question mine as well be “what is your favorite compiled language?”. There is a lot of overlap between the possible answers.
- AbelianGrape ( @AbelianGrape@beehaw.org ) 4•2 months ago
Yeah, I like subleq.
- compiler is extremely fast, faster even than
tinycc
- strongly statically typed: all values are
int
s. Since it’s all of them, you don’t even need to write it! - memory safe: the entire (virtual) address space is guaranteed to be accessible at all times so there’s no way to leak any of it (can’t release it anyway) or to segfault (it’s all accessible).
Subleq is the obvious winner in my mind.
- compiler is extremely fast, faster even than
- FizzyOrange ( @FizzyOrange@programming.dev ) 32•2 months ago
- tooLikeTheNope ( @tooLikeTheNope@lemmy.ml ) 6•2 months ago
Gleam?
https://gleam.run/- FizzyOrange ( @FizzyOrange@programming.dev ) 2•2 months ago
I dunno it looks well designed but I dunno why I would use it instead of Rust.
- I Cast Fist ( @ICastFist@programming.dev ) 2•2 months ago
Honest question, what would make you pick Gleam over Elixir? Both seem to have significant overlap
- FizzyOrange ( @FizzyOrange@programming.dev ) 6•2 months ago
Isn’t Elixer dynamically typed?
- I Cast Fist ( @ICastFist@programming.dev ) 1•2 months ago
Oh, I forgot that detail, makes sense. Does Gleam already have something equivalent to Phoenix for elixir?
- Dhs92 ( @Dhs92@programming.dev ) 28•2 months ago
Rust
- germanatlas ( @germanatlas@lemmy.blahaj.zone ) 25•2 months ago
That is a very specific subset
- sus ( @sus@programming.dev ) 26•2 months ago
Garbage collection is still allowed, and technically JIT languages are still compiled so it really isn’t that restrictive
- JackbyDev ( @JackbyDev@programming.dev ) English3•2 months ago
Java, the language so good you compile it twice!
- demesisx ( @demesisx@infosec.pub ) English24•2 months ago
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
- Cyclohexane ( @cyclohexane@lemmy.ml ) 2•2 months ago
Tell us more about unison
- demesisx ( @demesisx@infosec.pub ) English13•2 months ago
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:
- Lambda ( @lambdabeta@lemmy.ca ) 20•2 months ago
Ada, hands down. Every time I go to learn Rust I’m disappointed by the lack of safety. I get that it’s miles ahead of C++, but that’s not much. I get that it strikes a much better balance than Ada (it’s not too hard to get it to compile) but it still leaves a lot to be desired in terms of safe interfacing. Plus it’s memory model is more complicated than it needs to be (though Ada’s secondary stack takes some getting used to).
I wonder if any other Ada devs have experience with rust and can make a better comparison?
- collapse_already ( @collapse_already@lemmy.ml ) English5•2 months ago
I have done quite a bit of C, C++, Ada, and Pascal development. I recently got into Rust. I am still getting used to Rust, but it feels a bit like someone tried to apply Ada to C++. I like the modern development environment, but I am slower writing code than I would be in Ada or C++. The one feature of Ada that I really like and want other languages to adopt is the Rep spec. I write driver code and being able to easily and explicitly identify which symbol corresponds to which bit is really good.
- apoisel ( @apoisel@discuss.tchncs.de ) 18•2 months ago
OCaml.
- Cyclohexane ( @cyclohexane@lemmy.ml ) 8•2 months ago
Sad I had to scroll to the end to see this.
Ocaml is brilliant and has the nicest type features. It’s almost like Haskell but more approachable imo.
- AbelianGrape ( @AbelianGrape@beehaw.org ) 2•2 months ago
As a Haskell programmer, “OCaml has the nicest type features” hurts just a little bit.
I sometimes teach a course in OCaml. The students who are very engaged inevitably ask me about Haskell, I encourage them to try it, and then they spend the rest of the semester wondering why the course is taught in OCaml. Bizarre how different that is from when colleagues in industry want to try Haskell.
- Cyclohexane ( @cyclohexane@lemmy.ml ) 1•2 months ago
What are your thoughts on this comparison? https://github.com/sidkshatriya/me/blob/master/007-My-Thoughts-on-OCaml-vs-Haskell-Rust-2023.md
- AbelianGrape ( @AbelianGrape@beehaw.org ) 1•2 months ago
Largely reasonable?
Haskell is not good for systems programming which sums up about 60-70% of that post. Laziness is lovely in theory but many industry uses of Haskell use stricthaskell for all or most of their code, so I certainly agree with that part too.
Their largest complaint about using Haskell for small non-systems programs seems to be the mental overhead induced by laziness. But for me, for small programs where performance isn’t a huge concern (think Advent of code or a script for daily life) laziness reduces my mental overhead. I think that author is just especially concerned about having a deep understanding of their programs’ performance because of their systems background. I worry about performance when it becomes relevant. Debugging Haskell performance issues is certainly harder than strict languages but still totally doable.
The lack of type classes or other form of ergonomic overloading in OCaml is easily the single “feature” most responsible for the language never taking off.
- Cyclohexane ( @cyclohexane@lemmy.ml ) 1•2 months ago
As someone who is not deep into type theory or functional programming, can you please explain why you mean by “ergonomic overloading”?
My understanding is that ocaml mitigates the need for type classes through its more advanced module system. So far I have been enjoying the use of OCaml modules, so I’m curious what exactly I’m missing out on, if any.
Thanks for taking the time to talk with me btw!
- AbelianGrape ( @AbelianGrape@beehaw.org ) 1•2 months ago
You have to be explicit about which module you’re using at all times, even though 99% of the time only one could apply. When the type class resolution is unique, but complicated, there’s no mental overhead for the Haskell programmer but getting all the right modules is a lot of overhead for the OCaml programmer. It also lets us write functions that are polymorphic under a class constraint. In OCaml you have to explicitly take a module argument to do this. If you want to start composing such functions, it gets tedious extremely fast.
And then even once you’re using a module, you can’t overload a function name. See:
+
vs+.
. Basically modules and type classes solve different problems. You can do some things with modules that you cannot ergonomically do with type classes, for example. create a bit-set representation of sets of integers, and a balanced search tree for sets of other types, and expose that interface uniformly from the same module functor. But Haskell has other ways to achieve that same functionality and more.OCaml’s type system cannot replicate the things you can do with Haskell’s higher kinded types, type families, or data kinds at all (except for a fraction of Haskell’s GADTs).
- xigoi ( @xigoi@lemmy.sdf.org ) English2•2 months ago
I’ve recently been trying to learn OCaml and find it really nice. The major pain points are
- C-style separate compilation with manually created headers
- Small standard library
- No generic print function
- Hard to use external libraries
- AbelianGrape ( @AbelianGrape@beehaw.org ) 1•2 months ago
Is
Printf.printf
not a good generic print function? It’s even variadic!- xigoi ( @xigoi@lemmy.sdf.org ) English1•2 months ago
When you want to print something, you can’t just
Printf.printf x
, you have to explicitly give it instructions on how to print a value of that specific type.
- Andromxda 🇺🇦🇵🇸🇹🇼 ( @Andromxda@lemmy.dbzer0.com ) English13•2 months ago
Hands down, Rust 🦀
- I Cast Fist ( @ICastFist@programming.dev ) 12•2 months ago
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
- asudox ( @AsudoxDev@programming.dev ) 11•2 months ago
Rust.
- KindaABigDyl ( @KindaABigDyl@programming.dev ) 10•2 months ago
Rust and Haskell (I think Haskell counts)
- xigoi ( @xigoi@lemmy.sdf.org ) English10•2 months ago
Nim
- BorgDrone ( @BorgDrone@lemmy.one ) 9•2 months ago
Swift
- 1rre ( @1rre@discuss.tchncs.de ) 9•2 months ago
C is memory safe if you program it well enough, so I guess C
- sus ( @sus@programming.dev ) 24•2 months ago
every single language (except Vlang of course) is memory safe if you program it perfectly.
Very, very few humans are capable of doing that, especially with C.
- SatouKazuma ( @SatouKazuma@programming.dev ) 17•2 months ago
C? Memory safe? HAHAHAHA
- MajorHavoc ( @MajorHavoc@programming.dev ) 4•2 months ago
Lol. The people downvoting your comment need to get good.
- Tja ( @Tja@programming.dev ) 4•2 months ago
Skill issue.