5 ms·

Actually the future is a language that best fits YOUR needs.

by arberx 5y ago

pionar 5y ago
Yes, that's always the answer. Use the tool best suited for the task in front of you.
dimgl 5y ago
After many years of programming I agree with this so much. I know now that if I need to do heavy I/O and JSON work Node.js is a no brainier. Need concurrency with a fast execution/compilation within a single binary? Go is amazing in that regard. Need to stay on the Microsoft stack and interop with legacy APIs? C# will more than likely fit the bill. There’s just so many languages and they each excel at different things. I no longer have the mentality where one size fits all.
- choeger 5y ago
  Heavy I/O in Node.js? And what the heck is JSON work and why can't any language do that? And of course, Rust is not a one-size-fits-all language. For starters it doesn't have a garbage collector. But it is type-safe. And that alone will pay a huge dividend down the road if you choose it today.
  - dimgl 5y ago
    Any language can do JSON serialization. Whether it's an enjoyable experience is another topic. Having to deal with JSON in Go is a massive pain comparatively. It's just way easier to do it in Node.js. I'm having to do this kind of work right now, where I'm leveraging a third-party API that has horrendous JSON responses and I'm having to convert it to a normalized JSON structure so that I can use it within my own app. I keep wishing I would have just gone with Node.js instead of Go but now I'm too far deep. By I/O, I meant that basically anything that requires you to wait for a response is really easy in Node.js. In particular handling HTTP requests is dead simple. My point being that I'll pick different tools for different jobs. Go is really nice when I have little control over the environment and architecture, such as with AWS Lambda. The ability to compile a binary specifically for that architecture without needing to deal with `node-gyp` in Node.js is attractive to me. But I'll weigh the pros and cons of going with each of these different tools that I'm comfortable with.
echelon 5y ago
Which turns out to be Rust in an ever increasingly many situations. Rust is going to eat into Java, C#, and Golang marketshare for services soon. The tooling for writing these is fantastic, and there's a single deployable binary with no GC.
- tayo42 5y ago
  Rust makes it way to hard to do anything practical with async, i find it hard to believe it would compete with those languages. If youre already in a situtation where you can already make do with gc whats there to gain by getting rid of it?
- metaltyphoon 5y ago
  Sorry to burst this bubble, but all 3 languages you mentioned won't lose any space for Rust for backends. Rust can only dream to come close to have tooling as nice as C#, Go and Java. Productivity wise, Rust is just not as good as the other languages you mentioned. async on Rust is a pain in the ass. For your hot path, sure use Rust, otherwise no one cares about a GC language as long as it's productive and can get the job done faster.
  - echelon 5y ago
    How is async Rust a pain in the ass? I've got actix handlers with various async database workloads, singleton LRU reloading caches, service calls, etc. It's a breeze. I'm no more productive in Java.
mooreds 5y ago
I totally get this. At the same time, as software developers we also need to be aware of industry trends, at least if we want to maximize our salary/career (whether you should do that is a whole different conversation). (Maybe this is a no-op comment if you expand what "YOUR needs" means.) That means that you are looking at a few dimensions when determining what language to solve problems: * can it solve the problem * can I use it to solve the problem * am I creating an issue by using it (for the team short term, for the company long term) * how does using it make me a better developer You don't need to think about this every time you write code, but when you are considering investing time learning or using a new language, it behooves you to look at the larger picture as well as the immediate situation.
Buttons840 5y ago
This whole thread (at the time of writing) ignores the hard part of dealing with large groups of people and interpersonal relationships. In such a context, what good does telling people to follow their heart do?
PaulDavisThe1st 5y ago
Which is why I look forward to spending the send half of the 2020's writing WASM by hand that gets JIT-compiled into machine code and then executed in the best implementation of Hypertalk I can get my hands on.

Actually the future is a language that best fits YOUR needs.

by arberx 5y ago

Actually the future is a language that best fits YOUR needs.

pionar 5y ago

Yes, that's always the answer. Use the tool best suited for the task in front of you.

dimgl 5y ago

After many years of programming I agree with this so much. I know now that if I need to do heavy I/O and JSON work Node.js is a no brainier. Need concurrency with a fast execution/compilation within a single binary? Go is amazing in that regard. Need to stay on the Microsoft stack and interop with legacy APIs? C# will more than likely fit the bill. There’s just so many languages and they each excel at different things. I no longer have the mentality where one size fits all.

choeger 5y ago
Heavy I/O in Node.js? And what the heck is JSON work and why can't any language do that? And of course, Rust is not a one-size-fits-all language. For starters it doesn't have a garbage collector. But it is type-safe. And that alone will pay a huge dividend down the road if you choose it today.
- dimgl 5y ago
  Any language can do JSON serialization. Whether it's an enjoyable experience is another topic. Having to deal with JSON in Go is a massive pain comparatively. It's just way easier to do it in Node.js. I'm having to do this kind of work right now, where I'm leveraging a third-party API that has horrendous JSON responses and I'm having to convert it to a normalized JSON structure so that I can use it within my own app. I keep wishing I would have just gone with Node.js instead of Go but now I'm too far deep. By I/O, I meant that basically anything that requires you to wait for a response is really easy in Node.js. In particular handling HTTP requests is dead simple. My point being that I'll pick different tools for different jobs. Go is really nice when I have little control over the environment and architecture, such as with AWS Lambda. The ability to compile a binary specifically for that architecture without needing to deal with `node-gyp` in Node.js is attractive to me. But I'll weigh the pros and cons of going with each of these different tools that I'm comfortable with.

echelon 5y ago

Which turns out to be Rust in an ever increasingly many situations. Rust is going to eat into Java, C#, and Golang marketshare for services soon. The tooling for writing these is fantastic, and there's a single deployable binary with no GC.

tayo42 5y ago
Rust makes it way to hard to do anything practical with async, i find it hard to believe it would compete with those languages. If youre already in a situtation where you can already make do with gc whats there to gain by getting rid of it?
metaltyphoon 5y ago
Sorry to burst this bubble, but all 3 languages you mentioned won't lose any space for Rust for backends. Rust can only dream to come close to have tooling as nice as C#, Go and Java. Productivity wise, Rust is just not as good as the other languages you mentioned. async on Rust is a pain in the ass. For your hot path, sure use Rust, otherwise no one cares about a GC language as long as it's productive and can get the job done faster.
- echelon 5y ago
  How is async Rust a pain in the ass? I've got actix handlers with various async database workloads, singleton LRU reloading caches, service calls, etc. It's a breeze. I'm no more productive in Java.

mooreds 5y ago

I totally get this. At the same time, as software developers we also need to be aware of industry trends, at least if we want to maximize our salary/career (whether you should do that is a whole different conversation). (Maybe this is a no-op comment if you expand what "YOUR needs" means.) That means that you are looking at a few dimensions when determining what language to solve problems: * can it solve the problem * can I use it to solve the problem * am I creating an issue by using it (for the team short term, for the company long term) * how does using it make me a better developer You don't need to think about this every time you write code, but when you are considering investing time learning or using a new language, it behooves you to look at the larger picture as well as the immediate situation.

Buttons840 5y ago

This whole thread (at the time of writing) ignores the hard part of dealing with large groups of people and interpersonal relationships. In such a context, what good does telling people to follow their heart do?

PaulDavisThe1st 5y ago

Which is why I look forward to spending the send half of the 2020's writing WASM by hand that gets JIT-compiled into machine code and then executed in the best implementation of Hypertalk I can get my hands on.