Ask HN: What “new” programming languages will you be using in 2017
84 comments
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_...
1 - https://manning.com/books/nim-in-action?a_aid=niminaction&a_...
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.
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...
Some Nim screencasts would be awesome. I would love to make some myself, if only I had the time...
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.
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.
Funny that you praise languages using ML-family syntax while complaining about language designers using "old" syntaxes.
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.
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.
Really? Didn't know that :)
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.
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.
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 :(
* 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 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).
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).
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!
> 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.
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.
I have completely given up on DefinitelyTyped/Typings/@types. The odds that any non-trivial type definitions are complete, up-to-date, and correct seems to be incredibly slim -- and god help you if you're stuck on a very specific version of an NPM library. I had high hopes with @types but all I have to show for it is an increasingly large file containing modules declared as "any".
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.
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.
The Microsoft @types repository is actually not the recommended way of storing Typescript typings.
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...
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...
Why not just ES6 with Babel?
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).
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).
>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.
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.
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.
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.
Cheylon and Scala seemed better to me when they started. But it seems Kotlin is what Java really should have been, hehe :)
my problem with scala seems to be its future. it's so convoluted right now :( (i quite like scala btw)
+1
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.
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.
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.
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.
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.
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.
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.
* 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.
> * 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 :)
Have you considered Nim? I think you might find that it is a more natural Python replacement :)
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.
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.
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.
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.
Elixir is in no way a subset of Ruby.
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...
crystal-lang.org states:
Language Goals
* Have a syntax similar to Ruby (but compatibility with it is not a goal)
Crystal has a strong Ruby flavor, but it's not a subset of Ruby.
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.
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.
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.
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.
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.
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.
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
[1]: https://github.com/evincarofautumn/kitten
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.
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, 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)
- 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)
- 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.
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.
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.
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.
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.
I started learning Rust a few days ago. It's an interesting language and I can really see the motivation behind creating it.
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.
I like the Rust community, friendly and helpful.
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.
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
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
F# on .net core and linux.
Nim as mentioned by @beagle3.
Nim as mentioned by @beagle3.
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.
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.
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.
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.
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/
[1] http://chapel.cray.com/
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.
Cosmology sounds exciting.
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. 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...
[3] https://www.threadingbuildingblocks.org/
[4] https://github.com/pragmagic/vscode-nim
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...
[3] https://www.threadingbuildingblocks.org/
[4] https://github.com/pragmagic/vscode-nim
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 :)
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.
Elixir.
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.
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.
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.
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.
I'd like to get started using Rust for bare metal development.
Elixir and Julia. Gimme those macros!
I would like to learn some rust and/or elixir
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.
I will actually take the time to learn nasm and do some low stuff. The goal is to explore real mode and bios interrupts.
More Scala, starting to dabble with early versions of Dotty, Idris, Haskell, Nim, and very possibly Rust.
Isn't Dotty just the name of the new compiler for Scala?
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)
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)
I'm hoping to get Rust into the mix at work. Will definitely be playing with it at home.
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.
How do you define new? I'd say ES6 if that counts.
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.
Probably one of Rust, Go, Julia, or Scala.
I'd like to give Rust a try for real.
I started using F# at the end of 2016 and I'm excited to continue it through 2017.
Swift and React JSX scripts (and lots of C#...which is neither old nor new)
Eve because logic programming.
EDIT: I can't believe nobody else mentioned Eve.
EDIT: I can't believe nobody else mentioned Eve.
ES6, does that count?
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!
C++17
Rust.
I want to try Monte but the documentation isn't very good and I don't understand their IRC conversations.
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.