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++.
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.
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.
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.
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.
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 is a subset (nay, it's a language within it's own right language now, the method chaining syntax is very readable) of Ruby running on the BEAM vm from Erlang.. not Erlang itself
Crystal is a native compilation of Ruby (or a subset at least), not Python btw.
But Erlang does have a few warts, both in the language syntax and in the standard library, and these warts are never going to go away, because backwards compatibility. (Erlang cannot hope to pull a Python 3 with any success.)
Elixir is a new development, hopefully avoiding the downsides while not losing the upsides and the general FP-esque idea, and retaining the VM-level interoperability.
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.
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 :(
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.
> 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.
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!
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.
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.
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.
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 :)
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.
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.
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).
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.
>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.
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.
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.
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.
- 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)
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.
84 comments
[ 2.9 ms ] story [ 40.4 ms ] threadI like the Rust community, friendly and helpful.
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, 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.
Elixir is a subset (nay, it's a language within it's own right language now, the method chaining syntax is very readable) of Ruby running on the BEAM vm from Erlang.. not Erlang itself
Crystal is a native compilation of Ruby (or a subset at least), not Python btw.
But Erlang does have a few warts, both in the language syntax and in the standard library, and these warts are never going to go away, because backwards compatibility. (Erlang cannot hope to pull a Python 3 with any success.)
Elixir is a new development, hopefully avoiding the downsides while not losing the upsides and the general FP-esque idea, and retaining the VM-level interoperability.
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.
Have you considered Nim? I think you might find that it is a more natural Python replacement :)
* 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 :(
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...
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.
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).
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.
Main: http://nim-lang.org
NES emulator (compiled to JavaScript, runs in the browser): https://hookrace.net/nimes/
Simple 2D game: https://hookrace.net/blog/writing-a-2d-platform-game-in-nim-...
More examples: https://nim-by-example.github.io/
Nim has pythonesque syntax, with Pascal/Delphi roots, fast compile times, portability (compiles down to C, JavaScript, LLVM), strong metaprogramming support, seamless FFI, optional GC, and a lot more.
It doesn't have Rust's ultimate safety, although it has quite a bit -- e.g., it can track which thread accesses what for concurrency (in a limited but extremely useful way).
I'm a fan; It looks like the fun of Python but the speed of C/C++. I haven't had a chance to start a project in Nim - hopefully, in 2017.
1 - https://manning.com/books/nim-in-action?a_aid=niminaction&a_...
Some Nim screencasts would be awesome. I would love to make some myself, if only I had the time...
Somehow language designers seem to cling to old syntaxes.
I mean s-expressions have their beauty. But C or VB like syntaxes always feel clunky to me.
Though I guess ML syntax is a tiny bit less ancient than either s-expression or Algol syntax, which seems to be what you are complaining about.
But after doing a search, it seems you're right. Languages with ML-family syntax weren't very popular the last 20 years. Most languages look like C or Algol these days.
I only knew that I didn't like most trailing delimitters and I knew only a few languages that didn't have them.
[1]: https://github.com/evincarofautumn/kitten
The reason why I believe Kotlin is a great way ahead is - Great java interop, removes a huge amount of boilerplate, results in very readable code and extremely easy to learn (one of the reasons we could not switch to Scala was the steep learning curve which would be a big problem for new developers joining us).
i 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 think this is overblown. Yes, the language has a deep learning curve, but you're really trading off language complexity for lack of framework complexity. Because the language is so powerful, you'll see a lot less 'magic' frameworks (no need for a DI framework, no need for AOP, etc) so applications tend to have a really low barrier of entry to work with. We hire new developers all the time and they are productive way before they master the language.
NoRedInk (among other companies) use non-mainstream FP languages and hire juniors all the time. Turns out that people can learn things quickly if they're smart (which is why you hired them, I hope) and are given mentorship.
I 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
- 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)