HN Explorer

Ask HN: Which lang. are you most productive for API access and computing data?

10 points by mettamage ↗ HN
Recently I saw a statement of someone claiming to be most productive in Smalltalk, and someone commenting that he/she wasn't [0]. I have noticed that I find stories as to why people that are or aren't productive in a language insightful. I will be in "building projects" mode within 2 weeks from now [2]. I know most of my projects will involve API access, database stuff, simple math computations, if needed. It probably won't involve a web front-end, it might but I wouldn't count on that.

I've seen quite a few languages to one degree or another [1]. So for the following languages I have a clue how productive I'd be:

JS, Py3, Java, Obj-C, C, C++, Bash, Ruby, C#, VBA, x86-64, R, PHP, Matlab, Mathematica, and Go.

I'd still like to know what you think from these languages in which you feel most productive and why.

Languages I don't have a clue about:

Haskell, Lisp, Smalltalk, Kotlin, Swift, Rust, Dart, Scala, Perl, Julia, Groovy, APL, Erlang, Elixir, Clojure, Delphi and F#

I'd really like to know from these languages in which you feel most productive and why.

[0] https://news.ycombinator.com/item?id=29225207

[1] At least one project, all the way up to using professionally.

[2] Personal context:

I'm going to be unemployed soon. Rather than finding a new job I figured, screw it! I'm going to do stuff that I actually like to do. After 3.16 hellish years that was 23 months job searching in the software industry, and 15 months of working at companies I wasn't a fit for (one way or another) I need that. A bsc. and msc. in computer science did not get me far in the resume screening round (hence the long search for almost 2 years).

9 comments

[ 3.4 ms ] story [ 33.2 ms ] thread
potta_coffee
I've been really productive in Python in Javascript but Golang as slowly eroded away at those, now it's my primary language for most work. I do lots of backend web dev and I've recently started writing Lambdas in Go and find it superior to Python - better performance overall.

I've found that it takes me longer to write code in Go than Python and the code is more verbose, but I have a very high rate of first-compile success. Compiler catches most errors I'm likely to make. I've written about 6 small services in Go now and 1 med / large sized one.

mettamage
Interesting, I've noticed that the strong typing in Go does really help with getting that compile to work.

I've worked in a medium Go codebase (one might call it big, it's on the edge). I sometimes had a really hard time getting a particular value from a variable. The problem was that the way the code was structured, I couldn't know the type, but in the debugger I did see that the value was there in memory. The senior Go software engineer told me to make the type global, but I don't know what to think of that to make any type global the moment multiple very far away source files need that particular form of type information.

Another thing that I've seen that helps with Go productivity is the relentless focus of only one way to do things.

Edit: I also think what is amazing about Go is the whole "everything sensible is baked in" type of thing. You may disagree if it's sensible. But I like being able to immediately write tests, or write HTML templates, etc.

potta_coffee
Project structure is one of the things about Go that I didn't like. Because the community emphasizes the standard library over frameworks, and the import system was a little different, I really struggled with figuring out how to structure new projects.

I'm not necessarily a Go fanboy, it's not exactly the most fun code to write but it's been a valuable tool for me.

0des
Go, by a mile. From day 1 all I wanted to do was write programs that compile down to a single binary, and code that could run on just about any machine I had. That was a far fetched dream for the longest time, and I'd groan about writing things in C++. Now I'm somewhat close to that being a reality and I'm just comfy enough to not look back. It's fast, the stdlib is amazing (in fact I challenged myself to only use stdlib this year and it was pretty awesome), and I don't feel like I'm re-tooling all the time to keep up with the new guys from the last round of hiring, or chasing bugs in abandoned dependencies.

I'd say that the one shortcoming is that making GUI apps is no walk through the park like it was in the VB days, or the tcl/tk days, but it is making significant strides in the form of Fyne, which is a great project with a charismatic team who is working toward making it pretty damn easy to make GUI apps in Go.

One of my latest interests has been using Go's web side to use the browser as my GUI, meaning you can write web apps with it and sweet jesus it's fast.

Just my 2 cents, hope you find your way with the new job.

[deleted]
(comment deleted)
mettamage
I'm currently looking at this question for my own projects ;-)

When it comes to a job, I care less about absolute productivity and more about relative productivity, salary, people, culture, location (not in that order). But when it's me, myself and I, then focusing on having a language that I can be amazingly productive in becomes a much bigger priority. I remember Paul Graham once writing an article on how he build a search engine company and was so much faster because he decided to use Lisp instead of C.

In terms of productivity, I'd like to see if I can replicate that, at least a bit.

readonthegoapp
don't understand what OP is saying.

you hate your job so...you're quitting the industry, but you're still curious what people like to use for their API work?

mettamage
I don’t hate my job. My contract didn’t get extended twice because of culture fit issues (e.g. me taking 1 hour to question the business model and improving it — since I am not a business person that’s not my place).

A job in programming != programming your own project(s)

I am talking about the latter.

rampointerhater
The language you are used to is the most productive as long as it is covered by all must have libraries, those libraries are of good quality and there is enough shared wisdom on the internet.

If you are not familiar with any language in particular you shall check your priorities.

Dynamic languages like Perl, Ruby, Python and Lua are likely the most productive ones but it cannot handle complex math algorithms or business logic without a big performance penalty. Those languages are higher level layers over the C language. They are abstractions so they cannot compete. Those languages when compared to C will consume more ram, more CPU and longer code execution's time.

However many of the libraries of dynamic languages are written in C and wrapped for use in native Perl, Ruby, Python, Lua code to highly minimize the performance hit.

Java and C# are bloated and consume too much RAM, "OO obfuscation" may also be an issue. But after they have started up all the bloat they will perform very very well and have good productivity if you can deal with it.

C, C++ are the most performant but will take ages to get productive with it.

Rust is C++ in the functional paradigm.

Go is like C but slower. There is hype because concurrency is easier but most projects do not even have a legit reason to use concurrency.

For high performance desktop apps Delphi is the king of productivity.