4 ms·

Am I the only one sick of projects declaring, "written in rust", "primarily developed in go", etc? Why do your users care about your implementation language? Do

Am I the only one sick of projects declaring, "written in rust", "primarily developed in go", etc? Why do your users care about your implementation language? Do you have any features worth mentioning? If your main selling point is that you used the shiny new language, I'm already doubting the usefulness of the endeavor. Just the straw that finally broke the camel's back . . .

chmike 10y ago
Another argument why I'm very interestd to know thta it's written in go is that go will be a first class language in thta IDE :)
adrianratnapala 10y ago
I care about it whether it pulls in big dependencies. So I tend to avoid things in Java or Node.js, and on Unix I would avoid .Net (Mono). On Windows I'm fine with .Net, but would want to avoid Python. For languages like Go and Rust which compile to native code, I don't give a damn -- except to note that it is such a language.
erre 10y ago
Interestingly, I am tired of most projects declaring the language in which they were written upfront, especially when they are a copy of something else, "but written in ${language}!" - however, I am interested in the language a text editor is written in. Or, rather, the language it's extensible in. I'm a long-time Emacs user, but have been growing increasingly tired of it. Whichever incarnation of Emacs I turn to, it just seems old-fashioned and outdated. And yet, whenever I try another editor, I end up coming back to Emacs. And one of the reasons is often the language (or ability at all) with which to extend it.
chewxy 10y ago
Perhaps not for this case, but for libraries, it'd be prudent to write the language that it's for
nitemice 10y ago
I don't think it's about the users at all. I'd speculate the main reason people write things like that, and so prominently, is because they hope it will attract contributors who either already know that language or are enthusiastic enough about it to progress the project significantly. Otherwise someone may just pass it over assuming it's another piece of junk written in <insert-your-least-favourite-language-here>.
conradev 10y ago
If the language is relevant to the innovation then I think it's fine to mention it. For example, a font renderer in Rust that is faster than FreeType[1]. There is also Servo[2], which is a web rendering engine that will be able to eliminate memory corruption bugs. For other projects (like this one) I find that the language can be a distraction from the actual value it provides. [1] https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445#.os6a1lsrd https://medium.com/@raphlinus/inside-the-fastest-font-render... [2] https://servo.org https://servo.org
justabystander 10y ago
Some people avoid projects because of the language it's developed in, unfair as it may seem. This could be because they've used a similar project with performance or maintainability issues written in some other language. That could be because the project itself, or it might be that the language isn't particularly suited to the problem space. I know of a few projects for which I'm personally awaiting more performant alternatives. Others aren't particularly fond of the package managers and build systems that accompany certain languages. And, at the end of a day, the bias could be even less reasonable than that. Language bias is a unfortunate reality, but as long as it doesn't start a flamewar, it's not a big issue. Additionally, on the positive side, some people want to contribute to a project and wish to do so in a certain language. This could be because it's their preferred language, or they may want to exercise a newer skillset or build a contribution portfolio in a new area. The language doesn't matter much in a pre-compiled application, but when it's an open source application looking to gather and foster a community or build momentum, the language does matter.
eksu 10y ago
Perhaps this open source project was posted on Hacker News not only to garner users, but contributors?
dcw303 10y ago
I've been guilty of this. When meteor.js was new, I made an issue tracker, and proudly submitted it to HN with a title something like "Issue tracker made with Meteor". Some things I found: 1. You have a much better chance of getting upvotes if you appeal to a popular technology. Had I not mentioned Meteor I suspect I would never have made it to the front page. 2. In my case, most of the initial interest came from those more interested in the underlying technology than the application. 3. I found it very difficult to market the project as an issue tracker as it was already established as a meteor project.
- qznc 10y ago
  I guess this one? https://github.com/dcw303/mindmeld https://github.com/dcw303/mindmeld Could not get it to run. Broken with current meteor?
  - dcw303 10y ago
    That's the one. It hasn't been updated since Meteor 0.6(?) a few years ago, so I'd be amazed if it still worked.
dagw 10y ago
Why do your users care about your implementation language? They don't, but they're not 'talking' to users with those statements. For Open Source projects getting contributors is just as important as getting users, and they care what language you're using. Especially on a site like this one there is a decent chance that you can reach people who also want to help out with the development.
preek 10y ago
The headline on the Landing Page says "Elegant Free Open-Source". I for one applaud these great selling propositions. And I'm speaking after using Emacs and VIM for 15 years. Sublime Text was horrible in that it offered an easy refuge to many young and inexperienced people. But ultimately it was a closed source prison that they got pulled into. And yes, I'm a professional developer having founded multiple companies. I'm a capitalist, nothing wrong with selling software. However, having great tools that last a lifetime available is one of the most important point I learned and like to teach to my students (I'm a lecturer, too). Why lock yourself in? Just because it looks more shiny and is easier in the first week? That's a good reason to use many things, but not your primary driver as a professional software engineer. Hooray for these new editors that look shiny and are open source. And then when the students ask how I did those crazy things in Emacs, they still get those huge eyes and want to gobble all the information in. This kind of curiousness happens rarely with people locked into proprietary systems.
tjpnz 10y ago
I would add "on Github" to that list.
wingerlang 10y ago
Considering one of the selling points is 100% open source, it makes sense to point out the language.
krylon 10y ago
> Why do your users care about your implementation language? In an open source project, it matters to potential contributors. It might matter to users in terms of what platforms it can be ported to - probably less these days, where "portable" means "runs on Windows, Mac, Linux", but still, it is not irrelevant.
jdc0589 10y ago
at this point, its one of the first things I check for if it isn't declared publicly. Why? because I'm sick of every application being written in js/electron, even when it's a huge hinderance to performance. You can write bad/poorly optimized code in any language. But its a lot harder to write polished, efficient, low consumption applications in an electron stack for some application types than it needs to be.

chmike 10y ago

Another argument why I'm very interestd to know thta it's written in go is that go will be a first class language in thta IDE :)

adrianratnapala 10y ago

I care about it whether it pulls in big dependencies. So I tend to avoid things in Java or Node.js, and on Unix I would avoid .Net (Mono). On Windows I'm fine with .Net, but would want to avoid Python. For languages like Go and Rust which compile to native code, I don't give a damn -- except to note that it is such a language.

erre 10y ago

Interestingly, I am tired of most projects declaring the language in which they were written upfront, especially when they are a copy of something else, "but written in ${language}!" - however, I am interested in the language a text editor is written in. Or, rather, the language it's extensible in. I'm a long-time Emacs user, but have been growing increasingly tired of it. Whichever incarnation of Emacs I turn to, it just seems old-fashioned and outdated. And yet, whenever I try another editor, I end up coming back to Emacs. And one of the reasons is often the language (or ability at all) with which to extend it.

chewxy 10y ago

Perhaps not for this case, but for libraries, it'd be prudent to write the language that it's for

nitemice 10y ago

I don't think it's about the users at all. I'd speculate the main reason people write things like that, and so prominently, is because they hope it will attract contributors who either already know that language or are enthusiastic enough about it to progress the project significantly. Otherwise someone may just pass it over assuming it's another piece of junk written in <insert-your-least-favourite-language-here>.

conradev 10y ago

If the language is relevant to the innovation then I think it's fine to mention it. For example, a font renderer in Rust that is faster than FreeType[1]. There is also Servo[2], which is a web rendering engine that will be able to eliminate memory corruption bugs. For other projects (like this one) I find that the language can be a distraction from the actual value it provides. [1] https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445#.os6a1lsrd https://medium.com/@raphlinus/inside-the-fastest-font-render... [2] https://servo.org https://servo.org

justabystander 10y ago

Some people avoid projects because of the language it's developed in, unfair as it may seem. This could be because they've used a similar project with performance or maintainability issues written in some other language. That could be because the project itself, or it might be that the language isn't particularly suited to the problem space. I know of a few projects for which I'm personally awaiting more performant alternatives. Others aren't particularly fond of the package managers and build systems that accompany certain languages. And, at the end of a day, the bias could be even less reasonable than that. Language bias is a unfortunate reality, but as long as it doesn't start a flamewar, it's not a big issue. Additionally, on the positive side, some people want to contribute to a project and wish to do so in a certain language. This could be because it's their preferred language, or they may want to exercise a newer skillset or build a contribution portfolio in a new area. The language doesn't matter much in a pre-compiled application, but when it's an open source application looking to gather and foster a community or build momentum, the language does matter.

eksu 10y ago

Perhaps this open source project was posted on Hacker News not only to garner users, but contributors?

dcw303 10y ago

I've been guilty of this. When meteor.js was new, I made an issue tracker, and proudly submitted it to HN with a title something like "Issue tracker made with Meteor". Some things I found: 1. You have a much better chance of getting upvotes if you appeal to a popular technology. Had I not mentioned Meteor I suspect I would never have made it to the front page. 2. In my case, most of the initial interest came from those more interested in the underlying technology than the application. 3. I found it very difficult to market the project as an issue tracker as it was already established as a meteor project.

qznc 10y ago
I guess this one? https://github.com/dcw303/mindmeld https://github.com/dcw303/mindmeld Could not get it to run. Broken with current meteor?
- dcw303 10y ago
  That's the one. It hasn't been updated since Meteor 0.6(?) a few years ago, so I'd be amazed if it still worked.

dagw 10y ago

Why do your users care about your implementation language? They don't, but they're not 'talking' to users with those statements. For Open Source projects getting contributors is just as important as getting users, and they care what language you're using. Especially on a site like this one there is a decent chance that you can reach people who also want to help out with the development.

preek 10y ago

The headline on the Landing Page says "Elegant Free Open-Source". I for one applaud these great selling propositions. And I'm speaking after using Emacs and VIM for 15 years. Sublime Text was horrible in that it offered an easy refuge to many young and inexperienced people. But ultimately it was a closed source prison that they got pulled into. And yes, I'm a professional developer having founded multiple companies. I'm a capitalist, nothing wrong with selling software. However, having great tools that last a lifetime available is one of the most important point I learned and like to teach to my students (I'm a lecturer, too). Why lock yourself in? Just because it looks more shiny and is easier in the first week? That's a good reason to use many things, but not your primary driver as a professional software engineer. Hooray for these new editors that look shiny and are open source. And then when the students ask how I did those crazy things in Emacs, they still get those huge eyes and want to gobble all the information in. This kind of curiousness happens rarely with people locked into proprietary systems.

tjpnz 10y ago

I would add "on Github" to that list.

wingerlang 10y ago

Considering one of the selling points is 100% open source, it makes sense to point out the language.

krylon 10y ago

> Why do your users care about your implementation language? In an open source project, it matters to potential contributors. It might matter to users in terms of what platforms it can be ported to - probably less these days, where "portable" means "runs on Windows, Mac, Linux", but still, it is not irrelevant.

jdc0589 10y ago

at this point, its one of the first things I check for if it isn't declared publicly. Why? because I'm sick of every application being written in js/electron, even when it's a huge hinderance to performance. You can write bad/poorly optimized code in any language. But its a lot harder to write polished, efficient, low consumption applications in an electron stack for some application types than it needs to be.