Could you post more about your experience please Adam - I for one would be very curious in how you get on 
1 Like
@OvermindDL1 What are OCaml’s PPX thingies? Like the Lisp DSLs you can write by using metaprogramming, or are they something that converts OCaml to something else (so the other way around)?
2 Likes
@dimitarvp OCaml’s compiler is ‘pluggable’, in short:
- PP - Preprocessor, like this is what ReasonML is, it just takes input source, converts it to OCaml, then feeds it to the rest of the compiler. OCaml has a surprising number of PP’s.
- PPX - These plug ‘in’ to some or multiple of the middle stages of the compiler. They work on the AST of that stage of the compiler (which does mean you have to update on new compiler versions, however there’s a library that abstracts that out so you work transparently on basically all versions of whatever minimum feature set you want). Depending on the stage(s) you hook in to the AST have varying levels of information, like higher stages are typed and contains attributes that you can work on, lower stages tend to be less (or none in the case of right before sending to the backend, it’s all integers at that level, basically assembly in AST form) typed but you can put in interesting optimization things then.
- Backend - This is what consumes ‘some’ of the above-mentioned stages to output a final object. The mainline OCaml compiler comes with two, a super easy to debug bytecode compiler that is run via the OCaml bytecode interpreter, and a native code compiler that outputs native code with nothing else needed (fastest optimizing compiler out!), both of those consume the last AST stage.
json_of_ocamlis another backend that consumes the last AST stage and output very machiney-looking unreadable but fast javascript. Bucklescript or whatever it’s called now hooks a more middle AST level to generate javascript that looks like the source OCaml but type safe (thus it relies on the javascript JIT a whole lot more, but that works well anyway). And there are others, like there is an OCaml backend that hooks somewhere in the middle to output BEAM/Erlang code!
Rust’s proc-macro’s are like OCaml’s PPX’s (except less powerful as they hook the very very early tokenstream instead of multiple possible AST tiers).
EDIT: But there are a lot of PPX’s in existence that add all kinds of really cool and interesting features (like proc-macro’s for Rust), everything from erlang-style bitstream handling to elixir-like compile-time source macro’s to rust-serde-like serialization/deserialization engines and more, it’s really cool.
3 Likes
I like it too! With Erlang I feel good.
Am I tired of endless additions to Java, there are even claims to Rust - in my opinion, if there were fewer language constructions there, it would be better for the language.
3 Likes
I agree Rust can be verbose and it definitely gives me PTSD flashbacks to Java sometimes – but the compiler and all dev tooling are the best I’ve ever seen in my life and that alone makes developing in the rather clunky syntax and puzzling mechanics like partial moves, circular borrowing and polymorphic trait return values much more tolerable.
I miss working with Rust every day. I love Elixir to tears but its dev tooling is sadly very behind. But then again, almost every language out there is very behind Rust’s dev tooling.
3 Likes
I think things like async were rushed a little bit, but overall the vast majority of features in the language are rather necessary. The few that aren’t necessary, such as ?, have such an overwhelmingly nice usability thing that it’s worth having them, however I don’t actually think that’s the case for ? as Rust has an RFC to get postfix macro’s in, which would have made it so ? could just have just been a postfix macro instead of a language construct.
However, Rust’s syntax can change, unlike almost every other language, on it’s every-3-year version scheme. Since you can link mismatched syntax files without issue it allows for a very easy upgrade path as the language may add, or indeed even remove, syntax features. 
2 Likes
Sadly their 2021 edition seems extremely underwhelming. Zero risks, zero tries to reduce verbosiveness, zero tries to bring other constructs natively. 
2 Likes
Yeah I had the same thought… Maybe just a pandemic lull is what I’m hoping.
EDIT: Then again maybe it means the syntax is pretty ‘finished’ too? Which is a good target.
1 Like
If it’s finished then ouch. Rust’s syntax leaves a lot to be desired. I mean OK, once you figure it out it does make sense – I mean stuff like the where T: Trait1+Trait2+Trait3 and the lifetime annotations – but it’s still a fairly high barrier to entry.
Sigh. I guess when I put my life in order (pretty soon now, I hope; it has been a tough battle for 1-2 years but things are finally falling in place lately) and have some free time and here and there I’ll just start learning both Rust and OCaml intensely because I definitely like OCaml’s syntax more. I want to get to a strong mid level with them (I am not keen on getting to the advanced levels yet though).
3 Likes
… that stuff was always clear to me… ^.^;
But then again I know haskell and a good bit of idris, and this looks tame in comparison, lol.
But still, it’s very succinct and gives a lot of information for what is typed, it would be hard to do it better.
Like in OCaml, the equivalent to Rust impl traits would be OCaml’s higher typed modules, which are a whooooole lot more verbose in comparison, to a huge degree at times. Rust is actually very clear and simple here, it learned a lot from the predecessor languages.
3 Likes
The 2018 edition was very demanding on the developers and led to a lot of burnout. They’ve tried to reduce the likelihood of that happening again.
2 Likes
OK, Kotlin Multiplatform is obviously cool, but I think you asked about “the ‘coolest’”. So I think the ‘coolest’ language and tech are Erlang and BEAM, even right now.
Looks like @AstonJ already mentioned Erlang/OTP. And I agree that Erlang was so ahead of its time.
3 Likes
I can completely relate with wanting to reduce burnout but IMO they shouldn’t have announced the Rust 2021 edition at all. I believe there are venues where new syntax can really make an impact and they should have just postponed them for a near-future edition (2022, 2023 etc.)
The 2021 one looks like a very half-hearted effort, sort of like “Fine, we are obliged to make the damn edition, here, get something that anyone would hardly notice”.
Again, they should have just said “Rust will not have a 2021 edition. We will entertain the idea again in 2022”.
4 Likes
While I agree with everyone that Rust is really cool (I love it too), I think Go is on the upswing again.
But what do I know, I like LISPs too.
2 Likes
Meaning what in this case? Popularity? New language features?
2 Likes
I’d classify it as hype I guess. And partly in “real” popularity. At least in the circles I’m associated with.
2 Likes
I think it’s very likely that we’ll see Go as popular as Python one day - it can be argued that Python became as popular as it did because Google said they used it (it was certainly one of its biggest plus points when I was weighing it up against Ruby).
We just need to start a thread placing bets on when that might be 
3 Likes
Go is basically improved Python anyway. It’s super logical for it to be popular in those circles.
I’ll admit that Go is a bit easier and quicker to start a project with. But to me, the guarantees that Rust gives you absolutely outweigh some of the pains you have to endure to develop in Rust.
4 Likes
Perhaps one of the reasons that things look like that is most changes to the language and its libraries can occur without needing a new edition. Moreover, Rust is a stable platform and expect the rate of change to slow down.
Lastly, to reiterate the point about burnout, here is a quote from the Rust 2021 announcement in May:
However, note that Rust is a project run by volunteers. We prioritize the personal well-being of everyone working on Rust over any deadlines and expectations we might have set. This could mean delaying the edition a version if necessary, or dropping a feature that turns out to be too difficult or stressful to finish in time.
5 Likes
I don’t disagree and I even said this much in my comments. I’m not entitled to any of the fantastic Rust team’s free labor fruits.
All I was saying is that they could have just refused to have a Rust 2021 edition. They didn’t have to make it because it brings almost nothing to the table. It simply left me scratching my head wondering why was it even done.
Bold statement, improvements can always come along and be integrated. 
IMO Rust could stand to be a bit less verbosive and introduce a few more shortcuts like the ? operator.
But I’ll also immediately admit that, for the extremely complex things Rust can do, its syntax is just fine and also superior to many other languages.
Finally, I too see Rust’s language stabilization and completeness as a very good thing.
4 Likes