“No, we’re telling everyone we are using Java”

https://twitter.com/joeerl/status/1104298407231922176

by tosh • 7 years ago

400 368 7 years ago

Joe-Z2• 7 years ago

Why would he even ask "can we tell people?" Is keeping the programming languages your company uses a secret something people assume by default?

Now I just feel stupid for working mostly in Java. (It's handy and it works. Leave me alone, okay!)

jaabe2• 7 years ago

We keep a large part of our stack secret. Not for competitive reasons, but because people around here assumes the only two “serious” programming languages are JAVA and C#.

We did use C# for two decades so it’s not completely a lie when we tell people it’s our main language, but it’s still a little silly to lie about it.

minton• 7 years ago

It is the same way in my industry. C#, Java, MSSQL are “good” because executives have heard of them. Whereas Ruby, Elixir, Postgres, etc are “toys” because they’ve never heard of them.

fetbaffe• 7 years ago

Language snobbism is the worst.

Redoubts• 7 years ago

But what if I want to work in $boring_sector using $cool_stack, how do I find you?

ams61103• 7 years ago

Early C# and contemporaneous Java were virtually copy-and-paste identical. Even today I would put them in the same bucket when classifying languages. Though I haven't used either in many years.

sokoloff• 7 years ago

He would ask if he could tell people in order to preserve his position as a trusted expert and trustworthy "front man" of Erlang.

Suppose he didn't ask and just blabbed away? The trust he's developed over the years would be substantially marred. ("Don't tell Joe anything you don't want to show up on Twitter...")

Do I think keeping your tech stack secret is super important or that that secrecy itself is a competitive advantage? Hell no! Do I think it's still your call to decide what you disclose publicly? Of course.

Joe-Z2• 7 years ago

Thank you for your answer. I didn‘t know his role, so for me it was just „some programming guy“.

matt2000• 7 years ago

Don't feel stupid, I like Java too! Java is a memory safe language with a great standard library and amazing language stability that runs on all platforms and beats almost all other languages on performance. Seems pretty good to me!

HN is a very skewed place that's into some very niche stuff. That can be fine, it's good to be interested in new things, but no one should draw too many conclusions from trends we see on here.

Just to poke a few HN bears by way of example:

* Rust will never see widespread adoption. It's just hard and complicated, so seems cool and exclusive. * Lisp isn't gonna happen either, and that's because it's not even a good choice for most problems. It just feels really really cool when you write something in a purely functional way and so you imagine that _must_ mean this is some higher plane of existence. Not really, we've had 30-40 years for this thing to take off, not happening. * Even Erlang, while really cool, is just a super niche thing. If you're making a huge messaging service then definitely go for it, but you're making a website? Choose pretty much anything else.

There's a lot of reasons for all of the above (low average amount of experience leading to long term memory loss for the industry being the big one), but this comment is too long already and everyone's just going to be mad about the Rust stuff anyway.

ulkesh6• 7 years ago

I adore Java! It has been a skill I’ve used at a few jobs now and I wouldn’t want to do anything else. If people get upset about your opinions, then that’s their problem.

reikonomusha• 7 years ago

Common Lisp currently isn’t so great for purely functional programming. The language has the equivalent of GOTO, imperative loops, mutable objects, etc. But work is being done to make it a better functional language.

pjc50• 7 years ago

Lisp is definitely not going to happen, but given the ongoing expansion of C++ to (to me) unlearnably huge levels I think Rust will find a substantial niche in embedded and HPC systems, not to mention Firefox.

For "just write a thing that works" I've come to really prefer C# for desktop apps and Python for small things.

ams61103• 7 years ago

Can you as a Java developer tell me why it is then that every time I have a problem on a Linux machine with OOM killer randomly terminating things and general performance problems it always traces back to someone's Java program. Why does Java have a reputation as a memory and resource pig?

ufmace• 7 years ago

I'd agree that Java gets maybe too much hate in hacker communities. Java is fine IMO, if maybe a little boring. Not terribly useful for exploring cool new language design theories, but just the thing for writing a Line Of Business app that can get useful stuff done and not require updates and security patches every month. I've never written cross-platform GUI apps in Java myself, but it seems like it's probably the least-bad way I know of to write cross-platform desktop applications that share most of their code.

Mostly agree on the other points. I do like Rust, but it's still young, and many potential areas of use just don't have mature library support with lots of features yet. And some of the community enthusiasm does get over the top - I'm sure not holding my breath for rewrite everything in Rust crowd's wishes to come true, no matter how bad memory misuse bugs have been - including the Linux kernel and the universe of GNU utils.

yumraj• 7 years ago

I have worked in numerous languages, all the way from C, C++ to Java, C#, JavaScript, Python, and some go and Elixir. And, one thing I have noted is that Java programmers are the most conservative when it comes to picking, learning, using other languages.

Part of the reason is that if you're in the Java ecosystem, you can be very comfortable as it gives good performance, great mature tooling and libraries for almost anything under the Sun - so why would you want to leave it. And, there is enough demand that you'll be reasonably employed for a long time.

Which in itself is a reasonable argument, nothing wrong with it. But, on the flip side, if you want to grow as a computer scientist/engineer it is always good to look outside and broaden your horizons.

Insanity• 7 years ago

Working in a company where a transition away from Java is happening at the moment, in favour of other languages (mainly Go, partly Python) I can confirm at least the resistance from the people who mainly did Java in their carreer, compared to people who also wrote different languages.

Of course, it might also be because people who have worked in a variety of languages are already 'used' to learning a new language.

coldtea6• 7 years ago

Why would he even ask "can we tell people?"

Because irrespective to if they want to keep their language secret or not, they might not want to be featured in Elixir's homepage, or have any of the other information they shared in a private message go public.

yawaramin4• 7 years ago

Why would he even ask "can we tell people?"

I'm not sure he did. His tweets say:

However, I can't say who it is because they asked me not to tell anyone they're using Elixir.

And:

... we don't want or competitors to have, so please keep this inquiry private.

So in fact they might have just asked him to keep it quiet without him even asking about it.

aboutruby2• 7 years ago

If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

http://paulgraham.com/avg.html

hopler5• 7 years ago

Viaweb used Lisp.

Google used python, Java, and C++

Amazon used perl and C++

Facebook used PHP!

noir_lord• 7 years ago

I think Yahoo used a lot of C++ back in the day as well.

myth20185• 7 years ago

Indeed. And reddit used Lisp, only to their regret after some time [0].

Such decisions are in fact not simply about languages in themselves. They revolve around languages, availability of libraries needed for the task in hand, community, availability of proficient programmers vs your ability to train new ones etc.

[0] https://redditblog.com/2005/12/05/on-lisp/

biesnecker2• 7 years ago

I really wish that Erlang/Elixir were strongly typed. I've blown my foot off with the "dynamic language gets us going fast and now let's scale" footgun too many times to not be afraid. Obviously big important systems are built in Erlang, but I don't think I've got the guts to do it.

bfrydl• 7 years ago

For what it's worth, while I don't really disagree, Erlang's pattern matching is very powerful and covers a lot of the same ground as static typing.

Erlang is not in my opinion a “dynamic language gets us going fast” language. It's a language specifically designed to handle large scale reliably for long periods of time.

zaphar• 7 years ago

I think Erlang and possibly Elixir get about as close as you can get to having a rock solid reliable service in a dynamic language. Largely due to the pattern matching and the emphasis on coding the happy path and letting the non-happy path crash with a supervisor restarting it and logging the crashes for later analysis.

You will get a lot of milage out the Erlang ecosystem.

dmitriid5• 7 years ago

Phillip Wadler tried to add static typing to Erlang in the 90s. He could only make it work for a subset of the language.

IIRC message passing greatly complicates things.

dev_dull• 7 years ago

Static types with message passing works great and is used in production at any company which uses Akka typed.

YorkshireSeason5• 7 years ago

The problem all extant typing systems for message passing (in particular session types) have is that they cannot really deal well with data dependent patterns of message passing. Erlang's mailbox-based message passing is especially prone to data dependent patterns of message passing.

Yes, you can add enough expressive power to the typing system to make this work (e.g. dependent types), but then it stops being pragmatically viable, as far as we know in 2019.

sacado2• 7 years ago

Erlang's niche is distributed systems anyway, an area where static typing is at odds more often than not. I mean, you can guarantee the executable you are working on is exempt of typing errors, but it's just a small component of the overall architecture. What about data you are receiving? What if some remote client is using an older version of your software? What if the web service you are calling changed its API recently?

I use Elm, which is as statically-typed as possible for a client webapp, but I know I can never guarantee that JSON data I receive from remote servers is of the expected type.

mcintyre1994• 7 years ago

I find static typing is extremely useful in the case where you're receiving JSON though - I write the server side and we use Scala. For us we write the type we expect, validate the input as soon as it hits the server (in the controller), fail immediately if it doesn't validate and if it does validate then we're dealing with that type in all the rest of the code. Obviously that's not going to handle receiving a shape of data that you don't expect, but you'll error immediately and I find it really robust in practice.

skybrian• 7 years ago

This seems like an overstatement since protobufs (for example) are a widely used way of describing a common data format for distributed systems and they do support static types. Though, common practice is to make all fields optional.

Types can also be very useful for security, to keep track of which runtime safety checks need to be done. For example, you can have a separate type for HTML strings that can be rendered without escaping.

SamWhited• 7 years ago

Erlang's niche is distributed systems anyway, an area where static typing is at odds more often than not.

I've worked on a lot of distributed systems, and I don't see what this has to do with anything. Yes, static typing doesn't prevent you from doing any of the things you mentioned like changing your API out from under someone, but it's not supposed to. It Does however prevent certain classes of mistake in the individual service or executable, which is still a laudable goal in and of itself. It's not a silver bullet, but it's no less useful in distributed systems than it is anywhere else.

Also, are we talking about strong typing or static typing? The OP said one thing and this reply says another. Either way, both are nice in distributed systems too.

Ericson2314• 7 years ago

This is rediculous. If I'm dealing with something that completely terminates quickly, like the Python in Meson or Nix in Nixpkgs, maybe I can get away with not having static types and still get work done.

If I'm dealing with some complex long-lived distributed system, I don't have time for the bullshit errors no static type checking allows. I'm already waist-deep with real problems!

Also if you control the client and the server, do not just blindly follow Postel's law and except crappy data. Be rigid and lo, and behold, one side quickly excises all the bugs in the other.

koolba• 7 years ago

Static typing with uncontrolled input, whether user input or distributed systems running multiple versions, is handled via "Don't trust, verify!". Structures and inputs are validated at the ingress so that the rest of the code of you application can rely on static type checks. If the validation fails the entire request can be immediately rejected.

aero1423• 7 years ago

I've come to believe that modern type systems are not primarily about types. They are mostly useful static code analysers. Sometimes you can use them to optimize the machine code generated by the compiler, but they are much more about enforcing constraints at compile time on the abstractions we build in code. System boundaries in distributed systems are just places where you have to declare and dynamically validate what other systems send in. Validating how you use those inputs according to your declared constraints at compile time is still very useful.

lugg3• 7 years ago

The guts or the discipline?

Dynamic doesn't really cause problems in its own. Only abuse of it which can be said about most things.

I guess there is an argument that f forces you to have good habits but that comes at a pretty big cost if your team is half decent.

Someone1234• 7 years ago

"Just write good code" or "Just hire perfect programmers" the go to retort for any language weakness. I've been in this industry long enough to just roll my eyes every time I hear that now, it simply doesn't scale beyond one individual.

biesnecker2• 7 years ago

My team might be half decent. So might the dozens of other teams working on the code base over years and years. Everyone will certainly have the best of intentions. But mistakes will certainly be made. Misunderstandings will occur.

Note I said "now let's scale" -- it's pretty easy to rely on good practices and a steady hand when it's a dozen engineers in a room. When it's a thousand engineers in three timezones it's a fair bit harder.

Edit: typo

rdtsc• 7 years ago

It had type specification for years: https://learnyousomeerlang.com/dialyzer

They are opt in of course, but have the property that the more specifications you add and the more precise they are, the more type errors they'd discover. After it run it tells you if there is a type discrepancy. If it can't decide it doesn't say anything.

The technical term for that is "success typing" http://www.it.uu.se/research/group/hipe/papers/succ_types.pd...

convolvatron• 7 years ago

is this exactly the same as 'soft types' (http://wiki.c2.com/?SoftTyping) or subtly different?

tniemi• 7 years ago

Isn't Erlang the language that you can edit/patch while it is executing? I think hard typing would be extremely difficult in that kind of environment.

abstractbeliefs• 7 years ago

It is, but you can still running static analysis tools on written code before executing a code switch. The key thing is that you track the changes applied so you understand what's happening.

The nice thing about erlang though is that the nature of the message passing interface and pattern matching means that you can get relatively understandable interfaces.

koala_man5• 7 years ago

Someone should correct me if I'm wrong, but I don't think that this is a special feature of Erlang.

It's done by writing your handlers to accept a closure to use for future requests. It's not inherently different from doing this in Java:

  if (req.isUpdate()) {
    handler = Class.forName(req.getUpdateName()).newInstance();
  } else {
    handler.handle(req);
  }

It's way easier when you have message passing and every level is set up to restart on crashes, but I don't think anything necessarily stops you from doing the same in any other language.

mercer3• 7 years ago

I suppose the 'Let it crash' characteristic of the BEAM kind of compensates for a lack of a strongly typed approach, if the concern is stability and being able to stay up despite triggering a bug.

dmitriid5• 7 years ago

I’ve heard the same “we don’t tell people we use Erlang because it gives us such an advantage” ~10 years ago.

Yup, those companies moved a lot of their business to Java, and C#, and Go, and even Ruby.

cuddlecake2• 7 years ago

Citation needed

wbl• 7 years ago

Even the ones writing telephone switches?

dmitriid5• 7 years ago

There are very few companies developing telephone switches. Ericsson famously ditched Erlang in the late 90s, and as I hear there's very little Erlang remaining there.

Can't say about other companies.

Cisco uses Erlang in the control plane apparently [1]

[1] https://twitter.com/guieevc/status/1002494428748140544

dfox• 7 years ago

Relation of Erlang to telco switching is somewhat opposite than what most people believe. Ericsson's stored program switches do not run on Erlang, but use execution model enforced by hardware that undeniably was inspiration for Erlang.

Other manufacturers used either some traditional mix of C(++) and assembly or got on the CCITT/ITU bandwagon of CHILL ("CCITT High Level Language"), which is combination of C/BLISS style low level execution model with Algol/Pascal syntax and COBOL-like verbosity with some extent of native support for threading and coroutines.

vikingcaffiene3• 7 years ago

Elixir is one of those languages that changes you. I realize its a ruby flavored wrapper on top of erlang but I don't care. Coming from an OOP/C based language background, it took me a while to get it. Implicit returns? Immutable data? Pipes?? No inheritance??? No for loops????? And all thats just if you use the phoenix framework which maps pretty analogously back to a standard web server flow. Once you start digging into Supervisors and umbrella projects, the top of your head will get blown clean off. It's a hell of a drug.

I am glad to hear there are more companies out there giving it a try. Any time I see a job posting for a company that uses it, I give them a hard look. It tells me that they are a) hiring people who are of a certain mindset (see the python paradox[0]) and b) they understand the competitive advantage that using a language like Elixir can bring to the table.

[0] http://paulgraham.com/pypar.html

richk449• 7 years ago

Funny how that pg post has aged. Now python is the language you learn if you want to get a job.

What’s the new python?

johan_larson• 7 years ago

Rust, maybe. I'm not particularly leading edge myself, so I've heard of it but never actually tried it.

tosh• 7 years ago

Rust, ClojureScript, Clojure, Racket, Elixir, Elm, Reason, OCaml, Haskell

fkrkgkvodkskd• 7 years ago

JavaScript.

rad_gruchalski8• 7 years ago

golang

peteforde2• 7 years ago

I'm a Ruby guy and I'd love to feel what you're feeling. Where should I start / what should I check out? Bonus points for concept walkthroughs and materials designed to bring Ruby folks up to speed, specifically concepts that need to be temporarily forgotten or unlearned in order not to get sad.

I like being a polyglot, but my schedule is tight enough that I need to hit the ground running or else I get pulled back to reality pretty quickly. There's a lot of posts and videos out there on Elixir, so curators are incredibly awesome in my world.

whizzkid3• 7 years ago

Start here --> https://elixir-lang.org/getting-started/introduction.html

You will start feeling the magic around chapter 4 with pattern matching and the rest gets just better :)

Try not to migrate your "how to .." thoughts from other languages into Elixir. It has some uniqe ways to solve everyday problems.

Have your interactive elixir console ready to play with as well, good luck!

whalesalad• 7 years ago

Highly recommend this: https://codestool.coding-gnome.com/courses/elixir-for-progra...

I think it's probably the best way for an experienced programmer to get up to speed on idiomatic Elixir, why you do certain things, etc...

jypepin• 7 years ago

I'm kind of a ruby guy, and I started with the elixir intro from their website. Very clear and well documented. Then I built a website using Phoenix and learnt through that.

Docs in elixir are first class citizen, so everything is very well documented. And just like in ruby/rails land, any question you may google will return a lot of high quality posts with answers!

w0rd-driven• 7 years ago

The official docs for Elixir or Phoenix framework go a long way. One thing that sticks out above the rest for me is Elixir koans[0]. They’re extremely rudimentary but I think the project showcases Elixir’s hot reloading if I’m not mistaken and it’s very fluid. Other follow along courses may have taken this approach but I was extremely impressed by how everything fits together.

[0] https://github.com/elixirkoans/elixir-koans

honkycat• 7 years ago

Elixir in Action from Manning, and all of the PragProg books are great

vikingcaffiene3• 7 years ago

"The gateway drug" IMO is the Phoenix framework. It models cleanly to much of what you already know as a Ruby dev. The creator, Chris McCord wrote a book [0] for it that is one of the most well written programming books that I've come across. Chris does a fantastic job of making the information accessible and understandable. You learn by building an app of substance and apply all the concepts that make phoenix a wonderful web framework to use. Towards the end, Chris starts easing you into some of the more "hardcore" concepts and gives you the opportunity to use them on the project you are building throughout the book. That level of quality just seems to permeate the ecosystem as a whole. Others on here have made the point that the waters might start getting muddied as it gets more popular but I've had nothing but great experiences so far and would love to see it really take off.

[0] https://www.amazon.com/Programming-Phoenix-1-4-Productive-Re...

mercer3• 7 years ago

I found the Programming Phoenix book to be quite nice because it similar to Hartl's Rails tutorial. Seeing where and how the two differed was very useful.

wolco• 7 years ago

No loops? That can be life changing.

Jtsummers• 7 years ago

I don't know Elixir, but I do know Erlang (one of Elixir's inspirations). The lack of loops is replaced by recursion or higher level functions. Tail calls (all, not just recursive) are optimized so that you don't blow the stack. Since the two (iteration and recursion) are easily transformed into the other, it's a pretty clean mode of coding.

tim333• 7 years ago

You can sort of loop in Elixir eg.

Enum.map(1..100, &IO.puts/1)

prints the numbers 1 to 100

derefr• 7 years ago

If you’re wondering: Erlang (and so Elixir) has a very “pragmatic” design behind its abstract machine/runtime; it’s not like the lack of loops is to be functionally pure or anything.

They remove loops in the Erlang abstract machine so that there are only ever O(1) instructions executed between each function call (where a tail-recursion is considered a function call.) With this constraint in place, the runtime can get away with a hybrid of cooperative and preemptive scheduling called “reduction scheduling”, where functions only ever yield when they make a function call (or return from one.)

By ensuring every function body has O(1) “reductions” before it hits a CALL or RET op, the runtime guarantees (unlike cooperative scheduling) that execution will always yield from a task in a bounded amount of time; and by ensuring yields only happen at call-sites, the runtime ensures that (unlike preemptive scheduling) there is no register state to preserve at time of yield—all the scheduler has to record when it pauses a task is the thunk (function pointer + parameter list) for the call it was about to make.

Together, these guarantees allow for extremely low-overhead context switching between tasks in a soft-realtime context.

Other systems (e.g. .NET’s Orleans) simulate this hybrid approach by splitting code into state machines with explicit yield points being the state transitions. But AFAIK, only ERTS takes the approach of making function calls into the state transitions. (Because, without the no-native-loops constraint, such an approach doesn’t work at all.)

rad_gruchalski8• 7 years ago

Recursion is the way to go in Erlang / Elixir: https://learnyousomeerlang.com/recursion When one writes a bit if Erlang for a while, one gets a completely different view on any software to be written in the future. Erlang is life changing. But there are things where other technologies are better fit.

kbp2• 7 years ago

No loops? That can be life changing.

I doubt it would be for someone from a Ruby background, where higher order functions already generally replace built-in loops.

ashleyn• 7 years ago

As someone who's done a bit of Rust, I'm starting to see its influences just reading that list of features.

Retra• 7 years ago

It looks to me like Elixir is just doing the same things most other functional languages are doing.

macintux10• 7 years ago

The language itself is a fairly typical FP, but only if you disregard the VM it runs on and the OTP framework.

As I've frequently said about Erlang, the language is much more powerful than the sum of its parts. There are a great deal of complementary features in the stack.

bitwalker4• 7 years ago

It is really the BEAM that is most compelling, Elixir is a great language on top of it, but the VM provides tools that simply don't exist in most other languages, if any. Specifically things like runtime tracing with pattern matching, the ability to connect an interactive remote shell to a running system and poke at it using code, ETS/Mnesia, hot upgrades/downgrades, etc.

dpflan2• 7 years ago

When/how can a company assess that using a particular language is a "competitive advantage"? It seems that the competitive advantage is perhaps in hiring the people who are actually proficient in the language -- and the advantage arises when that language is one that has X, Y, Z paradigms and is designed for A, B, C use cases, and then is used appropriately.

https://twitter.com/devoncestes/status/1104000439987683328

lazyant• 7 years ago

yes, I'd say if a language fits the product for some reason then it's an advantage, but a "competitive advantage" sounds like a stretch. If it's a niche language you want to attract the programmers in a smaller pool so you may as well advertise it.

whizzkid3• 7 years ago

I am not advocating for the company but it might be something like this;

Handling of same amount of users comparing to their competitors with a software stack that requires %70 less employees to run will give them enough room to lower their product price comparing to others. Imagine If they can keep it this way X number of years, then they will be able to eliminate their competition.

elcritch• 7 years ago

Not just the cost, but often the complexity reduction in team communication overhead can mean improvements in the ability to add features and services quickly. Financial arenas deal with a lot of events that need to be processed quickly with complex data transformation requirements that change quarterly in many cases.

Consultant32452• 7 years ago

Minimizing costs like this is most important for commodity software with lots of similar competitors. I think the real answer will vary greatly from company to company and market to market. Generally, I would recommend companies be careful to not think they're all that special. Special companies/products/markets may require special tools, but 99% of companies should pick the most mainstream tools available: Java, .net, c/c++, etc.

hopler5• 7 years ago

Developer maintence time is not the marginal cost/priced of software. Software has low marginal cost to the economics is all about scaling up sales, and your tech stack is mostly binary: the job is either possible or impossible. developer cost within a factor of 10x is irrelevant.

mwkaufma2• 7 years ago

"I was in a hipster coffee shop, and all the liberal young people were whispering about how much they actually love Haskell."

mwkaufma2• 7 years ago

Real talk: mere hours after posting this dumb joke, we went to Copa Vida in Pasadena, unknowingly during the SCALE 17X Linux Conference, and it _actually happened_ O__o

iiiggglll• 7 years ago

One of the perl guys (maybe Larry Wall?) said the same thing at a talk once about companies using perl but not wanting anyone to know it because it was a such a time saver they considered it a competitive advantage.

snaky2• 7 years ago

That's still the same about Perl, but for different reasons now.

While the rest of the world sees Perl as a legacy language and analysts insist that no one is talking about it, our Perl business is vibrant, alive, and growing. Leading companies such as Amazon, Boeing, and Cisco continue to demand Perl skills in their developers while Booking.com is investing in Perl as its core development language. How can this be explained?
This is the Perl Paradox. No one is interested in talking about one of the most influential modern programming languages yet it continues to thrive under the radar.

https://www.activestate.com/resources/webinars/perl-paradox/

guitarbill3• 7 years ago

continue to demand Perl skills in their developers while Booking.com is investing in Perl as its core development language. How can this be explained?

It's simple: because rewriting it doesn't make business sense. But from having talked to Booking.com devs, I don't get the impression it's something they'd recommend for new projects.

So while some businesses build on Perl might be "growing", is this because of Perl, despite Perl, or doesn't matter? The success of a business says nothing about the ecosystem surrounding the language they are using (unless they get so big they can shape it). A far better proxy for language health is how easy it is to hire a team of competent <language> programmers at all skill levels - by which I mean veterans with enough varied experience, and college graduates who'll consider programming in <language> without a bigger paycheck. (The ultimate metric would factor in turn over due to dissatisfaction/burn out from tech debt.)

For what it's worth, I still love `perl` for one-liners, because it's far more consistent than the various GNU and BSD versions of `sed`/`awk`/`grep`. But I'd rather be programming something else, and I'd rather be deploying something else, given that consistent deployments are possible now with language-agnostic tools like docker. So a big advantage Perl had is gone.

sedachv3• 7 years ago

How can this be explained?

I have a much simpler explanation. Publishers and conference organizers like O'Reilly eventually saturate the market for Perl books and conferences (books especially, because used books start to cannibalize their sales), so they move on to promoting a different, new language, so that even their existing customers will have to buy the new books and pay hundreds/thousands of dollars to attend conferences for the new thing.

hopler5• 7 years ago

For major soft dev projects, Amazon deprecated Perl 12years ago when they moved to java for retail website development, and uses it for maintenance of too-big-to-fail legacy parts of the retail website.

rocgf• 7 years ago

I worked at Booking.com for a while, though never in Perl directly.

Take this with the grain of salt of any personal anecdote on the Internet, but I can definitely say that Perl is not loved there. Most people hated it deeply, some of them were like "it's not horrible...".

They are now allowing Java as well for the newer project, and they will have Java and Perl as 'blessed' languages moving forward. I don't really believe that they are doubling down on Perl in any sense of the word, they're just doing what any other company with a huge amount of code written in a dying language would.

zbentley• 7 years ago

I programmed in Perl (5) in a large enterprise environment for five years. On a huge, monolithic codebase, with people who were innovating with the language in interesting ways. The business environment was restrictive (healthcare), but the amount of people leveraging Perl's flexibility to build powerful, flexible tools to enable faster development on the codebase at scale was startlingly high. A large proportion of developers engaged at every level, from XS to MOP (we used a modified version/fork of Moose) to distributed computing (we used a home-rolled queue worker solution, think Celery for Perl, but without the AnyEvent cancer), and novel web frameworks on the frontend, some of which were put back out on CPAN.

Basically anyone who wanted to be productive there demonstrated an impressively innovative, cross-cutting skillset that combined deep knowledge of UNIX technologies, the particulars of the application, and an incredibly expert language of the particulars of the language itself.

And honestly?

It sucked.

A lot.

I won't say this about any other platform--not modern security-vuln-in-the-package-manager-every-two-weeks JS, not "do you mean actually cross-platform or relying-on-compiler-UB cross-platform?" C, not the worst old-layered-on-new-layered-on-old-again PHP, but: Perl as a platform on which to build something non-tiny, or something that requires more than a small handful of developers, is unutterably awful. And I say that as someone that got pretty good at it, I think.

At the micro level, TIMTOWDI confuses newcomers, makes code review inconsistent, and means that as soon as someone feels fluent and productive on the codebase, then they have to engage with someone else's code, and they get stuck all over again. This means that mentorship is a complete bastard, and developer progression is incredibly hard to gauge, teams form fiefdoms (even in the face of huge linting tools; things that make an ultra locked-down JS/TS project look paltry by comparison--even for off-to-the-side greenfield projects) and can't transfer developers, you name it. Perl at any sort of scale is worse than the quoted "write-only" slogan: it's "write-once, re-learn from scratch on read". For a junior dev, rewriting would be a blessing.

At the medium (between micro and macro) level, the metaprogramming abilities of Perl just . . . fuck everyone up, no matter what they want to do. Want to get your work done in as straightforward and repetitive a style as possible? Welp, no matter how simple the task, and how straightforward-looking the utilities for it might be (on CPAN or in house), they won't interoperate for shit. Want to reduce boilerplate and ease the pain of common tasks by encapsulating (or, god forbid, applying metaprogramming) to speed up some process? No problem, first-class laws-of-the-universe-altering facilities are available to everyone--to get your change functional, you'll just have to interoperate with . . . well, everyone (some of whom wrote third party modules, and aren't people you can ask nicely for help). Object systems will fight with message queue clients for control over how calling nonexistent methods on arbitrary objects that neither one created should work (you thought Ruby's method_missing was a foot gun? Ha!). A tool for printing console logs will override the alarm(2) hooks used by your main HTTP client, meaning that if someone leaves a debug print in the wrong place, HTTP connections to a down endpoint will start blocking forever and kill you. Can this happen in other languages? Sure! Python, Ruby, and PHP (to some extent) all allow the same flexibility and low-level access. But only Perl makes this the default convention* to follow. I've heard people say "Perl programmers are just C programmers who couldn't hack it, but still want to write C". There's a grain of truth to that. Problem is, those aren't the kind of people I want to share a codebase with.

At the large (5MMSLOC+ codebase) level, Perl's an operational nightmare. Thanks to all the ways that libraries can customize the language, it has the metastasized version of most other interpreted scripting languages' problems when it comes to compilation phase and memory, namely: "what happens when I have to compile a huge dependency graph on startup? Can I cache those things in some sort of intermediately usable format or do I have to wait many minutes to start a test script? Can I fork? When I fork, what gets shared? Just filehandles opened by the application? Or random shit inside libraries too (and are compiled dependencies encouraged to make their IO resources' lifecycles manageable by the outer runtime)? Will my box crash due to GC-caused refcount/allocation cycles if all my forks exit at once?" These aren't unique to Perl, but I think they're worse in it than any other language. Oh, and that's without getting into the insane degree of mutability Perl permits. It's the freedom of C without the discipline ("set environment vars any time you want! Hell, they're a first class language data structure! Oh, and change what the STD* streams point to, that's fine to. And dynamic scoping and Scope::Upper means you can't tell when something will change because some code totally unrelated to yours decided it should!"). When trying to handle requests or do anything "nested" (terminate SSL, alter things that would go on e.g. "Context" in now-unpopular Go idiom), Perl's conventional answer is just "dynamically overwrite globals!" In general, this means that it doesn't matter in what context you tested your code in, it'll do something different at runtime because a) if it does anything interesting it depends on global-ish state, and b) other random code can rewrite SIBLING global state whenever it wants (think Python, but if the convention were for any coder that got stumped about how to pass data around to just modify globals/locals/vars willy-nilly). Again, a risk in most environments, only actively encouraged in Perl.

I promise that wall of text isn't just specific-employer PTSD. I've been through CPAN code, negotiated with package maintainers, gone to conferences, tried to get a sense of how people are contextualizing these problems. And the impression I came away with is that the vast majority of the entire Perl ecosystem--from the practices understood to be desirable by programmers to the behavior of existing/hardened/public code--is overwhelmingly harmfully inaccurate, poorly-thought-through, and defended by the worst strain of cleverness-above-practicality (or "don't touch it, it works when you hold it just right and don't breathe" for incredibly simple requests) when challenged.

Perhaps at some point in the past this ecosystem reflected the cutting edge, but I think that time is long past. If you're making a small commandline utility or personal one-off in Perl, go nuts. I don't think you're a bad person. Just make sure it doesn't get any bigger than one developer's worth of code.

EDIT (probably the first of many, because essay): typos and grammatical fixes. Promise I won't change the substance.

* Why the hell are either of those libraries calling alarm(2)? Answer: the logger didn't realize that write(2) wasn't interruptible, and the HTTP lib author didn't realize that connect(2) took a timeout. By the way, both were in incredibly popular modules on CPAN.

Floegipoky4• 7 years ago

I recently left a job at a company with a primarily perl 5 codebase. I would never choose to use perl to start a new project. In my opinion its relevance these days is primarily legacy systems and duct tape/scripting. I still use it for hacking on small tasks, it's pretty decent for technical interviews.

jackewiehose• 7 years ago

Is it really a thing that companies keep such technical choices as a secret to seek advantage? How about even more trivial stuff like using SCRUM (or the secret approach to software development you do). Or "The secret to our success is giving free donuts to all our employees".

Do you have other real examples?

brown9-2• 7 years ago

Whatever competitive advantage there might be, such secrecy also puts you at a recruiting disadvantage.

badfrog2• 7 years ago

Not just recruiting, but there are all kinds of problems if your engineers can't have conversations about the language in public forums/meetups/etc and can't make contributions or even feature requests for the language and tools.

sidlls2• 7 years ago

Using languages and technologies that aren't relatively mainstream also puts the company at a recruiting disadvantage. It's trivial to have a full pipeline of candidates who are relatively inexpensive to hire and "good enough" within days of posting a bog-standard "Java services developer" job description.

whitexn--g28h• 7 years ago

I’ve been hiring spring boot developers, and on day one I just throw them the Phoenix guide and say “this is what we use here, learn or leave”

FunnyLookinHat• 7 years ago

I've read an equal number of horror stories to success for Erlang / Elixir. That isn't to say it's not good or useful, but that it isn't some magic bullet that solves every problem for you.

Edit - I guess my point is that it's not good enough to keep a secret. :)

FlyingSnake• 7 years ago

I've read an equal number of horror stories to success for Erlang / Elixir

Care to share them here?

Grimm1• 7 years ago

I sure haven't I'd love to see a few if you have them. Help me be better informed for choosing a language for large projects

appleflaxen• 7 years ago

Please: provide some details so that those of us looking at the pool can decide if we want to walk over.

bitwalker4• 7 years ago

I've been working in both professionally for several years now and talked with many over that time, at conferences and such, and have yet to hear "horror stories", but such stories could definitely be useful as illustrations on how _not_ to build a system in Erlang or Elixir, so you should share examples!

I _have_ seen some projects with pretty terrible code, but that has nothing to do with Erlang/Elixir, and everything to do with the skill level of the team behind the project.

nickpsecurity2• 7 years ago

friendlysock brought up a legacy project with a lot of specific problems:

https://lobste.rs/s/pcebor/choosing_elixir_for_code_not_perf...

innocentoldguy• 7 years ago

I've used Java, Erlang, and Elixir professionally and I would never go back to Java. I like being able to write code without the crutch of an IDE. I like not having to deal with JVM deployments. I also like Erlang's functional paradigm and concurrency model a lot better. I'm at least twice as productive in Erlang and Elixir, so I view the two languages as having a competitive advantage over Java.

svnpenn• 7 years ago

I tried elixir but then I realized it's just a wrapper for Erlang. It literally won't run without Erlang binary.

Stop trying to make elixir happen. It's not going to happen.

GordonS• 7 years ago

Eh? Why would it being on top of Erlang mean it can never be popular? Isn't that like saying any language on top of the JVM or CLR can never be popular?

ianleeclark2• 7 years ago

I mean, I write elixir professionally. Its kinda clearly happening

jstewartmobile• 7 years ago

I have not adopted this religion yet, but I have attended a few services.

Still too many philosophical doubts about a functional language where map and reduce only take one enumerable, and have to be prefixed with "Enum.".

At least it's not JavaScript.

jwr• 7 years ago

Back when I worked on building software for clients, I used to tell people "we run all software on the Java Virtual Machine" instead of "it's written in Clojure", because I was afraid they would get scared.

But then I noticed that nobody actually cares much about what tools you use, as long as they get the job done. The end result is what counts.

samsonradu• 7 years ago

Many times it is hard to pinpoint what/when the ‘end result’ is. So while the clients are happy now, they won’t be happy to hear they might have a hard time maintaining the project through the years. Clients will want to know they can hire people to work on the codebase.

dwaite5• 7 years ago

Unfortunately most times if an external vendor is delivering custom software the clients have already failed - software has a lifecycle that extends far beyond 1.0 delivery. This is why we still have things like X-UA-Compatible: IE=5.

cmauniada• 7 years ago

I wish I followed this advice when I was setting up lambdas on aws. There was this general distaste for "java" in the dev community. Doing a new project and this time around I am using java, and it works so beautifully. The second choice would have been python, but I like the strict type checking.

vajrabum• 7 years ago

Do you find that using the JVM in Lambda affects your cold start times? If so, do you have a pre-warm strategy and how does it work? Or maybe it doesn't matter for your application?

mrep2• 7 years ago

That is hilariously ironic considering 90% of AWS is written in Java.

peterlk• 7 years ago

This is not always true. A friend once built an application for the government (I don't remember any more specifics) in Python. He delivered it to them and mentioned in a document somewhere that it was written in python. This was unacceptable to them because python was not on the list of approved languages. So, after some negotiating, he caved, switched the project to Jython (with minimal changes) and delivered it as "running on the JVM". This was seen as acceptable, and the delivery was accepted.

giancarlostoro• 7 years ago

I wonder why that is. I know theres a list of DoD approved software licenses and guidance on using open source software but didnt know there was a list of languages allowed.

misiti3780• 7 years ago

That must have changed in the past 10 years because I was working on a DOD project in 2007 and it had a large python component.

lostlogin2• 7 years ago

I’ve seen software rejected this at a university as the IT teams (pleural) didn’t like the language it was written in. However the problem was solved by the software vendor withdrawing their quote as we were too hard to deal with.

S4M• 7 years ago

Why didn't they specify beforehand theor language choice? The negociation about Jython you describe should have taken place before the work started

zmmmmm2• 7 years ago

I still tell people we're using Java instead of Groovy, but that's more because I can't be bothered having the repeated 5 minute discussion with them about what it is. (Besides that, I actually consider Groovy almost to be essentially like a template engine or set of macros for writing Java code. It's not like other JVM languages that try to introduce a different style).

linkmotif4• 7 years ago

Groovy, the real JavaScript. I love Spock but never could get into using Groovy for non-test code.

raverbashing3• 7 years ago

But then I noticed that nobody actually cares much about what tools you use, as long as they get the job done.

Unfortunately there are a lot of cases where this matter:

- Customer requires the sw to run on their standard environment (think some version of RHEL, or some Windows Server version). Hence you're limited to what's supported there (usually from the vendor). No bleeding edge versions of Python/Node/.NET etc. You might need to build a Go or Rust binary for that specific system and it might not always be obvious. Java might be a different story, but I wouldn't risk it.

- Embedded software (for similar reasons)

- Sw that needs to run on a customer's system

- Sw that needs to interface with an existing system (loading a DLL/.so? JVM?)

marco_salvatori• 7 years ago

Yes. When a client hires a developer, he cares that he receives a proper delivery and he cares that all of the decisions related to that delivery were made in his best interests. Technology choices are an important part of building a technical vision for a company and planning for software maintenance. People may not seem to care much, but that's only because they are trusting the people they hire to care and to know better than they do. When there are any questions on technology, clients appreciate and value unbiased discussion on those choices, in the context of their business. An important part of having clients, perhaps the most important, is establishing trust and one does that with success, but also a record of transparent, appropriate project decisions.

trimbo2• 7 years ago

Back when I worked on building software for clients, I used to tell people "we run all software on the Java Virtual Machine" instead of "it's written in Clojure", because I was afraid they would get scared.

That seems... dishonest? What happens when the client wants to hire someone else in the future, only to find out it's not Java, it's actually this language which is not mainstream at all?

sethhochberg• 7 years ago

I think it would be dishonest if the agreement was that the software should be built in Java - but to me, this reads more like an operational concern. The client felt comfortable with a software package they can deploy on the JVM... but that doesn't necessarily mean they cared whether it was written in Java. If I were hiring a dev for a Java project, I'd explicitly hire a Java developer, not just someone who promised a product which would run on the JVM.

baud147258• 7 years ago

Actually, I think there are cases where the clients would care: for example with on-premise software, using either the OpenJDK or Oracle JVM will incur different costs. Idem with Oracle/SQL Server.

protomyth• 7 years ago

Remember this happening at a couple of big companies that used Smalltalk in the 90’s. It was a BS move then and now. That’s why you take with a grain of salt language popularity numbers.

stunt• 7 years ago

I don’t understand talking about programming language without context.

There is no point to discuss or compare programming languages without having the context about project, environment, scale, resources, and architecture.

davnicwil• 7 years ago

This is spot on. The same programming language / framework can provide positive, zero or negative competitive advantage depending on the usecase. If you don't have that context, this information is really rather useless on its own.

With that being said, in this example you have to imagine their competitors certainly will have that context (they'll each be building a replica of the same thing, essentially) and so the situation is different. Only hearing the language / framework they are using becomes more useful and valuable, then.

aboutruby2• 7 years ago

The context is "major financial services company". There are actually quite a few running Elixir.

exabrial• 7 years ago

Are we already on the next hype cycle?

boznz2• 7 years ago

If the client asks and I tell them I write it in Delphi, I loose the contract period, if they don't ask I generally get the contract. Been like that for last 20 years and will be for the next 20

koala_man5• 7 years ago

Is this real? If so, please elaborate.

karlakush• 7 years ago

Nobody writes Delphi so it would be difficult for the client to maintain their software if their relationship with the original author ever ended.

boznz2• 7 years ago

Its real, certainly not going in to client details though that would be pretty unprofessional.

Currently my main income is derived from a suite of software I wrote for a small winery who subsequently grew to be a very big winery. They got big enough to hire an IT team and a Manager and a consultant who basically are telling me that Delphi is ancient and my whole system is a risk to the business despite having 100% up-time for the last 10 years (Basically if their server was up the system was up). Nothing I am able to do is going to convince them otherwise and it is on the cards to replace it.

Again I will gracefully back down and support the system until it is changed so should get another 2-4 years out of it based on previous experience *

I was an IT Manager for a long time and I do understand peoples worries but I also understand that if something is working, is documented, has an open source and data structure, can be supported and doesn't have a forced end of life there is sometimes a bigger risk to making a change. Behind a lot of software is generally one guy or gal, I don't try and hide that fact and sometimes pay the price but and I know several other packages that have just one guy as the linchpin but there will be no pressure on them as they hide it behind a company.

I also have C and SQL skills which people don't find so offensive :-)

* The expenses system I wrote in the UK had the same decision made on it in 2004 to replace it with the new mega SAP R/3 ERP they were moving to and it was still being used up until 2016. A Time Management System I wrote in 2008 is still being used despite the client telling me it would be phased out in 2013 as part of a new CRM system.

jayd16• 7 years ago

If they don't ask then they don't plan on making changes to the code (even if they will, they're not _planning_ for it).

If they do ask then they are planning to make changes. If they're planning for that then it makes sense they would lean towards the most popular and easy to hire for languages.

noonespecial• 7 years ago

I loved Delphi. I still use the OSS "Lazarus" IDE for hobby projects.

But I've got enough experience with Delphi and its "VCL" libraries that I'd require a fully licensed and running VirtualBox image with your exact build environment capable of compiling the project before I'd sign off on the deliverable.

ransom15382• 7 years ago

Using Delphi is an unfair business advantage.

aero1423• 7 years ago

This whole thing reeks of the CTO selling a story to the non-technical CEO. I'm not saying it's not useful to the company, but companies build strange internal myths about obscure tech choices.

dpflan2• 7 years ago

Are those internal myths equivalent to rationalizations of the decisions? Do you have any anecdotes or know where to find some?

aero1423• 7 years ago

I call them myths because it's not important if it's literally true, just that if the executives believe it's true, then they make the right choice. For example, if you have a home grown internal tool, like a database or a messaging system, it's important that the executives believe that it is a competitive advantage for the company so they don't try to replace it. If they try to cut the maintenance of that internal tool out and switch to something cheaper, then it would probably be terrible for the company because engineering would need to rework the whole system that depends on it and it wouldn't end up being cheaper. Same with switching the language you use to Java. Sure you can hire more Java developers, but rewriting the system from scratch or splitting the codebase is probably worse, so just make sure the CEO believes Elixir is key to their success, whether it actually is or not.

Listen to Steve Jobs describe object oriented programming. I'm not sure he even knew what it was, but it worked out for the company that he sold it so well. https://www.youtube.com/watch?v=2kjtQnPqq2U

jmts• 7 years ago

Recently I was curious why so much big cloud software is written in Java. Cassandra, Kafka, and Neo4j are some examples. I don't have a lot of experience in the area myself (embedded software engineer) so I put it down the JVM providing straightforward platform independence and a consistent API, and the (assumed) simplicity deploying .jar files. This anecdote suggests it may be a less deliberate choice and that Java is just the de facto language. Does anyone have deeper insight on this this trend that they might be able to share?

My apologies for this post being a little tangential.

wmf• 7 years ago

Before Go and Rust came out, the mainstream statically-typed languages were C, C++, and Java. Java was also one of the few "modern" languages that can idiomatically use multiple cores. So yes, Java was pretty de facto.

mrath6• 7 years ago

Even now Java is pretty much defacto in many places.

Go does not scale well and it is a dumb language, not that that is bad. But just that it does not feel like a improvement to switch to Go.

Rust is still new and I think it will not get mass adoption like Java because of higher learning curve.

abernard1• 7 years ago

Performance.

The JVM is an extremely fast platform given its feature set. It also has a coherent and powerful concurrency specification that is stable. While it is possible to have very low latency systems in Java, it requires a bit more work, and people tend to gravitate to C++ if the 3x penalty from C is too high.

But aside from the latency, if you can deal with full GCs, Java is a data throughput monster. The default GC is actually very good in most cases, and the JVM GCs allow significant performance tuning, which is a discipline in its own right.

It will be interesting if the low latency Z Garbage Collector introduced in JDK11 eventually removes one of the last complaints on Java performance.

dwaite5• 7 years ago

Java has issues both with latency and memory usage due to the garbage collector and general age of the language (missing modern features like value types).

Performance is.. complex. The lack of value types causes a lot more indirection, the hotspot compiler patches away some of it, the copy collector will compress connected objects together so that they will fit 'automagically' into CPU cache.

Unoptimized Java code may often run faster than unoptimized C/C++ code, but Java gives you only vague, global flags for attempting to tune memory behavior and code generation.

For monolithic Java applications, you can have a lot of different memory patterns internally (short term objects for the web stack, medium-term objects for transactional state, plus long-term objects representing accumulated state) which can really muck with the garbage collector's assumptions around generations. For server applications, this can cause things like heavy load causing request/response short-term state to be promoted to the mature generation. You start having to break up monolithic applications for performance reasons.

But, that still is being a victim of your success - and you would be better off by default creating the first version of your application in a language that allows your developers to iterate quickly.

hodgesrm• 7 years ago

Java has a huge base of engineers familiar with it, great libraries, scales well, and has stable development tools. If it were not for some of the FUD around Oracle ownership I think at least some of the concerns about it would disappear.

It's interesting to me that people don't seem to throw shade on C++ as much even though it's even older and in many ways harder to use effectively than Java.

Gibbon12• 7 years ago

people don't seem to throw shade on C++

I hear my friends make dismayed noises about C++ any time they are forced to work on it. When I look at Java or C# code snippets I mostly feel like I understand what's going on. C++ makes me go wat?! far too often.

Personal opinion I think Java would have a better rep if they'd optimized the GC for latency instead of speed. C# on the other hand would have a vastly better rep if it wasn't a Microsoft product.

mrath6• 7 years ago

Java is a very decent language even in comparison with other modern languages. And the amount of tooling, libraries are not matched by any other. It is easier to hire good Java developers. C# is the only other languages I can think which is as much capable as Java. I was hoping for golang but IMO it is not great for anything other than small command line apps.

Macha• 7 years ago

Faster than Python/Ruby. Safer than C/C++. Sun was seen as nicer than MS. No remaining languages had as many replacement developers once you ruled the previous ones out.

Then add in two decades of entrenched software and network effects.

RivieraKid2• 7 years ago

What's the alternative? I have experience with a lot of programming languages and recently decided to use Java on the server side of a side project.

Java is fast, has amazing IDE support, large library ecosystem and it's a solid language. And yes, I stand behind the last claim, I don't understand why Java gets so much hate. Swift is the best-designed general purpose language I've used and it's not hugely better than Java.

BTW, part of the decision to use Java was that I'm very familiar with it and wanted to get started fast, but now I'm having second thoughts. I guess Kotlin would be a good choice? And maybe Swift but not sure about library ecosystem on the server.

m463• 7 years ago

I don't understand why Java gets so much hate.

I remember when java first came out, I thought it would take over the world if they would "finish it". To me, this meant letting it run like other scripting languages:

    #!/usr/bin/java

and let it do useful things everywhere in the os, but with wonderful OO.

But instead of becoming a systems language, it sort of became a "nice cobol" that was mostly adopted to do business logic. I suspect the limitations imposed on it were to ensure portability and security, but it sort of polarized the people who would or would not adopt it. It was approachable to people who didn't think pointers were necessary (or some who couldn't do pointers), and repulsive to people who didn't want these constraints.

I think over the 20 or so years that followed, the idea of what java is used for has stuck. I also think perl took up the slack on the systems side, with python.

I wonder if java had been more of a systems language from the start, would it have been unsucessful? Or would it have displaced perl/python?

dwaite5• 7 years ago

Java is sometimes considered inferior to other languages for several reasons:

Ecosystem wise: - The JVM still uses quite a bit of memory, sometimes 3-4x more memory than say Ruby or Python (which are also garbage-collected languages). There is a reason that Android phones ship with several times more system RAM than iOS devices. - The JVM is gradually becoming only suitable for server development. Client GUI development has been mostly abandoned (with applets being deprecated, no Swing improvements for years, and JavaFX no longer being an official project), and the startup time is too slow for systems development a la shell scripts - IDE support is actually more middle-of-the-road in my experience. IDEs can suffer from needing plugins to deal with diverse third party tools such as build systems and test systems, often themselves developed with no regards for how to integrate within a graphical environment - Many popular libraries exist in varying states of disrepair. Lack of clear stewardship by Sun then Oracle caused several libraries to target quite ancient JVMs. - Use of popular libraries can thus hinder your ability to use newer JVM features, and can even hinder your ability to upgrade to newer JVM releases - exploratory and incremental development (REPL environments, exposing server app changes) have historically been pain points. I personally have seen environments where verifying a a fixed typo in a JSP template file requires a five minute redeployment. - there are some very poor programming patterns (such as getter/setters for internal state) which have been cemented in the Java ecosystem, such that I would never recommend it for starting or junior developers. - there is a long-standing reputation for java developers (more than developers in other languages) to treat Java as a hammer and all problems as a nail. In reality, Java is in the top ten for solving certain problems, and outside the top 50 for solving others. You simply can't be good at everything. But this means a lot of recommendations to use Java get discounted - "is this person only recommending to use Java because they have zero experience with anything else?"

The JVM and Java language themselves: - The language has gone years with relatively few improvements. - The language has a strong guideline of backward compatibility maintenance which hinders the efforts to improve it. As examples, lambda support was added in Java 8 without a clear model for dealing with errors, as well as Optional added without compiler support to enforce usage or VM-level support to optimize memory layout. - There is a lot of dead weight and known bad classes in the standard library (many pre-1.2 classes like Hashtable, two date/time systems, CORBA, RMI). Some of these are finally being removed from Java by being relegated to external libraries. - The language and JVM have an obfuscated generics system, with features (such as reified generics) likely never to be completed - The Java language is wordy and simplistic, requiring a lot of code to accomplish tasks compared to many other languages - Due in part to the simplicity of the Java language and focus on supporting multiple implementations of library APIs (such as multiple logging frameworks, multiple XML libraries, multiple JSON libraries, and so on) the language tends to be design-pattern-heavy and complex to navigate. - The exception model of Java (with checked exceptions) is generally considered to have been a poor choice now. - The class loader creates frustrating-to-diagnose issues, eating up valuable time you could be working on your application

Kotlin solves some of the language issues, but not the JVM or ecosystem issues.

Swift has a nicely developing server ecosystem, but does act differently from Java in important ways. Java has a broken intra-process isolation model, but you do still have web "containers" that allow for deployment/redeployment of applications on a running server, and which will attempt to recover gracefully from programmer errors. Many Java applications dedicate a thread for handling a request, and will handle exceptions as a failure in that request - but otherwise continue on attempting to handle future requests.

Swift is _not_ gracious about programmer errors, and will abort() on misuse such as force-unwrapping an optional without a value, or indexing an array beyond bounds. This is not unusual (node and PHP are examples of servers which will abort on certain issues) and is generally a benefit in that you get to diagnose failures by primary effects rather than secondary effects, but it does mean that you need infrastructure to catch such issues and make sure a new instance of your server is started.

(For what its worth, there have been proposals in the future (post a Swift language concurrency model) to add isolation around subprocess or actor boundaries, so that unexpected errors would only abort a "portion" of a server.)

dwaite5• 7 years ago

I'll try to answer the second part to the best of my ability, not knowing more about what sort of server problems you are trying to solve (http content? javascript PWA/SPA app? API server? chat server?)

- Python is a pretty popular language for server development. It does have some performance issues (including a global interpreter lock), so you would have to decide the trade-off of your time vs infrastructure cost. - Ruby on Rails and Sinatra are both pretty mature at this point; less trendy but a known mix of positive/negative points. In particular, I have a pretty easy time making high-quality REST APIs and backing persistence store in rails than in a lot of other languages (but I'll also admit to a stigma against Python based on a prior work project I had to co-own and maintain) - Javascript (via Node) isn't to be flippantly discounted. It isn't the best language and doesn't have the best tooling, but for a web application you likely will have front-end javascript anyways. You can also use Typescript, which usually is a net positive for productivity and maintainability (but I've hit a lot of issues lately with third party library type definitions) - C# is becoming more compelling with the .Net Core work. In some ways it feels like a Java which was properly maintained by its vendor. - I won't bash PHP, since its disadvantages are well known. But for quick prototyping web applications (without excessive javascript), a dev with PHP experience can work faster than in just about anything else - For non-web applications, Erlang (or Elixir) as well as Go may be the best choices due to their inherent support for concurrency. I can't comment on their use for making web applications. - C and C++ win in terms of theoretical maximum throughput and lowest latency/memory usage - but it requires time, knowledge, and skill to achieve that, and you likely care much more about business logic. I've seen experienced developers work months on a C-based server, only to beat its performance with something they wrote in a weekend in another language. - Swift imho has yet to be proven for the server. If you love the language it may be worth trying for a project, but I wouldn't choose it for something on the critical path (yet)

Java still has huge benefits when integrating with third party technologies within a monolithic application. For example, when selling servers acting as on-premises middleware, Java enables you to use third party libraries and some glue code to make a plugin to theoretically support everything. You also have the benefit of being able to publish a programming API for others to extend your product themselves with Java code, something which may not be as easy to accomplish with compiled languages or if it requires the customer to learn something a bit more esoteric.

Java is somewhat unique in how easy it is to add third party code and dependencies to a project - scripting languages usually cannot match this as dependencies may also include native code. This is one area where Pure Java was a win, and is why a lot of distributed processing systems (such as Hadoop and Storm) often are written in and prefer Java.

Finally, I personally don't buy into JVM languages very much (Using JRuby/Jython to run portable code on the JVM is another matter). A different syntax doesn't solve the problems with the Java ecosystem or the JVM's resource usage or lack of inherent support for newer programming concepts. As soon as you branch out to use Java code, you lose a lot of the safety/immutability guarantees and features in the new compiler model. In return, you lose the ability for all of the Java developers to be able to understand and contribute to your code.

sidlls2• 7 years ago

Engineers with Java experience and enterprise development are more plentiful (less expensive) than with many other languages and ecosystems.

slaymaker1907• 7 years ago

Java, by nature of its moving GCs, can often do better with long running applications than languages like C and C++ which can much more easily suffer from internal memory fragmentation. You can work around it by using tricks like memory pools, using a sophisticated malloc implementation, etc., but that all is much higher effort than with Java.

Additionally, a lot of the systems you mentioned can often benefit from the sophistacted dynamic classloader the JVM provides. For something like Spark (mentioning this one because I am familiar with it), it is a requirement to load and run user specified code dynamically. You can do this in C, but the JVM makes this much easier.

sehugg• 7 years ago

Yes, it's really more about the GCs than the JIT. The yak-shaving involved in a performant C++ app is an order of magnitude higher. Plus, you get nice stack traces. Libraries like Netty make for extremely high-throughput apps.

ktjfi• 7 years ago

So that's why so many companies say they use Python? So their competitors become stupidly slow?

eruci• 7 years ago

I tell everyone I'm using Perl.

eps• 7 years ago

Heh... reminds me of a startup from the dotcom era that I joined right when they were burning through their last millions. It was a hosted service aimed at telcos and claimed to handle thousands of active sessions per box. Except it was written in Perl and in reality didn't scale beyond 10 or 20 sessions. But it didn't matter a bit, because they had no customers. So, yeah, Perl :)

inopinatus• 7 years ago

I once told a competitor that we're using Javascript extensively and our TTM for new features is super low thanks to simply adding NPM modules whenever necessary.

In hindsight I should also have mentioned NoSQL databases and a microservices architecture.

lagadu• 7 years ago

In hindsight I should also have mentioned NoSQL databases and a microservices architecture.

That would just be cruel :(

cpeterso• 7 years ago

Erlang and Elixir processes seem like a good model for serverless FaaS. Your code as written could run on one core or scale to multiple cores or servers.

BuckRogers• 7 years ago

It's mildly misleading to say Erlang was the special sauce, language specifications and runtime are so often conflated. It's really BEAM VM that's special. There's not many other examples like BEAM languages that you could have a meaningful post either. Most languages are developer preference, and simply make some things easier than others. It didn't take me too long to get over "language churn", after finding there wasn't much for language innovation happening. Today I'm a fan of spaces like Java and C#. The languages are fine, but it's everything else that makes them so great.

namelosw• 7 years ago

This is really sad. Since Erlang is both a practical and simple, elegant language.

I always believe if Sun and Ericsson swap their languages back to 90s, say Sun have Erlang and Ericsson have Java the world would be totally different.

I'm pretty sure Java guys struggled quite some years for distributed Web development. Thread and lock were all the things most of them know.

drallison• 7 years ago

It might be time to reconsider using Java because of the Oracle v. Google lawsuit. Oracle has asserted that Java's APIs are copyright; that issue is the subject of a writ of certiorari currently before the SCOTUS. And some recent versions of Java are no longer free and open source. It is strange when language choices are driven by intellectual property considerations.

“No, we’re telling everyone we are using Java”

Related Stories