Ask HN: What “new” programming languages will you be using in 2017 - ramxtr
======
beagle3
Nim.

Main: [http://nim-lang.org](http://nim-lang.org)

NES emulator (compiled to JavaScript, runs in the browser):
[https://hookrace.net/nimes/](https://hookrace.net/nimes/)

Simple 2D game: [https://hookrace.net/blog/writing-a-2d-platform-game-in-
nim-...](https://hookrace.net/blog/writing-a-2d-platform-game-in-nim-with-
sdl2/)

More examples: [https://nim-by-example.github.io/](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.

~~~
dom96
Happy to see this mentioned here! My Nim book[1] is also going to be finally
published in 2017. Lots of great things to look forward to in 2017 for Nim :)

1 - [https://manning.com/books/nim-in-
action?a_aid=niminaction&a_...](https://manning.com/books/nim-in-
action?a_aid=niminaction&a_bid=78a27e81)

~~~
joshbaptiste
Great dom96, I have the pre-release and i'm really enjoying it. When I get a
hang of Nim I wanna create a set of Youtube "Learning Nim" screencasts since
Nim based videos are scarce on Youtube.

~~~
dom96
Glad to hear you're enjoying it :)

Some Nim screencasts would be awesome. I would love to make some myself, if
only I had the time...

------
grardb
I recently got into TypeScript, if that counts. I'm really enjoying it so far,
but I'm running into some annoying things as a beginner:

* 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 :(

~~~
orif
For packages with default export, you can use synthetic imports options in
tsconfig.

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).

~~~
grardb
Oh nice, thanks for the tips! Those things will make my code so much nicer :D
I am indeed using webpack, so that shouldn't be an issue (unless it doesn't
work in conjunction with `target: 'node'`). Crossing my fingers!

------
rohanprabhu
Definitely Kotlin. I had a meeting with my team and talked about the
advantages of Kotlin and why I believe we should start writing a proportion of
the new modules in Kotlin and have asked for their input. This is one of the
cases where it needs to be unanimous decision, but so far everyone seems in
favour of it and looks like we'll be writing a good amount of Kotlin in the
coming months.

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).

~~~
runT1ME
>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.

~~~
sotojuan
This attitude happens all the time FP in the job comes up and it essentially
means the parent commenter's company has no time or resources for training or
mentoring.

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.

------
BlackjackCF
Rust - I've been looking at Rust from afar, and I like what I see. A coworker
also has given it a glowing recommendation.

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.

~~~
ellius
Can you elaborate on how you've been burned? I want to integrate it into some
work projects, so I'd like to be aware of potential pitfalls.

~~~
BlackjackCF
Take what I'm saying with a grain of salt. It was stuff at work with
MongooseIM (a fork of ejabberd) and it was just horribly unintuitive to
configure and run. That could have just been my outsider's view as a devops
person trying to figure out how to run a poorly configured app for production
though.

------
nine_k
New things I plan to pay attention to:

* 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.

~~~
_joel
I think that's not quite right.

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.

~~~
sotojuan
Elixir is in no way a subset of Ruby.

~~~
_joel
Sure, perhaps incorrect definition, hence why I said it's a language in it's
own right. It's definitely influenced by Ruby. [https://www.sitepoint.com/an-
interview-with-elixir-creator-j...](https://www.sitepoint.com/an-interview-
with-elixir-creator-jose-valim/)

------
dopamean
I know I'm late to the game but Go. I've been wanting to play with it for a
while but haven't had the mental capacity to really dive in after work. As it
turns out the company I work at has a project or two slated for the new year
that will likely be written, at least partially, in Go. I look forward to
getting my feet wet.

~~~
TheGillis
In a startup now that is using Go. It has worked out extremely well so far.
Some of the pieces like unused imports are errors, and checking for error
return values in the end help to keep things clean. Performance is definitely
impressive.

------
lobster_johnson
Rust: Because I like the idea of zero-cost abstractions in a rich ML-like
data-oriented language that has modern facilities such as pattern matching,
abstract data types, generics, hygienic macros and package management, without
the legacy baggage of C++.

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.

------
evincarofautumn
New: Rust, ATS; new to me: J, D. And working on the compiler for Kitten[1],
which should be usable by the end of the year.

[1]:
[https://github.com/evincarofautumn/kitten](https://github.com/evincarofautumn/kitten)

------
ggregoire
If we extend the discussion to the query languages: GraphQL.

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.

------
zerosign
rust, ruby, scala, typescript

\- 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)

------
hakanderyal
\- Nim.

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.

------
ndr
Pony: [http://www.ponylang.org/](http://www.ponylang.org/)

------
ishbits
Rust. I think its got everything I want in a replacement for C. Plus the
project I'm working on is considering using Rust to replace C for parsing
untrusted input. I just need to get past the syntax.

------
xj9
Rust and Elixir. i have a number of p2p projects i want to get started on.
i've spent the last couple of years educating myself on the state of the art
for this type of tech, and i have some ideas that i think may be interesting.

------
michaelchisari
I'm starting a greenfield project using Rust for the backend and Elm for the
frontend. Strong typing and safety all around. Wish me luck.

------
mike-cardwell
I started learning Rust a few days ago. It's an interesting language and I can
really see the motivation behind creating it.

------
afshinmeh
I recently joined Rust community to develop some crates. I always wanted to
learn a system programming language but haven't had a chance to try C / C++.

I like the Rust community, friendly and helpful.

------
ramxtr
I'm personally aiming for Scala. I took the first coursera class and loved the
language features so far. The main potential problem I see is a decreasing
rate of adoption.

~~~
pcsanwald
YMMV, but when I got back into functional programming years ago, I was excited
to learn scala, but as it turned out, clojure was everything I expected scala
to be.

~~~
nine_k
Everything, including e.g. type inference?

------
agentgt
Well "new" is sort of relative (and thus nebulous) so lets ignore that. This
2017 as my company moves things closer to the data I have been using lots
PL/pgSQL.

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](https://github.com/thehydroimpulse/postgres-extension.rs)

------
partisan
F# on .net core and linux.

Nim as mentioned by @beagle3.

------
sjellis
Rust, definitely. I'm actually most interested in the possibility of using it
for some of the areas that people are currently using Go (CLI tools and back-
end Web). Rust actually already has a lot of the selling points of Go and in
the long-term I think that Rust will outdo Go in some ways, but the HTTP stack
is still maturing.

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.

------
kampsy
Rust. Have not had the time to play around with it. Am a full-time Go
developer and I want to add Rust to my CV.

------
thegayngler
Swift - It's cross platform, pretty and seems to be well maintained.
JavaScript(ES2017, React, etc.) - I already use this now. I will just be
adding on to what I already use from it now. GraphQL - I was looking for a
REST replacement. GraphQL looks to be it. I feel like it makes sense to me.

------
ziotom78
I am going to study Cray's Chapel [1]. I'm a cosmologist and regularly have to
write/use codes that run on clusters. In the past years I have tested many
different languages to substitute C/C++/Fortran for HPC development: Ocaml,
Nim, Ada, and Julia. I must say that so far Julia has proven to be the best
choice by far. However, I miss the C/C++/Fortran compilation phase, which
spots missing parameters, mismatched types and other errors which Julia
catches at runtime. Chapel might provide the best of two worlds: static
compilation like C, and numerical-oriented features, like Julia.

[1] [http://chapel.cray.com/](http://chapel.cray.com/)

~~~
dom96
Hey ziotom78. I didn't realise you were evaluating so many languages. I'm
curious, where did nim fall short? How can it be improved for your use case?

Cosmology sounds exciting.

~~~
ziotom78
Hi dom96,

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](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;](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](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](https://www.manning.com/books/nim-in-action)

[2] [http://www.adass2016.inaf.it/index.php/participant-
list/15-i...](http://www.adass2016.inaf.it/index.php/participant-
list/15-invited/28-robitaille-thomas)

[3]
[https://www.threadingbuildingblocks.org/](https://www.threadingbuildingblocks.org/)

[4] [https://github.com/pragmagic/vscode-
nim](https://github.com/pragmagic/vscode-nim)

~~~
dom96
Thank you for taking the time to write this. I almost missed it (wish HN gave
notifications for replies). I will do my best to take your feedback into
account :)

------
pcsanwald
I really want to check out typescript this year. Seems pretty cool and I've
been working a lot in JS (ES6) this past year, so I feel like it'll be a great
experience to really feel what a type system buys/costs you.

------
silvaben
Elixir.

We are using it to build our newly minted startup, Metriculator -
[https://www.metriculator.com](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.

------
simonebrunozzi
I'm re-learning Python! Not a "new" language, but I lost most of my (already
poor) Python skills and I want to revamp them.

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.

------
Tobu
I'd like to get started using Rust for bare metal development.

------
GavinMcG
Elixir and Julia. Gimme those macros!

------
pavlo
I would like to learn some rust and/or elixir

------
chmike
I'm going full Go. I've got it accepted as programming language for some
software component I'm in charge of. It's for a scientific research
application. For me it's a big change since I was full C++ for the last 15
years. I studied and considered D but there is not enough traction and tool
set is lighter.

------
dosshell
I will actually take the time to learn nasm and do some low stuff. The goal is
to explore real mode and bios interrupts.

------
speedkills
More Scala, starting to dabble with early versions of Dotty, Idris, Haskell,
Nim, and very possibly Rust.

~~~
s4vi0r
Isn't Dotty just the name of the new compiler for Scala?

------
jetti
Elixir. I started last week and already love it.

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)

------
breevo
I'm hoping to get Rust into the mix at work. Will definitely be playing with
it at home.

------
IRATEEE
I have a hard time choosing between Go and Rust, I really like Go, but I have
fallen in love with Rust. But I think I will dive into Go just because of
getting a job asap in 2017.

------
kensai
Lua. Combine it with C to enjoy both of them even more! :)

~~~
etiene
I love Lua and I just mentioned it on the "old" thread, however! It's almost
24 years old :')

------
irrational
How do you define new? I'd say ES6 if that counts.

------
jksmith
I'd like to build up a shop of 50 devs using the golang toolchain and just see
how much shit we can get done.

------
mindcrime
Probably one of Rust, Go, Julia, or Scala.

------
netrap
I'd like to give Rust a try for real.

------
vorotato
I started using F# at the end of 2016 and I'm excited to continue it through
2017.

------
cwbrandsma
Swift and React JSX scripts (and lots of C#...which is neither old nor new)

------
miguelrochefort
Eve because logic programming.

 _EDIT: I can 't believe nobody else mentioned Eve._

------
ww520
ES6, does that count?

------
aspencer8111
VueActiveAngularEmbers.js v10.3.1 - A hybrid of the latest 4 hotnesses to hit
the JS community. Because - yay new JS frameworks every 2 weeks!

------
Koshkin
C++17

------
AlphaGeekZulu
Rust.

------
BuuQu9hu
I want to try Monte but the documentation isn't very good and I don't
understand their IRC conversations.

