What other languages interest you?

What does elixirists think about other programming languages?

2 Likes
  • Swift : better than objective C but still miles away from something i would want, OCaml works better for that (or Rustā€¦)
  • Go : No. Big big Nope here
  • Julia : Good for scientific computations. They need more contributors and a couple other years to clean their deep warts and the community is a mixed bag. But i am cheering for it so we can clean some Fortran out.
  • Crystal : not bad at all, but a bit of a strange fellow. Crystal also decided to go for CSP model of memory and communication so they get some malus point. We will see.
1 Like

Iā€™d love to see Crystal do well for cpu intensive tasks - I love their tagline, ā€œFast as C, slick as Rubyā€ :003:

Did not know you could use Swift for Android apps, which makes it more appealing now:

3 Likes

I donā€™t think Smalltalk is dead, the commercial implementatons are simply priced out of reach. It is that valuable for companies which sell as such prices to be still in business because the companies that use it know how effective it really is.

Smalltalkā€™s problem is not having BDFL to ensure all implementations are identical. This is the advantage the languages like python, ruby, and java have, but how many effective live coding environments have been built around them?

Pharo and Squeak seem to be going strong. If Gilad Bracha and al were not bought out the likes of Sun and Google to go and develop Java who knows what the SmallTalk world would be like to do. I really see these things as a corporate philosophy of keeping truly powerful tools out of developers hands. Having developers stick their nose to their grindstone wheel using primitive tools keeps them from having the proper birds-eye view of their projects, which is reserved for managers, not to mention that the programmers managers have working for them the more important they are and the bigger their budgets.

I think languages like Smalltalk are more likely to be used by in house or departmental teams who need to get stuff up and running quickly and reliably

Loper OS Ā» Where Lisp Fails: at Turning People into Fungible Cogs., http://www.flownet.com/gat/jpl-lisp.html

Yes and no. SmallTalk has some pretty big problem, and it moving to ā€œclass basedā€ language made it even worse. Do not see evil everywhere. SmallTalk was not solving the problems company had and it is still not solving them. It is working kinda ok for some things mind you.

I am more interested in language paradigms than the languages themselves, so languages which combine having a good grasp of the paradigm and are good in area I have practical work to do are those I prefer.

This means:

Elixir - functional paradigm, web programming, concurrency an added bonus. I see it as alternative to learning Lisp or Scheme.

Nim - python like, lisp like, metaprogramming, many potential platforms as it compiles to C. Games developers seem to like it a lot

[C] (https://en.wikipedia.org/wiki/C_(programming_language) - canā€™t do without it. Needed for interfacing with external libraries at the very least, helps grasp low level computer details

Rust - for efficiency, safety

Javascript for web pages. Do I have a choice?

Lua - embedding in other larger compiled programs

OCaml functional programming. If @OvermindDL1 says it will be very good to learn it, then I should :grin:

No languages can be perfectly conceived first time around, it would have evolved if more attention was paid to it. When you consider that IBMā€™s early Java IDEā€™s were based on Visual Age Smalltalk, it becomes quite clear that for some reason BigCo did not want Smalltalk or something similar to it wind up in developers and end users hands.

It had to be the web and its primitive tools and environment, which after 20 years still lags behind what was available 20 years ago. They only thing it has brought to the fore is the need for good concurrency, but it seams Erlang and BEAM had that right years go.

I mean after all the development and contributions all these big companies have made to open source why havenā€™t they been able to contribute to something as basic as a good graphics interface to GDB?

Their offerings are not good enough to do stuff really well, but not bad enough for a commercially profitable alternatives to be developed for them.

Lua is definitely interesting. It is a small, compact language where they have resisted adding many new ā€œfeaturesā€. It also has the benefit that you can run it natively on Erlang/Elixir using Luerl which is implemented in Erlang. :grinning:

6 Likes

Which part of elixir-lang covers the interaction between Elixir and Erlang libraries? Is it as transparent as adding a use erlangmodulename

even easier. To use any erlang lib, you just call the function with the name of the module as an atom in front of it. So for http://erlang.org/doc/man/crypto.html#strong_rand_bytes-1 as an example, you would just do :crypto.strong_rand_bytes(your_integer_here) . And you would be good.

1 Like

Iā€™m quite with @vonH for most of that too:

(Not duplicating links that are already placed)

The EVM/BEAM is awesome, Elixir macroā€™s on that are outstanding, lfe might be better but not as large of an ecosystem.

NIM is fascinating, Iā€™m keeping my eye on it but barely been reading over its manual so far.

Iā€™d choose C over C++, you can still program C in C++ except C++ can have a lot more fully efficient and safe safety harnesses that C does not have and cannot have, plus with templates you can be far more expressive as well while retaining that safety.

Rust is fascinating, still not a top choice due to its macro systems being young, but it could easily replace C++ for me over time.

D Is basically a better C++, compiles almost as fast, optional but not enforced GC, sadly the standard library had 2 conflicting implementations for a while, and the one that came out on top still has a lot of enforced GC in it that is slowly being removed, once that is done though then it could also replace C++ in many ways, but Rust I think might be better overall if you need its safety, and Rusts safety is fantastic.

Javascript just because it is ubiquitous now, however Iā€™d not program on it if I can get away with it, which I can.

TypeScript - If you must absolutely use Javascript, then use it as typescript, it compiles javascript too but you can type it over time so you can get it at least reasonably useful without being a death-trap.

Bucklescript - This is an OCaml Compiler back-end that compiles to very readable and optimized javascript. Basically you can program Javascript with the full power of Javascript but in OCaml or any language that compiles to OCaml (like F* or ReasonML or whatever), it is fantastic, it is my go-to to-javascript ā€˜languageā€™ (via OCaml).

Lua is ubiquitous, but makes a fantastic embedding language.

Terra is LUA backed by LLVM, the LUA itself is LuaJit and is not LLVM accelerated, but Terra adds optional typing to Lua and static typing to a new terra function definition (you use terra instead of function) and ā€˜thoseā€™ are compiled with the full power and optimizations of LLVM, and not just that, you can dynamically generate those using Lua, and even more so, this can be done at program run-time, for a super-fast embedded lua-like language that runs circles around even luajit, or you can even output the final LLVM binary as a library (normal windows dll or linux/mac so file or so) that you can link to at runtime to access the pre-compiled, optimized calls, it is fantastic and is what Iā€™ve been using instead of Lua for my recent projects.

Haxe - An ā€˜actionscriptā€™ inspired language that has long since diverged from its heritage to become an actually good language, it is OOP sadly but it has a strong macro system and more importantly it can compile to almost anything. By default it compiles to everything from javascript to C++ to java to android to iOS to RPi to a dozen other things, and making more back-ends is actually very easy for it. It has a great FFI system and there are libraries to handle about everything transparently to any of the back-ends, consequently it is a very popular language for games, youā€™d be surprised just how many games are made in Haxe, as I recall it is the most used indie-game language.

And of course OCaml, even if you do not use it (but with Bucklescript you really should) it is a fantastic language for helping meld your brain to understanding types in a wonderfully clean and succinct way, better than any other language in my opinion for that. Plus OCaml compiles to very fast native code near that of optimized C++ but safe and certain. :slight_smile:

4 Likes

Iā€™m enjoying Elixir the most out of the languages I am interested in. I am 100% Scala at work, and Elixir for fun side hacking.

1 Like

I was learning Ruby (and subsequently Rails) before I moved to Elixir and Phoenix after seeing the announcement of Phoenix v1.0 on HN a few years ago. Because of this change, I would like to dive into Erlang at some point. The functional paradigm has also peaked my interest in Rust and Haskell, but I donā€™t have a solid reason to learn those aside from my curiosity. Aside from those two, I would like to explore TypeScript, Go, and C++ more.

Mine lies in F#, Clojure and Haskell.

1 Like

Even more transparent. You call an elixir module with ElixirModule.func and an erlang module with :erlangmodule.func and thatā€™s about it.

Just an extra comment about running Lua is that other ways of doing it are to use ports to interface an OS process running Lua, or to use NIFs to call Lua directly in the VM. The 3 different ways all have their own pros and cons.

3 Likes

Why Go nope? :slight_smile: ā†’ most cloud stack tools are written in Go

https://www.cncf.io/

2:1 for static typed functional languages :thumbsup:

Elm for front end!

1 Like

Is this programming language proliferation really good for the professional developer community?

I can understand it from an academic point of view, but for the working dev who just needs to build and manage good reliable softwareā€¦

Is this whole language proliferation not really a distraction?

Thank God for Elixir by the way ā€¦ :wink:

Most of the churn in programming languages can be placed at the door of these 3 languages:
C++, Java and Javascript. Every other language development has revolved around problems caused by this unholy trinity. These languages coupled awkward, rapidly changing and broken APIs and libraries for mobile platforms are the real source of this problem, and simple bloody-mindedness from the Big 3.

Most of the initiatives promoted by the Big 3 come to absolutely nothing in the end. They have been promising panaceas for all coding ills and things havenā€™t changed a whit.

For an older generation most of the reasons are clear. Churn has come to the programming environment and it came with the onset of the web.

1 Like