Hey, #java software devs: how do you prevent the #jvm from dumping memory into the application folder if the application or system causes it to malfunction? I still want the memory dump, just somewhere else. Can that be done? Please show me the way!
One of the biggest advantages of #Java has always been the #JVM (which allows for absurd portability and also facilitates the configuration and scalability of #software#developed in Java).
In #C, until now, I wasn't aware of any interesting tool that could take on that role. But look at the surprise:
Congrats to the #Python folks for merging the first patches to disable / remove the GIL.
An excellent reminder that making deep-level changes of mature programming environments takes time, patience and a lot of very diligent work by smart and conscientious people.
In this case, I think it's taken just under 20 years. A fact I'll keep in my back pocket for the next time anyone wants to complain about how long major changes take in #Java and the #JVM
I'm always learning new and old programming languages because I find new concepts and development approaches for myself.
At the moment I am actively working with WebAssembly and virtual machines for its execution. Specifically, I have to work with text representation - WAT.
This is a very interesting experience of working with a stack machine using S-expressions.
I also have a feeling that WASM using WASI can be a good alternative to JVM and other similar virtual machines.
Pro: ora ho il #software che mi permette di fare quello che mi serviva, per cui non avevo trovato altre soluzioni già fatte che fossero funzionanti. In realtà, l’idea iniziale era di fare una #app specifica per questa #dimostrazione, ma strada facendo ho deciso che avrei reso questa più semplice e generica, potenzialmente utilizzabile anche per altri usi, e avrei implementato parte della mia logica sul mio #server con qualcosa di più rapido. Quello che è uscito fuori ora è una piccolissima app che esegue codice #JavaScript fornito dall’utente e permette a questo di interfacciarsi con API native. 3 API al momento, lmao. Non so se nel tempo la espanderò o no, ora mi serviva appena questa poca roba, e la #UX è #grezza grezza perché non ho tempo. Il codice è quì (ma non è bello): https://gitlab.com/octtspacc/DroidScriptin. ☕️
Contro: la programmazione Android in sé, che è sempre un leggero incubo. Tuttavia, l’unica alternativa teoricamente (chissà praticamente!) viabile sarebbe stata fare un’app per Symbian o J2ME, che certamente non avrebbe semplificato le cose. Vabbé, anche per questo ho alla fine realizzato questa parte del mio progetto demo nel modo in cui ho detto. La cosa più strana attuale del codice? (Content Warning: 🤓️) Il fatto che io debba tenere una classe dedicata funzionalmente vuota per dichiarare l’uso di un BroadcastReceiver all’OS, anche se io nella pratica quello lo uso nella MainActivity, e non nella classe che specifico nel manifest per quel permesso (perché non riesco a mettere MainActivity lì). Ah, però questo per quanto non abbia senso, funziona. La cosa veramente più strana, invece, lo è perché non funziona: su #Android4.4 (mio target) la UI è a posto, mentre su #Android13 (che monta il mio #smartphone principale) manca la barra dell’activity, e quindi non c’è manco modo di accedere al menu… vabbè, il #programma deve funzionare sul #telefono#vecchio, e lì appunto va. 🎈️
Il bug che ho descritto sopra, a confronto screenshot del mio telefono con quello dell'emulatore Android 4.4.(Ma come farà ad accadere questo #bug? 😩️)Nel mezzo: ne ho approfittato per provare #Kotlin un pochino, che avevo sempre snobbato, e adesso me ne pento… di non avergli dato una chance prima. È molto più piacevole di #Java da usare, secondo me, sintassi estremamente più pulita e concisa. Kotlin compila in #bytecode#dalvik e in generale targetta la #JVM direttamente, quindi le #API sono quasi identiche a Java, e avendo usato quello non bisogna imparare quasi nulla di nuovo; sintassi a parte appunto, che però si impara semplicemente scrivendo, è esotica ma assolutamente non esoterica. 🧶️
E giustamente vi chiedete, a che mi serviva esattamente? Se rientra nell’essere un sano #WeekendProject come ho programmato ieri, allora domani lo saprete… per ora non faccio spoiler, oltre a dire che il mio #MicroBlog potrebbe ottenere una funzione che solo #Twitter aveva e solo nei primissimi anni, e ora è un concetto estinto. Non vi dico che leggendo il #SourceCode potete intuire, ma mai dire mai… 👁️
「 The Wasm VM is small, so it is relatively easy to implement, and thus, it is also easy to port to many platforms. An unmodified Wasm VM is able to run in a browser as well as outside a browser. And, if you remember, this is the thing I am personally more excited about 」
Hey all you #Kotlin (and #JVM) experts. Is there a a makro I can use to raise a compile-time warning which is then shown in #AndroidStudio / #IntelliJIDEA ?
JetBrains introduces Amper. An experimental project description language for #Kotlin Multiplatform. The underlying system using the notation is still #Gradle.
Happy to see such developments. The #Java / #JVM build system is Gradle's killer application. But in its core it's a powerful framework to create build systems on top of.
The huge feature set of vanilla Gradle is probably it's biggest weakness when used directly by end users. Excited to see where this goes.
Various thoughts on too many programming languages, for no discernible reason.
I have been interested in Go since it's very initial release, but their dependence on Google is uncharming to say the least. I still haven't made up my mind on its GC, but its definitely better than most.
I used to do some ML work in .NET and if it wasn't dependent on Microsoft it would be a heavy contender for a great language, but it has far too many Microsoft-isms to ever really go much farther.
Rust is great, I enjoy beating my head against a brick wall battling with the compiler, and their safety is great, but overly complicated and feature-creep is a real problem on that entire project. I do a lot of work these days in Rust, for better (mostly) or worse (mostly-ish).
C is my bread-and-butter, as is Javascript for quick prototyping.
Elixir is great, but Erlang is unwieldy, the community is growing, but not fast enough - and I just can't get my mind to enjoy the syntax no matter how nice it is.
D is a lot of fun, but their GC can be slow at times, and the community is very small and packages are often broken and unmaintained.
Python was my first true love, but I really can't stand the whitespace, again love the language, hate the syntax.
Zig is fun, but just that. Fast, nimble, but early days, a bit confusing, could replace my insistence on C for core projects, but again, early days. I love to use them as a compiler for C, much faster than the defaults on any of the others.
Odin is one I love to keep an eye on, I wish I could get behind using it for more things. When I first took notice ~4 years ago the documentation was a bit scattered, but it looks much better now. The developer behind it is incredibly cool, could be seen as the next Dennis Ritchie imo. Runes are dope. The syntax is by far my favourite.
Julia, I love Julia, but performance last I tested was a bit of a miss, and by miss, it required a decent chunk of compute for basics, but when you gave it the system to throttle, it would be insanely productive to write in. Javascript is something that I prototype even syscalls in, but Julia is just the same but much better and more productive (and less strange) in many regards. I am really hoping this takes over in the ML/Data world and just eats Python alive. I've heard there has been major work in the perf department, but I haven't had reason to try it out lately.
Ada, memory safety before Rust! Great language, especially for critical applications, decades of baggage (or wisdom), slow moving language, insanely stable, compilers are all mostly proprietary, job market is small, but well paid, great for robotics, defense, and space industry types, but the syntax is... rough. Someone should make a meta-language on top of Ada like Zig/Nim/Odin do for C, or Elixir does for Erlang.
The others: Carbon, haven't tried; Nim, prefer when they were "Nimrod" (cue Green Day), decent but not my style; Crystal, seems cool, but not for me; Scala, great FP language, but JVM; Haskell, I'm not a mathematician, but my mathematician friends love it. I see why, but not my thing as much as I love functional languages. I'll try it again, eventually. I did not learn Haskell a great good.
I tend to jump from language to language, trying everything out, it's fun and a total timesuck.
Since writing this I've started looking more into Lisp, and I am starting to understand why everyone things its "gods chosen language". it's great, and you can turn/embed any language into a lisp. That's cool.
I like both Ada and C, but I work in the robotics industry, so we have to constantly switch between the two for anything hardware based. They both have their benefits, C is my preferred because of how simple (it can be, if you try...), but Ada (Primarily SPARK is what I've done work in) is great, but dated in many regards. I don't know if I've ever looked into Austral, but I'll take a look!
Haskell, tried it many times, never a good time. Ocaml isn't bad, but again, not my thing or style but definitely something I inherently understand more.
Scala, JVM, my sworn enemy. Never again. They can't get me suckered into reading Java docs again.
Elixir, great language, but I am going to agree with you - I am starting to prefer working with Erlang directly, but its early days on that. I've started looking into @lfe which looks incredible.
Nim, I dislike whitespace reqs in languages, I tend to value customization of my styles to make it all make sense to me, so Nim is too controlling for me in that regard. I read code a lot more than write it.
No real opinion on C2-3, love D, V looks interesting but not sure yet, Jai - if it ever comes out, haven't heard of Scopes, and I already mentioned Carbon.
If someone could find a way to package Rusts memory management in a tenable way to be cross-language, we would have a massive explosion of greatness. I know it's possible, but nearly impossible without some wicked genius' at the helm.
With #Java's evolution (discriminated unions, pattern matching, virtual threads), are #Scala / #Kotlin still worth it?
Scala & Kotlin have a culture of doing things at compile-time, the former more so than the latter.
This yields safety & expressiveness, and is reflected in features that Java will never implement, in platforms that it will never target well, or in paradigms it will never embrace.
Java is still Java, and you're stuck with Spring, Hibernate, and Jackson, sorry.
@alexelcu I'm enjoying Kotlin, but I have to venture into Java just as often, and I can say I still appreciate developments there. I once heard Brian Goetz explain InvokeDynamic in the JVM at a DevOxx congress, which was instrumental for Lambda expressions, and I was impressed with how they make these feature puzzles, with Java acting as a custodian of compatibility.