Elixir and Julia. Gimme those macros!
Ask HN: What “new” programming languages will you be using in 2017
41–50 of 85 posts
Re: Ask HN: What “new” programming languages will you be using in 2017
#42Lua. Combine it with C to enjoy both of them even more! :)
Re: Ask HN: What “new” programming languages will you be using in 2017
#43Definitely 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 Kot…
+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.
Re: Ask HN: What “new” programming languages will you be using in 2017
#44Rust - 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.
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.
Re: Ask HN: What “new” programming languages will you be using in 2017
#45Rust.
Re: Ask HN: What “new” programming languages will you be using in 2017
#46Rust, 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.
Re: Ask HN: What “new” programming languages will you be using in 2017
#47Nim. 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,…
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.
Re: Ask HN: What “new” programming languages will you be using in 2017
#48Rust - 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.
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.
Re: Ask HN: What “new” programming languages will you be using in 2017
#49Definitely 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 Kot…
>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.
Re: Ask HN: What “new” programming languages will you be using in 2017
#50I 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…
> 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.