What does elixirists think about other programming languages?
- 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.
Iād love to see Crystal do well for cpu intensive tasks - I love their tagline, āFast as C, slick as Rubyā
Did not know you could use Swift for Android apps, which makes it more appealing now:
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
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.
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.
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.
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.
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.
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.
2:1 for static typed functional languages
Elm for front end!
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 ā¦
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.