Live data from Hacker News

Ask HN: When has switching the language/framework made an important difference?

news.ycombinator.com

121–130 of 152 posts

Re: Ask HN: When has switching the language/framework made an important difference?

#121

Earlier quoted context omitted.

This is correct, and is sometimes necessary, but is a last-ditch save, since as written, it involves a branch. Much better if you can let the n+7 expand to a wider integer type. Or better yet, if you can ensure that it won't overflow in the first place -- which is what they did by restricting the type.

My x86-assembly has become very rusty, but couldn't it work like this, not using a branch: (with eax being the unsigned 32-bit input word) xor ebx, ebx test al, 7 stnz bl shr eax, 3 add eax, ebx (edit: replaced a movzx with an xor)

My assembly is probably worse than yours: and that is why I weaseled with "as written". I expect good compiler -- such as the ones we use every day will get this right.

But clever compiler still give me the willies, with their less-than-literal interpretations of the meaning of what I wrote.

I prefer code that is efficient good (whether that means fast, or something else appropriate to the circumstance) when taken literally, and then trust trust the compiler to smooth over my naivity about what efficiency really means.

Re: Ask HN: When has switching the language/framework made an important difference?

#122
At work, our first success in this vein was migrating a Python Twisted service to Go. Due to the critical nature of this service, we strove for feature parity. We ended up with a mostly Go-like code base, but it was very similar to the original code base in basic structure. Most of the improvements we got were due to the language choice, not due to a better design.

Our main concern is concurrency, and for that Go excels. Additionally, post re-write, that code base is easier to follow, easier to extend and maintain, easier to deploy, easier to control lower level aspects, and much, much more performant. It was years ago at this point, but I believe our improvement was something like 120x.

Since then, at work, we've moved to Go as our main language for services. This has provided even more wins as we continue to move legacy Perl/AnyEvent code over. With new rewrites (and new projects), we are taking the opportunity to also redesign systems, enabling our software to scale even further. We have lots more to do and we are hiring :)

Re: Ask HN: When has switching the language/framework made an important difference?

#123
post #118
post #78

Earlier quoted context omitted.

Is the Django-websockets story ok now?

Not really. There is the "channels" project which brings it closer to proper websocket capabilities, but it still isn't great to work with. I tried using it for a production project and gave up as I encountered too many issues. Ended up rewriting the app in phoenix as we needed really solid websocket support. Phoenix makes websocket seriously nice to work with and we've found the performance to be quite impressive.

That's nice to hear. I'm trying https://github.com/olahol/melody in a smallish project right now, and it seems very promising.

Re: Ask HN: When has switching the language/framework made an important difference?

#124
post #83

Earlier quoted context omitted.

The problem of old languages like perl and Ada is not lack of libraries, but lack of good developers that know how to write idiomatic code. Performing caching at the application level is so trivial in Perl that I do not see how a caching at ORM level could give any benefit.

And lack of employers that want to pay for such developers. Hence everything is being rewritten to Java(Script) and PHP.

Well I don't blame employers who don't want to invest in a dead language.

In Python land I am still happily getting offers with good salaries.

Re: Ask HN: When has switching the language/framework made an important difference?

#125
post #92

Earlier quoted context omitted.

Would you be able to recommend any Vue tutorials/resources/projects you found useful while learning?

I agree with the comment sibling recommending the docs -- they are good. maybe try building something with nuxt[1] first. nuxt a framework/static site generator build on top of vue (inspired by next.js for react). its conventions are easy to pick up. I find nuxt eliminates all the boilerplate and middleware I would normally have to write for a vue app with SSR (especially since vue-cli really only has a good client-s…

Made my personal website with nuxt. The tools are excellent -- it was so easy to integrate PostCSS, Pug, and TypeScript into the site.

Re: Ask HN: When has switching the language/framework made an important difference?

#126
post #44
post #38

Earlier quoted context omitted.

I want to explicitly call out an important point here. They inherited the original codebase and were able to understand the domain problems and what the original solution got wrong AND what it got right. Pretty much any language or framework they chose to rewrite the application in should have seen similar benefits (even if rewritten in Java). I've seen several projects where a rewrite was given to a entirely new tea…

Often, it's politically possible to achieve a complete rewrite by switching to another language, while staying in the same language would cause pressure to reuse parts of the old system or refactor the old system. Which is a bit sad.

That's a good point - a could top level comment could be:

"We switched from x to y. It was important because it justified rewriting the thing, which improved performance. Would have loved to rewrite it in x, but support just wasn't there."

Re: Ask HN: When has switching the language/framework made an important difference?

#127
post #100

Earlier quoted context omitted.

My big problem with Fortran is finding a modern tutorial written for an audience that doesn't already know some previous version of Fortran.

That's a fair criticism. One of the disadvantages of Fortran is that it caters to a very non-sexy segment of the programming population, by that I mean that UX/UI is not of great concern - a lot of learning materials I come across reflect that. Unless you find a textbook, you'll probably end up looking through undergraduate/graduate engineering lectures, or some presentation from a national lab (see below). First que…

I clicked on your first link out of curiosity and see that it's for F90/95. My first reaction was to wonder whether it would cover the object-oriented paradigm and IEEE floats added in later standards, but then I realized that this is a manifestation of the problem: lecture slides from 2014 that fail to cover even F03.

>First question, do you have access to a compiler?

Sure do. In fact I managed to fumble my way through writing a program to parameterize away piston-engined aircraft performance into an iterative solver a few years ago, but the lack of good/comprehensible language reference materials made trying to decipher the arcane incantations needed to do robust file I/O or divide the program into multiple source files, etc. into a very frustrating experience.

It was the last time I touched Fortran.

I'm surprised nobody has sat down and said "All right, if we want people to use Fortran outside of legacy codebases, we really need to polish the language introduction and put out a modern getting started guide to writing idiomatic Fortran in $current_year."

Because if they don't want new people to learn and use Fortran, why are they bothering to update the standard?

Re: Ask HN: When has switching the language/framework made an important difference?

#128

Earlier quoted context omitted.

All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. And all are worse performance-wise. Julia is regarded as the modern replacement for Fortran, but it isn't quite there yet. The major problem with Fortran is that there is (sadly) nearly no documentation on modern idioms, and occasionally you have to dive…

> All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. There is some C++ code that is very bad out there but most C++ code maintained by normal people is passable. When I use it I use it as C with references. > And all are worse performance-wise. You are incorrect just by the facts of the situation [0][1][…

is gfortran that much slower than Intel's compiler that they didn't bother to benchmark it?

Re: Ask HN: When has switching the language/framework made an important difference?

#129
Moving from Ruby to both Elixir and JavaScript (node) strongly improved developer productivity, performance, and time to release.

Ruby/Rails isn’t bad as such, but it’s slow and promotes a very convoluted & interdependent monolith by default.

Very happy with the change.

Re: Ask HN: When has switching the language/framework made an important difference?

#130
post #49

Earlier quoted context omitted.

Oh man I would love to work with Scala

I would not recommend Scala anymore unless you're a small team with smart devs eager to learn it. My project is not so small, and the average developer is not interested in spending the time to really learn the language and functional style. So in the end, we have code that not everyone reads and writes well, an ecosystem that is years behind Java, and tons of incompatibilities between Scala versions as it's still no…

This was not my experience. Of course you need a team that has the drive to learn the language, whatever it is.

If you go out on your own and decide to build your project with Scala and a big focus on using a functional style but no one else is following, you are going to have a bad time.

I'd like to know what are your issues with Scala and versions because we don't have these. IMHO, Scala is years ahead of Java and it's possibly so different that comparing them does not even make sense.

The transition from Java to Scala is awkward because you can do most of the things you do with Java in Scala. With that said, I think it's counter productive to do it. Scala is very different and approaching it with an imperative Java (even an OO) style is the worst thing to do.

One thing that I realized is that some people can go off and write cryptic code in Scala, very easily. This is true of other languages as well but in Scala, you can do a lot of things that will make you regret it the next time you try to read the code.

Post reply on HN