lambdabeta@lemmy.ca
on 05 Oct 2024 21:27
nextcollapse
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?
refalo@programming.dev
on 05 Oct 2024 23:54
nextcollapse
I would use Ada or Spark in a heartbeat if there was an easy-to-use, mature cross-platform GUI library for it.
collapse_already@lemmy.ml
on 06 Oct 2024 05:11
nextcollapse
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.
itsnotits@lemmy.world
on 07 Oct 2024 03:10
collapse
its* memory model is
1rre@discuss.tchncs.de
on 05 Oct 2024 21:28
nextcollapse
C is memory safe if you program it well enough, so I guess C
SatouKazuma@programming.dev
on 05 Oct 2024 21:33
nextcollapse
C? Memory safe? HAHAHAHA
refalo@programming.dev
on 05 Oct 2024 23:55
collapse
sus@programming.dev
on 05 Oct 2024 21:44
nextcollapse
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.
pathief@lemmy.world
on 05 Oct 2024 22:35
nextcollapse
Every car has airbags if you drive well enough. Right?
WolfLink@sh.itjust.works
on 06 Oct 2024 04:31
collapse
You can still make stupid mistakes in Rust. It may make it harder to make the most common mistakes, but pretending the guardrails are prevent any type of mistake is asking for a problem to happen.
The only one pretending mistakes canât happen is the person I replied to. Mistakes definitely can happen and no programming language is fool proof.
Continuing my car analogy, would you rather drive a car with airbags and seatbelts or one without them? Of course you can still have a fatal accident, but itâs nice to have safety features that make it as unlikely as possible.
MajorHavoc@programming.dev
on 05 Oct 2024 23:06
collapse
Lol. The people downvoting your comment need to get good.
frankenswine@lemmy.world
on 05 Oct 2024 21:19
nextcollapse
You mean⌠except Ada?
germanatlas@lemmy.blahaj.zone
on 05 Oct 2024 21:59
nextcollapse
That is a very specific subset
sus@programming.dev
on 05 Oct 2024 22:33
nextcollapse
Garbage collection is still allowed, and technically JIT languages are still compiled so it really isnât that restrictive
JackbyDev@programming.dev
on 07 Oct 2024 14:33
collapse
Java, the language so good you compile it twice!
paperplane@lemmy.world
on 06 Oct 2024 10:42
collapse
Not that specific tbh, most newer native languages these days are compiled and memory safe (Rust, Swift, Go, Kotlin Native, etc)
FizzyOrange@programming.dev
on 05 Oct 2024 22:02
nextcollapse
Rust for now, by a wide margin. But Iâm following other languages that I think have the potential to surpass it, including Vale (promises way more than it delivers currently), Koka, Hylo, maybe Lobster.
tooLikeTheNope@lemmy.ml
on 06 Oct 2024 08:49
collapse
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.
paperplane@lemmy.world
on 06 Oct 2024 10:40
nextcollapse
Coming from Haskell, OCaml always felt a bit strange to me. The double semicolons, the inconsistency in the standard library between curried and uncurried functions etc. Maybe Iâm confusing it with Standard ML though, canât remember.
cyclohexane@lemmy.ml
on 06 Oct 2024 17:18
collapse
I know double semicolons are a thing, but Iâve never had to use them. I forget what theyâre for, but yeah itâs supposed to be an escape hatch for something that shouldnât be happening iirc.
The curried snd uncurried functions⌠Maybe you are confusing with SML, because everything in ocaml is curried by default. Though admittedly the standard library could be more complete, but I personally am happy to use third party dependencies for less common things.
AbelianGrape@beehaw.org
on 07 Oct 2024 15:56
collapse
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@lemmy.ml
on 08 Oct 2024 22:50
collapse
AbelianGrape@beehaw.org
on 08 Oct 2024 23:28
collapse
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@lemmy.ml
on 09 Oct 2024 20:57
collapse
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@beehaw.org
on 09 Oct 2024 22:03
collapse
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).
AsudoxDev@programming.dev
on 05 Oct 2024 23:24
nextcollapse
Rust.
flubba86@lemmy.world
on 05 Oct 2024 23:54
nextcollapse
Julia
Buttons@programming.dev
on 06 Oct 2024 03:52
collapse
I wouldnât consider Julia statically-typed; am I wrong?
flubba86@lemmy.world
on 06 Oct 2024 04:07
collapse
Itâs actually optionally-typed. But if youâre liberal with type annotations you can treat it as statically typed.
KindaABigDyl@programming.dev
on 06 Oct 2024 00:11
nextcollapse
Rust and Haskell (I think Haskell counts)
mox@lemmy.sdf.org
on 06 Oct 2024 00:13
nextcollapse
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.
Buttons@programming.dev
on 06 Oct 2024 03:18
nextcollapse
The question mine as well be âwhat is your favorite compiled language?â. There is a lot of overlap between the possible answers.
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.
nous@programming.dev
on 06 Oct 2024 08:35
nextcollapse
How are they not memory safe in a multi-threadded context?
unique_hemp@discuss.tchncs.de
on 06 Oct 2024 08:44
collapse
Thereâs nothing to prevent data races. I myself have fallen into the trap of using the same list from multiple threads.
nous@programming.dev
on 06 Oct 2024 09:31
collapse
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.
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@lemmy.dbzer0.com
on 07 Oct 2024 02:46
collapse
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.
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@programming.dev
on 08 Oct 2024 06:26
collapse
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.
calcopiritus@lemmy.world
on 06 Oct 2024 18:05
collapse
Even though they are not what people mean when they say âmemory-safeâ, it is technically a kind of memory safety. It is unsafe to modify non-mutexed/non-atomic memory that another thread might be modifying at the same time.
starman@programming.dev
on 06 Oct 2024 14:18
nextcollapse
C# has native compilation capability, thanks to 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âŚ
Saizaku@lemmy.dbzer0.com
on 06 Oct 2024 23:51
nextcollapse
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?
Saizaku@lemmy.dbzer0.com
on 07 Oct 2024 03:00
collapse
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.
arendjr@programming.dev
on 08 Oct 2024 06:18
collapse
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.
paperplane@lemmy.world
on 08 Oct 2024 12:27
collapse
Most people would consider it so, but it actually does not either fulfill the argument I posed there: forums.swift.org/t/âŚ/31987
paperplane@lemmy.world
on 08 Oct 2024 13:15
collapse
Swift does have data race safety as of Swift 6 with their actor-based concurrency model and are introducing noncopyable types/a more sophisticated ownership model over the next few releases
Hmm, that sounds quite interesting. But because Iâve had to rebut that for everyone else that responded: Is it opt-in?
I guess, I would be fine with opt-in for the actor pattern, since you either do actors in your whole codebase or you donât, but otherwise, opt-in often defeats the point of safety measuresâŚ
paperplane@lemmy.world
on 09 Oct 2024 10:56
collapse
Itâs opt-in in Swift 5 mode and opt-out in Swift 6 mode, the Swift 6 compiler supports both modes though and lets you migrate a codebase on a module-by-module basis.
Agree that opt-in sort of defeats the point, but in practice itâs a sort of unavoidable compromise (and similar to unsafe Rust there will always be escape hatches)
AbelianGrape@beehaw.org
on 07 Oct 2024 15:51
collapse
Yeah, I like subleq.
compiler is extremely fast, faster even than tinycc
strongly statically typed: all values are ints. 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.
Dhs92@programming.dev
on 06 Oct 2024 00:36
nextcollapse
Rust
demesisx@infosec.pub
on 06 Oct 2024 00:43
nextcollapse
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@lemmy.ml
on 06 Oct 2024 17:21
collapse
Tell us more about unison
demesisx@infosec.pub
on 06 Oct 2024 19:12
collapse
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:
UFODivebomb@programming.dev
on 06 Oct 2024 01:02
nextcollapse
Scala 3 native. If the compiler was faster Iâd be even happier. Curious to try Ada
fruitycoder@sh.itjust.works
on 06 Oct 2024 01:41
nextcollapse
Python
Traister101@lemmy.today
on 06 Oct 2024 03:29
collapse
They specified statically typed languages. Python would be dynamically typed
MajorHavoc@programming.dev
on 06 Oct 2024 06:40
collapse
Python is dynamically typed by default, but lots of Python is statically typed.
Traister101@lemmy.today
on 06 Oct 2024 08:10
collapse
No python is statically typed. You have type hints, which makes the language tolerable but like their name implies itâs a hint at the type. You can perfectly legally pass in something completely different that doesnât conform whatsoever.
The primary thing static languages provide is static typing, that being the ability to determine before runtime that all the types are valid. A good example of this is how C++ programs will refuse to compile if you try to invoke a method that doesnât exist on the type. Thatâs because itâs statically typed. At compile time you know that the code is wrong. Dynamic languages fundamentally donât work like that. You cannot know until runtime if the method you called or the field you are trying to touch exists or not. Again type hints help a lot with this but that doesnât change how the language actually operates.
skulbuny@sh.itjust.works
on 07 Oct 2024 09:04
collapse
All static typing means is that types donât change, eg you canât declare a var as a string and later assign a number to it.
JackbyDev@programming.dev
on 07 Oct 2024 14:37
collapse
No.
skulbuny@sh.itjust.works
on 07 Oct 2024 15:03
collapse
Name one statically typed language that doesnât have that property. Name one non statically typed language that has that property.
JackbyDev@programming.dev
on 07 Oct 2024 18:45
collapse
Itâs much more involved than that. For example, static type systems involve checking that the functions you call accept the types of parameters youâre supplying then. Itâs a necessary part of static typing but alone is not sufficient.
If this code were a valid program in some hypothetical language but only failed at runtime then that would be an example of dynamic typing because the types cannot be verified statically (e.g., at compile time).
var a = 1
a = "a"
But youâre right, I donât really know of any languages like that. I couldâve sworn I heard this called strong typing but I canât easily find a source. And strong/weak typing are a mess of definitions nobody agrees on.
C# isnât exactly compiled, at least not into machine language.
It is transpiled into byte code that is run on a virtual machine that on turn is an interpreter/JIT-compiler.
Depending on why someone is asking for a compiled language that may or may not be a problem, because to the one writing the code it looks like a compiled language, but to the one running it it looks like an interpreted one.
Undertaker@feddit.org
on 06 Oct 2024 07:15
nextcollapse
It is compiled into bytecode. A transpiler translates to another programming language with the same level of abstraction. A compiler translates into a level that is nearer to or machine code.
sarahduck@lemmy.blahaj.zone
on 06 Oct 2024 08:29
nextcollapse
Not necessarily these days! With NativeAOT, C# can be compiled to machine code.
GetOffMyLan@programming.dev
on 06 Oct 2024 15:59
collapse
It is compiled to bye code. Just to be clear transpiling is completely different. It is also not interpreted.
But ahead of time compilation is available now. So you can compile straight machine code.
The newer tiered JIT can actually give better performance than a traditional compiler as well.
Overall C# is an awesome language. If performance is absolutely critical you can use raw pointers and manual memory management, but obviously you lose safety then.
pelya@lemmy.world
on 06 Oct 2024 05:56
nextcollapse
C++ with -Wall -Werror, and no pointer diddling.
FizzyOrange@programming.dev
on 06 Oct 2024 06:50
collapse
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.
cinnamon_tea@programming.dev
on 07 Oct 2024 17:07
collapse
I recently got bitten by exactly that std::optional UB and here I was thinking đ¤ after 12+ years in the industry starting all the way back in the day with C++03 that modern C++ was supposed to make things better.đ
cinnamon_tea@programming.dev
on 06 Oct 2024 06:17
nextcollapse
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â.
Olap@lemmy.world
on 06 Oct 2024 06:36
nextcollapse
D
stormeuh@lemmy.world
on 06 Oct 2024 06:37
nextcollapse
C on Morello (or any other capability machine).
undefined@links.hackliberty.org
on 06 Oct 2024 07:08
nextcollapse
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.
ICastFist@programming.dev
on 06 Oct 2024 11:56
collapse
Iâm anxiously waiting for Crystal to be able to compile for Windows so game development with it can get a kickstart
undefined@links.hackliberty.org
on 06 Oct 2024 19:11
collapse
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.
xigoi@lemmy.sdf.org
on 06 Oct 2024 07:11
nextcollapse
Nim
cafuneandchill@lemmy.world
on 06 Oct 2024 10:05
nextcollapse
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
30p87@feddit.org
on 06 Oct 2024 10:22
nextcollapse
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.
uthredii@programming.dev
on 06 Oct 2024 10:46
nextcollapse
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: www.youtube.com/watch?v=5_oqWE9otaE&t=3970s
InverseParallax@lemmy.world
on 06 Oct 2024 12:13
collapse
Thinking about zig for some stuff.
Mostly because those rusticles are pissing me off.
PushButton@lemmy.world
on 07 Oct 2024 14:39
collapse
I donât know what you are talking about?
Rust is such an amazing language, itâs so safe and clean and beautiful and simple and clear to read and such wow community that are making amazing crates for cargo because cargo is so cool I like it so much so easy toâŚ
Oh, and your fav lang sux alot!1 lolololllll
InverseParallax@lemmy.world
on 07 Oct 2024 20:01
collapse
âHey Linus, why havenât you rewritten the kernel in rust yet, you idiot?!?! Donât you realize youâre missing the future, old man!?!?â
Whatâs so bad about the Rust compiler? I know itâs slow, but given all the analysis itâs doing, it makes sense. And, from my own experience, setting correct optimization levels for dependencies along with a good linker makes incremental builds plenty fast.
ICastFist@programming.dev
on 06 Oct 2024 11:50
nextcollapse
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.
hessnake@lemmy.world
on 06 Oct 2024 14:28
nextcollapse
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.
bradboimler@lemmy.world
on 06 Oct 2024 17:36
nextcollapse
Java
davidagain@lemmy.world
on 06 Oct 2024 17:44
nextcollapse
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.
lambda@programming.dev
on 06 Oct 2024 19:41
collapse
Transpiles :)
yogsototh@programming.dev
on 06 Oct 2024 17:49
nextcollapse
purescript if you count âcompile to jsâ as compiled.
Otherwise Haskell
derpgon@programming.dev
on 07 Oct 2024 13:30
collapse
Thatâs transpiling, not compiling. Compiling is usually meant as âdirectly to machine codeâ, but I am yet to find an âofficial definitionâ.
AbelianGrape@beehaw.org
on 07 Oct 2024 15:46
nextcollapse
There is no official definition, in part because there isnât any formal way to define the term that satisfies our intuition.
Most treatments will handle âtranspilingâ as a special case of âcompilingâ and some will even handle decompilation as a special case where the object language is higher level than the source. Of course, even defining âhigher levelâ can be quite hard.
Plenty of languages âcompile to Câ and I see no issue with saying something âcompiles to js,â especially given that js mostly lacks features of purescript rather than the other way around.
tyler@programming.dev
on 07 Oct 2024 22:37
collapse
transpiling is just a type of compiling. compiling in no terms means âdirectly to machine codeâ.
HiddenTower@lemmy.world
on 07 Oct 2024 04:37
nextcollapse
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.
DavidDoesLemmy@lemmynsfw.com
on 07 Oct 2024 06:38
nextcollapse
Kotlin is nice
skulbuny@sh.itjust.works
on 07 Oct 2024 08:59
collapse
People donât understand that JIT languages are still compiled, JIT literally describes when itâs compiled.
threaded - newest
đŚ
<img alt="" src="https://gifdb.com/images/high/futuram-zoidberg-and-philip-j-fry-36l8lv8tqhxb5iqe.gif">
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?
I would use Ada or Spark in a heartbeat if there was an easy-to-use, mature cross-platform GUI library for it.
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.
C is memory safe if you program it well enough, so I guess C
C? Memory safe? HAHAHAHA
č˝ăĄçăăŚăă ăă
.
Please work on your Japanese.
.
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.
Every car has airbags if you drive well enough. Right?
You can still make stupid mistakes in Rust. It may make it harder to make the most common mistakes, but pretending the guardrails are prevent any type of mistake is asking for a problem to happen.
The only one pretending mistakes canât happen is the person I replied to. Mistakes definitely can happen and no programming language is fool proof.
Continuing my car analogy, would you rather drive a car with airbags and seatbelts or one without them? Of course you can still have a fatal accident, but itâs nice to have safety features that make it as unlikely as possible.
Lol. The people downvoting your comment need to get good.
Skill issue.
You mean⌠except Ada?
That is a very specific subset
Garbage collection is still allowed, and technically JIT languages are still compiled so it really isnât that restrictive
Java, the language so good you compile it twice!
Not that specific tbh, most newer native languages these days are compiled and memory safe (Rust, Swift, Go, Kotlin Native, etc)
Rust for now, by a wide margin. But Iâm following other languages that I think have the potential to surpass it, including Vale (promises way more than it delivers currently), Koka, Hylo, maybe Lobster.
Gleam?
gleam.run
Honest question, what would make you pick Gleam over Elixir? Both seem to have significant overlap
Isnât Elixer dynamically typed?
Oh, I forgot that detail, makes sense. Does Gleam already have something equivalent to Phoenix for elixir?
I dunno it looks well designed but I dunno why I would use it instead of Rust.
đ đ
đââď¸đ¨
The dash emoji. Always looks like a fart.
Swift
Hands down, Rust đŚ
Python with MyPy.
(Almost any language can meet those criteria, with enough shenanigans.)
But thatâs not compiled, not to binary at least.
WellâŚsort of.
(Everything is weirder than it seems at first glance.)
OCaml.
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.
Iâve recently been trying to learn OCaml and find it really nice. The major pain points are
Is
Printf.printfnot a good generic print function? Itâs even variadic!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.Coming from Haskell, OCaml always felt a bit strange to me. The double semicolons, the inconsistency in the standard library between curried and uncurried functions etc. Maybe Iâm confusing it with Standard ML though, canât remember.
I know double semicolons are a thing, but Iâve never had to use them. I forget what theyâre for, but yeah itâs supposed to be an escape hatch for something that shouldnât be happening iirc.
The curried snd uncurried functions⌠Maybe you are confusing with SML, because everything in ocaml is curried by default. Though admittedly the standard library could be more complete, but I personally am happy to use third party dependencies for less common things.
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.
What are your thoughts on this comparison? github.com/âŚ/007-My-Thoughts-on-OCaml-vs-Haskell-âŚ
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.
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!
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).
Rust.
Julia
I wouldnât consider Julia statically-typed; am I wrong?
Itâs actually optionally-typed. But if youâre liberal with type annotations you can treat it as statically typed.
Rust and Haskell (I think Haskell counts)
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.
The question mine as well be âwhat is your favorite compiled language?â. There is a lot of overlap between the possible answers.
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.
How are they not memory safe in a multi-threadded context?
Thereâs nothing to prevent data races. I myself have fallen into the trap of using the same list from multiple threads.
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.
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.
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.
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.
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.
Even though they are not what people mean when they say âmemory-safeâ, it is technically a kind of memory safety. It is unsafe to modify non-mutexed/non-atomic memory that another thread might be modifying at the same time.
C# has native compilation capability, thanks to Native AOT
learn.microsoft.com/en-us/dotnet/âŚ/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âŚ
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.
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.
Swift fits the description too
Most people would consider it so, but it actually does not either fulfill the argument I posed there: forums.swift.org/t/âŚ/31987
Swift does have data race safety as of Swift 6 with their actor-based concurrency model and are introducing noncopyable types/a more sophisticated ownership model over the next few releases
Hmm, that sounds quite interesting. But because Iâve had to rebut that for everyone else that responded: Is it opt-in?
I guess, I would be fine with opt-in for the actor pattern, since you either do actors in your whole codebase or you donât, but otherwise, opt-in often defeats the point of safety measuresâŚ
Itâs opt-in in Swift 5 mode and opt-out in Swift 6 mode, the Swift 6 compiler supports both modes though and lets you migrate a codebase on a module-by-module basis.
Agree that opt-in sort of defeats the point, but in practice itâs a sort of unavoidable compromise (and similar to unsafe Rust there will always be escape hatches)
Yeah, I like subleq.
tinyccints. Since itâs all of them, you donât even need to write it!Subleq is the obvious winner in my mind.
Rust
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:
youtu.be/zHzpoVgqgc4
Scala 3 native. If the compiler was faster Iâd be even happier. Curious to try Ada
Python
They specified statically typed languages. Python would be dynamically typed
Python is dynamically typed by default, but lots of Python is statically typed.
No python is statically typed. You have type hints, which makes the language tolerable but like their name implies itâs a hint at the type. You can perfectly legally pass in something completely different that doesnât conform whatsoever.
The primary thing static languages provide is static typing, that being the ability to determine before runtime that all the types are valid. A good example of this is how C++ programs will refuse to compile if you try to invoke a method that doesnât exist on the type. Thatâs because itâs statically typed. At compile time you know that the code is wrong. Dynamic languages fundamentally donât work like that. You cannot know until runtime if the method you called or the field you are trying to touch exists or not. Again type hints help a lot with this but that doesnât change how the language actually operates.
All static typing means is that types donât change, eg you canât declare a var as a string and later assign a number to it.
No.
Name one statically typed language that doesnât have that property. Name one non statically typed language that has that property.
Itâs much more involved than that. For example, static type systems involve checking that the functions you call accept the types of parameters youâre supplying then. Itâs a necessary part of static typing but alone is not sufficient.
If this code were a valid program in some hypothetical language but only failed at runtime then that would be an example of dynamic typing because the types cannot be verified statically (e.g., at compile time).
But youâre right, I donât really know of any languages like that. I couldâve sworn I heard this called strong typing but I canât easily find a source. And strong/weak typing are a mess of definitions nobody agrees on.
.
C# is good too. If you havent heard of lobster you should look into it.
C# isnât exactly compiled, at least not into machine language. It is transpiled into byte code that is run on a virtual machine that on turn is an interpreter/JIT-compiler.
Depending on why someone is asking for a compiled language that may or may not be a problem, because to the one writing the code it looks like a compiled language, but to the one running it it looks like an interpreted one.
It is compiled into bytecode. A transpiler translates to another programming language with the same level of abstraction. A compiler translates into a level that is nearer to or machine code.
Not necessarily these days! With NativeAOT, C# can be compiled to machine code.
It is compiled to bye code. Just to be clear transpiling is completely different. It is also not interpreted.
But ahead of time compilation is available now. So you can compile straight machine code.
The newer tiered JIT can actually give better performance than a traditional compiler as well.
Overall C# is an awesome language. If performance is absolutely critical you can use raw pointers and manual memory management, but obviously you lose safety then.
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::optionalcould 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.
I recently got bitten by exactly that
std::optionalUB and here I was thinking đ¤ after 12+ years in the industry starting all the way back in the day with C++03 that modern C++ was supposed to make things better.đ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â.
D
C on Morello (or any other capability machine).
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.
Nim
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
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: www.youtube.com/watch?v=5_oqWE9otaE&t=3970s
Thinking about zig for some stuff.
Mostly because those rusticles are pissing me off.
I donât know what you are talking about?
Rust is such an amazing language, itâs so safe and clean and beautiful and simple and clear to read and such wow community that are making amazing crates for cargo because cargo is so cool I like it so much so easy toâŚ
Oh, and your fav lang sux alot!1 lolololllll
âHey Linus, why havenât you rewritten the kernel in rust yet, you idiot?!?! Donât you realize youâre missing the future, old man!?!?â
<img alt="" src="https://lemmy.world/pictrs/image/f2a78334-2053-4d59-96a5-a9a1f2ada2aa.gif">
Whatâs so bad about the Rust compiler? I know itâs slow, but given all the analysis itâs doing, it makes sense. And, from my own experience, setting correct optimization levels for dependencies along with a good linker makes incremental builds plenty fast.
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
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.
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 :)
purescript if you count âcompile to jsâ as compiled.
Otherwise Haskell
Thatâs transpiling, not compiling. Compiling is usually meant as âdirectly to machine codeâ, but I am yet to find an âofficial definitionâ.
There is no official definition, in part because there isnât any formal way to define the term that satisfies our intuition.
Most treatments will handle âtranspilingâ as a special case of âcompilingâ and some will even handle decompilation as a special case where the object language is higher level than the source. Of course, even defining âhigher levelâ can be quite hard.
Plenty of languages âcompile to Câ and I see no issue with saying something âcompiles to js,â especially given that js mostly lacks features of purescript rather than the other way around.
transpiling is just a type of compiling. compiling in no terms means âdirectly to machine codeâ.
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.
Kotlin is nice
People donât understand that JIT languages are still compiled, JIT literally describes when itâs compiled.
That said, F# and/or OCaml.