Main: http://nim-lang.org
NES emulator (compiled to JavaScript, runs in the browser): https://hookrace.net/nimes/
Simple 2D game: https://hookrace.net/blog/writing-a-2d-platform-game-in-nim-...
More examples: https://nim-by-example.github.io/
Nim has pythonesque syntax, with Pascal/Delphi roots, fast compile times, portability (compiles down to C, JavaScript, LLVM), strong metaprogramming support, seamless FFI, optional GC, and a lot more.
It doesn't have Rust's ultimate safety, although it has quite a bit -- e.g., it can track which thread accesses what for concurrency (in a limited but extremely useful way).
I'm a fan; It looks like the fun of Python but the speed of C/C++. I haven't had a chance to start a project in Nim - hopefully, in 2017.
1 - https://manning.com/books/nim-in-action?a_aid=niminaction&a_...
Some Nim screencasts would be awesome. I would love to make some myself, if only I had the time...
Somehow language designers seem to cling to old syntaxes.
I mean s-expressions have their beauty. But C or VB like syntaxes always feel clunky to me.
Though I guess ML syntax is a tiny bit less ancient than either s-expression or Algol syntax, which seems to be what you are complaining about.
But after doing a search, it seems you're right. Languages with ML-family syntax weren't very popular the last 20 years. Most languages look like C or Algol these days.
I only knew that I didn't like most trailing delimitters and I knew only a few languages that didn't have them.
* For many third-party libraries, needing to write `import * as Something from 'some-package'` instead of `import Something from 'some-package`.
* Not being able to import non-TypeScript files, further fragmenting my import style by needing to write stuff like `const styles = require('./something.scss')`.
* Module resolution in general seems to be close enough to ES6 that I'm usually okay, but different enough that I sometimes get really confused about why something doesn't work.
* There are tons of incorrect type definitions in the DefinitelyTyped repository. A common thing for me to do is: 1) `npm install --save-dev @types/some-package` 2) notice that my app no longer compiles because a method supposedly doesn't exist 3) `npm uninstall --save-dev @types/some-package` 4) move on with my life, because the method does indeed exist and my code works. Once I have more experience, I'd like to contribute to the repo to fix these errors, but the repository itself is GINORMOUS. 1k+ issues, 3k+ contributors, 25k+ commits, and 87 open pull requests right now. I have to think that there's a better way to manage types of third-party libraries.
* I find the docs very difficult to read.
If someone has a good resource for learning TypeScript, I'd love to know about it! Specifically, my pain points are module resolution (as you can see) and types beyond the basics. For example, I recently tried to make a React component where the props could be some custom things I wanted, PLUS all the fields of HTMLAnchorElement. I tried, but couldn't figure it out, and eventually switched the props type to `any`. This is less than ideal :(
For non-js imports, you can create global module declarations (like the below snippet):
declare module "*.css" { const value: any; export { value }; export default value; }
But you will still need to use some bundler tool like webpack. It will just stop TypeScript from complaining.
Type definitions are the biggest issue even today, but things are much better now. Most popular npm packages already have type definitions, but if you need some exotic package, then you can write your own defnitions (probably only necessary bits).
I think this depends on the lib. As far as I know if a lib doesn't have a default export Babel is simply "emulating" one and TypeScript explicitly requires you to "export everything"
> Not being able to import non-TypeScript files, further fragmenting my import style by needing to write stuff like `const styles = require('./something.scss')`.
Yes this is a bit awkward, but I think it's bit cleaner than the stuff Babel etc. do.
> There are tons of incorrect type definitions in the DefinitelyTyped repository.
So true. I'm often forced to use require() to get around this. What helped me (but isn't for everyone) is choosing libs that are written in TypeScript in the first place like RxJS, Xstream, Cycle.js, Apollo-Client.
Next time I'll go with Flow. Generally the only thing I REALLY need to be typed are the domain-specific models, and so I'd rather be as close to idiomatic JS/babel as possible.
Typescript developers are encouraged to package a Typescript definition file inside of their repository if possible. Typescript is smart enough to pick it up automatically.
https://www.typescriptlang.org/docs/handbook/declaration-fil...
The reason why I believe Kotlin is a great way ahead is - Great java interop, removes a huge amount of boilerplate, results in very readable code and extremely easy to learn (one of the reasons we could not switch to Scala was the steep learning curve which would be a big problem for new developers joining us).
I think this is overblown. Yes, the language has a deep learning curve, but you're really trading off language complexity for lack of framework complexity. Because the language is so powerful, you'll see a lot less 'magic' frameworks (no need for a DI framework, no need for AOP, etc) so applications tend to have a really low barrier of entry to work with. We hire new developers all the time and they are productive way before they master the language.
NoRedInk (among other companies) use non-mainstream FP languages and hire juniors all the time. Turns out that people can learn things quickly if they're smart (which is why you hired them, I hope) and are given mentorship.
i am really excited about how the language is evolving. its becoming silly to use anything else on Android now.
on the server Spring 5 is building official support for kotlin as is vert.x. Reactor is integrated closely with kotlin... and the developers are putting in a lot of effort around scripting.
Elixir - This one is a maybe for me. I've wanted to get more into functional programming, but also not sure if I want to explore the Erlang stack since I've been burned by it at work.
* Rust, for it's a sane replacement for C and C++.
* Elixir, for it's more consistent than Erlang, running on the same battle-tested VM.
* Clojure, because any JS code I write now gets transpiled anyway, so why not use a nicer language with a nice standard library?
* Crystal, because it might be a faster and safer Python replacement.
Have you considered Nim? I think you might find that it is a more natural Python replacement :)
Elixir is a subset (nay, it's a language within it's own right language now, the method chaining syntax is very readable) of Ruby running on the BEAM vm from Erlang.. not Erlang itself
Crystal is a native compilation of Ruby (or a subset at least), not Python btw.
But Erlang does have a few warts, both in the language syntax and in the standard library, and these warts are never going to go away, because backwards compatibility. (Erlang cannot hope to pull a Python 3 with any success.)
Elixir is a new development, hopefully avoiding the downsides while not losing the upsides and the general FP-esque idea, and retaining the VM-level interoperability.
Language Goals
* Have a syntax similar to Ruby (but compatibility with it is not a goal)
For instance, Crystal has macros, which Ruby does not have. Think of Crystal as being a statically typed language that was made by people who love Ruby.
However, I think Rust went overboard with the line noise; the combination of very terse keywords, and a decision to rely on punctuation more so than keywords, means that it's a very dense, gnarly language.
Rust is also notoriously slow to compile, which worries me.
---
Swift: For the above reason, I really want to explore Swift. For me, Swift has pretty much the ideal syntax. As with Rust, you have Pattern matching, abstract data types and generics, but its designers has also spent a lot of time on ergonomics, and aren't afraid of making backwards-incompatible changes (which, this early in a language's life, I think is a good thing).
But I'm worried that the ecosystem and standard libary are not there yet for general-purpose development outside the realm of iOS/macOS GUI apps.
---
Nim: It's particularly interesting in that it's managed to retain a superb level of performance with a minimal, highly expressive, highly readable, fairly unintrusive syntax that combines the best of Turbo Pascal and Python. I'm less concerned about the fact that it's garbage-collected.
I'm admittedly less enamoured about some of Nim's {.weird syntax choices.}, and there are clear signs, in Nim's suprisingly huge feature set, that it was designed by a single person who had sudden ideas, implemented them about 80% of the way, and ended up with everything but the kitchen sink, without really considering the complexity or bewildering array of semantics that were incurred along the way — so many pragmas! Nim could do with a cleanup. I'm also disappointed that classical OO inheritance was kept.
That said, Nim looks terrific, and I hope to find a project to use it with.
---
I'm also hoping that Jonathan Blow's Jai language sees a release this year, because it looks quite exciting.
I will probably write a guide about how to create a simple and maintainable API with GraphQL and Node/Express, based on my own experience in 2016.
- rust => basically, it's not new for me, I've done several small toy project with it, but I want to create bigger project with it.
- ruby => not new again, doing it only for work :((
- scala => this year will be quite interesting year for this language since its library adoption for 2.12 are still on going and who forget about dotty anyway ? Full stack development (frontend + backend) will be quite interesting
- typescript => I already try this, but still not getting anything quite done yet, sometimes it's still a bit awkward in getting some development tools working. It has some issues in getting js library working together since some js libraries weren't that friendly with typescript. (frontends)
Lovely syntax, great performance, fast compilation times. With templates and macros provides you can build just right amount of magic you need into your programs.
It desperately needs more developers to bring the language 1.0, and I'm hoping things will move faster in 2017.
- Elixir.
For near-real-time, concurrent systems, I'm tired of using the tools I know (python, js), and I'm eager to start using the battle-tested solutions (BEAM).
- C# (maybe?)
I mainly develop line-of-business applications, and python, with it's great ORM, sqlalchemy makes things so much easier. But I want more type safety, and I'm hoping C# and the ecosystem will reach maturity on linux front in 2017, so I can evaluate C# as my main language for line-of-business applications.
I like the Rust community, friendly and helpful.
I may eventually port some of the code over to Rust once I play with postgres-extension.rs [1] to see if it is even possible. Probably not all of it because I believe you can only make extensions right now with Rust and not PL (ie loaded stuff) or maybe you can?
Postgres is no longer just a database... it is a pretty powerful platform.
[1]: https://github.com/thehydroimpulse/postgres-extension.rs
Nim as mentioned by @beagle3.
Elixir, possibly. It may be a good next move for Rails shops, but I'll see if the community grows a bit.
.NET Core if we get interest from my employer's customers. Very preferably not on Windows.
Cosmology sounds exciting.
Generally speaking, and exceptions aside, astrophysicists are not programmers. They usually write bad code, but most of them are aware of this. They are sometimes able to abandon an old technology and adopt a new one, but reasons must be very compelling! (Examples: astrophysicists are slowly switching from IDL to Python, as shown by T. Robitaille during the last ADASS meeting [2].) Given the current state of things, I feel that Nim could raise a lot of curiosity in my field, but it would not be compelling enough to do the switch. Nim has a beautiful syntax, and I love its many features (macros!). But there are many things that are vital in my field and Nim lacks:
- No scientific stack. It's true it is extremely easy to create your own bindings to C libraries, but the number of libraries I routinely use are so many that the effort would be huge: FFTW, OpenMPI/MPICH, BLAS, LAPACK, GSL, and so on. Languages like Julia and Chapel have been designed for the scientific community from their grounds. Therefore, many of the routines provided by the libraries above are already available within the language itself or its standard library, in a coherent interface. Even writing all the Nim bindings to the libraries I mentioned above would provide a suboptimal experience. What would be lacking is a high-level layer which harmonizes the inconsistencies among the C libraries. A practical example: suppose you want to calculate the FFT of a nontrivial subset of the elements in an array, like array[10:320:4] (start from element 10, take 320 elements, but only one out of four). Using NumPy, is just a matter of calling fft(array[10:320:4]), but using C or Nim's bindings to FFTW requires an explicit for loop to create the temporary array to be passed to FFTW's functions.
- Both Julia and Chapel provide native constructs to ease the parallelization of the code. This is a must in cosmology, which relies on very heavy calculations ran on clusters with thousands of computing nodes. C, C++ and Fortran here have the advantage of making both MPI libraries and OpenMP constructs available at the same time (and don't talk about the many alternative libraries, like Intel's TBB [3]). Chapel is extremely strong in providing alternative (and easier) ways to express the parallelism of numerical computations. Furthermore, there are plenty of ways to further help the C++ compiler in parallelizing loops, using the "reserved" keyword and a bunch of #pragmas. The last time I checked, very little of this was available in Nim; see my post here: http://forum.nim-lang.org/t/1978/3. Apparently, nobody was able to answer my question, from which I concluded that the solution didn't exist.
- I feel Nim's installation and environment to be a bit "fragile". In the past, I had a couple of occasions to show Nim to my colleagues. Both times I failed to run the installation process from the beginning to the end without problems, as there were little inconsistencies between what the documentation says and what install scripts really do. Just a few days ago I reported a new set of problems I experienced with the two latest releases, 0.15.2 and 0.16.0: http://forum.nim-lang.org/t/2693; luckily, this time nobody was watching me :-);
- (This is probably linked to the previous point.) The lack of a clear path towards version 1.0 scares a lot of potential users, including my colleagues. I wrote a set of codes in Nim for a paper submitted to Astronomy & Computing, and that paper was almost rejected because of the reviewers' feeling that Nim was not «serious» enough. (I was able to publish it only after I rewrote everything in Python!) I hope that when you'll finish your book [1], this will help people to think differently. I cannot avoid comparing Araq's promises for version 1.0 (see e.g., http://forum.nim-lang.org/t/650/2, a forum thread which dates back to 2014) with Rust' roadmap towards version 1.0 and beyond: the Rust community has done an impressive job in delivering versions 1.1, 1.2 and so on every six weeks, as promised. This is surely due to Rust's larger user base, but I think it also shows a different attitude. (From what I understand, Araq has decided not to speak of dates regarding version 1.0 anymore, which is good; however, it would be even better to provide a date and stick with it.)
- Finally, I feel that a number of missing nice touches are hurting its adoption. The lack of decent IDE support, with refactoring and reformatting, is crucial. As I said above, astrophysicists are not programmers: often you have to incorporate ugly code, but you first need to refactor and reformat it heavily. Tools like `clang-format`, IDEs like Qt Creator and plugins for the most used editors are lifesavers! Last time I used it, Emacs' nim-mode didn't provide a confortable user's experience. Meanwhile, I have switched to Visual Studio Code, but I have not tried the Nim package [4] yet (however, I see that it still lacks many crucial features, like reformatting and debugging support.)
[1] https://www.manning.com/books/nim-in-action
[2] http://www.adass2016.inaf.it/index.php/participant-list/15-i...
We are using it to build our newly minted startup, Metriculator - https://www.metriculator.com
This is the first functional language we are using (long time Ruby/Rails devs). We are also using the Phoenix framework.
Reasons why we chose Elixir/Phoenix -
- Immutability of data makes it easier to reason with and figure out exactly what is changed where.
- Lots of asynchronous work involved. Elixir is built for this.
- Real-time data push (Phoenix channels scale well in this respect)
- Syntax, stability and a vibrant, helpful community.
My Q1 goal is to build a simple game of Risk using text-based interface, and some AI that plays the other players - all to help my two nephews in Italy learn Python and have fun at the same time.
Not sure how long it will take, or if I'll ever be successful. Any hint (particularly on the text-based interface) would be really appreciated. I am now looking into Curses and Pygame.
C++. I'm looking to get into LLVM and maybe even contribute (that is a lofty goal)
ES6 or Typescript. I'm doing front end work for the first time this year and am looking into those (as it seems like I shouldn't start a project with Angular 1.x)
EDIT: I can't believe nobody else mentioned Eve.