7 ms·

Ask HN: What “new” programming languages will you be using in 2017

56 points by ramxtr 10y ago

mindcrime 10y ago
Probably one of Rust, Go, Julia, or Scala.
irrational 10y ago
How do you define new? I'd say ES6 if that counts.
pavlo 10y ago
I would like to learn some rust and/or elixir
afshinmeh 10y ago
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.
ishbits 10y ago
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.
mike-cardwell 10y ago
I started learning Rust a few days ago. It's an interesting language and I can really see the motivation behind creating it.
dopamean 10y ago
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 10y ago
  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.
ramxtr 10y ago
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 10y ago
  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 10y ago
    Everything, including e.g. type inference?
  - idobai 10y ago
    They're totally different languages. But because of safety, performance and productivity I prefer Scala.
pcsanwald 10y ago
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.
dosshell 10y ago
I will actually take the time to learn nasm and do some low stuff. The goal is to explore real mode and bios interrupts.
breevo 10y ago
I'm hoping to get Rust into the mix at work. Will definitely be playing with it at home.
ggregoire 10y ago
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.
ndr 10y ago
Pony: http://www.ponylang.org/ http://www.ponylang.org/
nine_k 10y ago
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 10y ago
  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 10y ago
    Elixir is in no way a subset of Ruby.
    - _joel 10y ago
      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-jose-valim/ https://www.sitepoint.com/an-interview-with-elixir-creator-j...
    - nine_k 10y ago
      crystal-lang.org states: Language Goals * Have a syntax similar to Ruby (but compatibility with it is not a goal) So it's more about being recognizable than being compatible.
  - nine_k 10y ago
    Indeed, Elixir is not Erlang. 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.
grardb 10y ago
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 :(
- k__ 10y ago
  > For many third-party libraries, needing to write `import * as Something from 'some-package'` instead of `import Something from 'some-package`. 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.
xj9 10y ago
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.
beagle3 10y ago
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-with-sdl2/ https://hookrace.net/blog/writing-a-2d-platform-game-in-nim-... 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 10y ago
  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_bid=78a27e81 https://manning.com/books/nim-in-action?a_aid=niminaction&a_...
  - joshbaptiste 10y ago
    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 10y ago
      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...
- k__ 10y ago
  Nim is one of the few 'new' languages with nice syntax. (others being Haskell, which could use less confusing 'operators', LiveScript and Elm) 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.
BuuQu9hu 10y ago
I want to try Monte but the documentation isn't very good and I don't understand their IRC conversations.
michaelchisari 10y ago
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.
evincarofautumn 10y ago
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
rohanprabhu 10y ago
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 10y ago
  >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 10y ago
    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.
- k__ 10y ago
  Cheylon and Scala seemed better to me when they started. But it seems Kotlin is what Java really should have been, hehe :)
  - 10y ago
chmike 10y ago
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.
jksmith 10y ago
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.
aspencer8111 10y ago
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!
agentgt 10y ago
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
zerosign 10y ago
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)
thegayngler 10y ago
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.
BlackjackCF 10y ago
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 10y ago
  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 10y ago
    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.
Tobu 10y ago
I'd like to get started using Rust for bare metal development.
ww520 10y ago
ES6, does that count?
cwbrandsma 10y ago
Swift and React JSX scripts (and lots of C#...which is neither old nor new)
netrap 10y ago
I'd like to give Rust a try for real.
GavinMcG 10y ago
Elixir and Julia. Gimme those macros!
kensai 10y ago
Lua. Combine it with C to enjoy both of them even more! :)
- etiene 10y ago
  I love Lua and I just mentioned it on the "old" thread, however! It's almost 24 years old :')
AlphaGeekZulu 10y ago
Rust.
sjellis 10y ago
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.
partisan 10y ago
F# on .net core and linux. Nim as mentioned by @beagle3.
lobster_johnson 10y ago
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.
miguelrochefort 10y ago
Eve because logic programming. EDIT: I can't believe nobody else mentioned Eve.
Koshkin 10y ago
C++17
vorotato 10y ago
I started using F# at the end of 2016 and I'm excited to continue it through 2017.
simonebrunozzi 10y ago
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.
hakanderyal 10y ago
- 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.
kampsy 10y ago
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.
silvaben 10y ago
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.
speedkills 10y ago
More Scala, starting to dabble with early versions of Dotty, Idris, Haskell, Nim, and very possibly Rust.
- s4vi0r 10y ago
  Isn't Dotty just the name of the new compiler for Scala?
IRATEEE 10y ago
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.
ziotom78 10y ago
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 10y ago
  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 10y ago
    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-invited/28-robitaille-thomas http://www.adass2016.inaf.it/index.php/participant-list/15-i... [3] https://www.threadingbuildingblocks.org/ https://www.threadingbuildingblocks.org/ [4] https://github.com/pragmagic/vscode-nim https://github.com/pragmagic/vscode-nim
jetti 10y ago
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)

56 points by ramxtr 10y ago

mindcrime 10y ago

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

irrational 10y ago

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

pavlo 10y ago

I would like to learn some rust and/or elixir

afshinmeh 10y ago

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.

ishbits 10y ago

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.

mike-cardwell 10y ago

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

dopamean 10y ago

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 10y ago
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.

ramxtr 10y ago

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 10y ago
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 10y ago
  Everything, including e.g. type inference?
- idobai 10y ago
  They're totally different languages. But because of safety, performance and productivity I prefer Scala.

pcsanwald 10y ago

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.

dosshell 10y ago

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

breevo 10y ago

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

ggregoire 10y ago

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.

ndr 10y ago

Pony: http://www.ponylang.org/ http://www.ponylang.org/

nine_k 10y ago

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 10y ago
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 10y ago
  Elixir is in no way a subset of Ruby.
  - _joel 10y ago
    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-jose-valim/ https://www.sitepoint.com/an-interview-with-elixir-creator-j...
  - nine_k 10y ago
    crystal-lang.org states: Language Goals * Have a syntax similar to Ruby (but compatibility with it is not a goal) So it's more about being recognizable than being compatible.
- nine_k 10y ago
  Indeed, Elixir is not Erlang. 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.

grardb 10y ago

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

k__ 10y ago
> For many third-party libraries, needing to write `import * as Something from 'some-package'` instead of `import Something from 'some-package`. 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.

xj9 10y ago

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.

beagle3 10y ago

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-with-sdl2/ https://hookrace.net/blog/writing-a-2d-platform-game-in-nim-... 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 10y ago
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_bid=78a27e81 https://manning.com/books/nim-in-action?a_aid=niminaction&a_...
- joshbaptiste 10y ago
  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 10y ago
    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...
k__ 10y ago
Nim is one of the few 'new' languages with nice syntax. (others being Haskell, which could use less confusing 'operators', LiveScript and Elm) 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.

BuuQu9hu 10y ago

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

michaelchisari 10y ago

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.

evincarofautumn 10y ago

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

rohanprabhu 10y ago

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 10y ago
>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 10y ago
  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.
k__ 10y ago
Cheylon and Scala seemed better to me when they started. But it seems Kotlin is what Java really should have been, hehe :)
- 10y ago

chmike 10y ago

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.

jksmith 10y ago

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.

aspencer8111 10y ago

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!

agentgt 10y ago

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

zerosign 10y ago

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)

thegayngler 10y ago

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.

BlackjackCF 10y ago

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 10y ago
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 10y ago
  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.

Tobu 10y ago

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

ww520 10y ago

ES6, does that count?

cwbrandsma 10y ago

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

netrap 10y ago

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

GavinMcG 10y ago

Elixir and Julia. Gimme those macros!

kensai 10y ago

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

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

AlphaGeekZulu 10y ago

Rust.

sjellis 10y ago

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.

partisan 10y ago

F# on .net core and linux. Nim as mentioned by @beagle3.

lobster_johnson 10y ago

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.

miguelrochefort 10y ago

Eve because logic programming. EDIT: I can't believe nobody else mentioned Eve.

Koshkin 10y ago

C++17

vorotato 10y ago

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

simonebrunozzi 10y ago

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.

hakanderyal 10y ago

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

kampsy 10y ago

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.

silvaben 10y ago

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.

speedkills 10y ago

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

s4vi0r 10y ago
Isn't Dotty just the name of the new compiler for Scala?

IRATEEE 10y ago

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.

ziotom78 10y ago

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 10y ago
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 10y ago
  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-invited/28-robitaille-thomas http://www.adass2016.inaf.it/index.php/participant-list/15-i... [3] https://www.threadingbuildingblocks.org/ https://www.threadingbuildingblocks.org/ [4] https://github.com/pragmagic/vscode-nim https://github.com/pragmagic/vscode-nim

jetti 10y ago

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)