
“No, we’re telling everyone we are using Java” - tosh
https://twitter.com/joeerl/status/1104298407231922176
======
jwr
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.

~~~
peterlk
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
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.

~~~
sharpy
Probably more to do with the runtime environment.

~~~
sieabahlpark
This is exactly why.

------
inopinatus
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
> In hindsight I should also have mentioned NoSQL databases and a
> microservices architecture.

That would just be cruel :(

------
jmts
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.

~~~
RivieraKid
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
> _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?

~~~
RivieraKid
Yeah I agree that it should be easy to run it like a scripting language... I
just found out it's possible since Java 11, you can now run "java
MyProgram.java"

Now that I think about it, I can understand why people would dislike Java, the
standard library kind of sucks, it lacked lambda functions before Java 8...
and in general there seems to be lack of focus on usability and elegance,
which also spreads to the ecosystem. Modern Java is not that bad though.

But - Java offers a surprisingly unique package - it's fast, it has GC, static
typing, good library and IDE availability, supports both OOP and functional
programming (kind of). There's really only 1 competitor unless I'm missing
something - C#. There's also Kotlin if that counts. Swift doesn't have GC and
not sure if it's mature enough outside of the Apple ecosystem. Dart is slower.

------
stunt
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.

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

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

[http://paulgraham.com/avg.html](http://paulgraham.com/avg.html)

~~~
hopler
Viaweb used Lisp.

Google used python, Java, and C++

Amazon used perl and C++

Facebook used PHP!

~~~
myth2018
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/](https://redditblog.com/2005/12/05/on-lisp/)

~~~
kazinator
Reddit's rewrite was done "pretty much done in one weekend".

Things that can be rewritten in one weekend are trivial; they don't speak to
anything.

A Lisp site that can be rewritten in Python in one weekend can be probably be
rewritten in shell + awk + CGI in two weekends.

~~~
myth2018
The link exposes some underlying reasons which I think applies to bigger
projects as well. Like the lack of libraries.

~~~
kazinator
Lack of libraries applies to tiny projects, because the "activation potential"
has to be small. Developers are reluctant to write 1000 lines of library
wrappage for the sake of 700 LOC of payload, but they might well do it for
something that can be expected to be 25 kLOC, and much more likely if they're
going to have 250 kLOC riding on it before the product reaches 1.0.

~~~
myth2018
It definitely applies to large projects as well. It's not just a matter of
what developers think about writing more code. It's a bit more complicated
economic decision involving how a significant amount of resources is going to
be spent on writing code, testing it, whether the team is actually capable of
writing the needed libraries, security risks introduced by bugs etc etc, just
to begin with.

------
boznz
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_man
Is this real? If so, please elaborate.

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

~~~
indecisive_user
Yup, I don't blame the client at all for rejecting a Delphi contractor.

Where I live it would be easier to just start the project from scratch than to
try to find someone proficient in Delphi to maintain it

~~~
devit
Just find any decent programmer and have them learn Delphi as needed?

I mean, a lot of people program in a language they aren't familiar with
because it has the best ecosystem for a given job or because the open source
project they are modifying is written in that language.

~~~
bwilliams
That's an option, but I can't imagine many folks would want to learn Delphi
and continue to invest their time into it unless the money is worth it.

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

~~~
sidlls
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
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”

------
dpflan
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](https://twitter.com/devoncestes/status/1104000439987683328)

~~~
whizzkid
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.

~~~
Consultant32452
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.

------
iiiggglll
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.

~~~
snaky
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/](https://www.activestate.com/resources/webinars/perl-paradox/)

~~~
zbentley
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.

~~~
labster
Cool story bro.

To me it just sounds like your colleagues were a little nuts. You don't need
metaprogramming to write a large application, and reaching for Devel::Declare
should be reserved for last resorts and "hold my beer" moments. You're right
that the conferences have a lot of this kind of stuff, but most of us know
better than to actually use it, and read Perl Best Practices.

Most of these issues are solved in Perl 6. Any language changes are scoped
lexically by default (e.g. declaring sub infix:<==>). Emphasis on threads
instead of forking for concurrency, with await and first class Promises. If
you want to write see, just write normal C and use NativeCall, instead of
writing in the bizarre XS dialect of C. But it's kind of a different
language... yeah.

~~~
Floegipoky
I'm not going to say we weren't all nuts... but a lot of advanced language
features, including metaprogramming, were necessary to build things that other
communities take for granted: frameworks, test harnesses, mocking, static
analysis, etc.

------
FunnyLookinHat
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. :)

~~~
bitwalker
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.

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

[https://lobste.rs/s/pcebor/choosing_elixir_for_code_not_perf...](https://lobste.rs/s/pcebor/choosing_elixir_for_code_not_performance#c_z4s36u)

~~~
unnawut
This is the first time I've heard of Lobst.rs. Looks like a HN clone more
targeted towards programming. Thanks!

------
protomyth
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.

------
dmitriid
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.

~~~
wbl
Even the ones writing telephone switches?

~~~
dmitriid
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](https://twitter.com/guieevc/status/1002494428748140544)

~~~
bitwalker
Ericsson absolutely still uses Erlang [1] - the vast majority, if not all, of
the core Erlang/OTP team are employed by Ericsson, and that team is still very
much active and constantly improving the language and runtime.

[1] [https://www.ericsson.com/en/news/2018/5/erlang-
celebrates-20...](https://www.ericsson.com/en/news/2018/5/erlang-
celebrates-20-years-as-open-source)

~~~
dmitriid
Yes, I know that. They have the team and continue developing and improving
Erlang because they have paying customers who use Erlang.

Inside the rest of Ericsson, however, there's very little Erlang left. Once
again, only hearsay, no hard proof. They still hire for Erlang here and there
(used to be primarily non-Swedish offices) [1], and they offer theses for
Erlang [2]

[1]
[https://jobs.ericsson.com/jobs?keywords=erlang&page=1](https://jobs.ericsson.com/jobs?keywords=erlang&page=1)

[2] [https://www.linkedin.com/jobs/view/master-thesis-erlang-
json...](https://www.linkedin.com/jobs/view/master-thesis-erlang-json-for-
the-5g-core-network-at-ericsson-958913296/?originalSubdomain=se)

------
jackewiehose
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?

------
exabrial
Are we already on the next hype cycle?

------
eruci
I tell everyone I'm using Perl.

~~~
eps
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 :)

------
BuckRogers
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.

------
drallison
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.

------
namelosw
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.

------
aero142
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.

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

~~~
aero142
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](https://www.youtube.com/watch?v=2kjtQnPqq2U)

------
cpeterso
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.

------
vikingcaffiene
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](http://paulgraham.com/pypar.html)

~~~
peteforde
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.

~~~
whizzkid
Start here --> [https://elixir-lang.org/getting-
started/introduction.html](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!

~~~
Klathmon
Pattern matching will break you.

I get frustrated at least once a week trying to use it in a language that
doesn't have it. My brain just thinks in pattern matching!

~~~
macintux
It's unfortunate when I encounter a language that has a crippled
implementation of pattern matching (looking at you, Scala). After using
Erlang, it's hard to accept anything less.

~~~
vram22
How are F#'s and OCaml's implementation of it, in your opinion?

~~~
macintux
I’ve not tried either, although in my limited exposure to SML it seemed fine.

The other related feature whose lack I regularly lament in most languages is
multiple function heads, which apparently is rarely used in the ML family
tree, bafflingly.

~~~
sgrove
I haven't heard the term "multiple function heads" \- is it similar to
Haskell's way of defining functions? e.g.

    
    
        fib 0 = 0
        fib 1 = 1
        fib n = fib (n-1) + fib (n-2)

~~~
macintux
Exactly. I don’t know what the typical industry term for it might be.

~~~
mercer
Multiple Dispatch / Multimethods (I think?)

~~~
macintux
Interesting, it appears that multiple dispatch is accurate. Thanks.

------
biesnecker
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.

~~~
sacado2
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
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.

~~~
fulafel
Dynamic languages do this with schema validation. It can be more expressive,
checking value ranges or string formats, multi field conditional constraints,
and so on. And allows better& customizable diagnostics.

Edit: also, versioning, cross language sharing, use in generative testing, api
client code generation and other metaprogramming uses. And documentation
generation, eg swagger

~~~
roca
and once you've validated a value your code immediately forgets what type it
is.

~~~
fulafel
Beware of confusing dynamic typing with weak typing :)

If you are using eg Clojure's spec, you can reference the same stuff
downstream in the control flow too, for eg fn argument validation.

------
Joe-Z
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!)

~~~
matt2000
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.

~~~
ulkesh
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.

~~~
GorgeRonde
Most people who have durably coded in java and say, Haskell or a Lisp (as I
have) or any other trending language on HN will prefer the latter.

Knowing that (as I did) why not expand your horizon (as I did) ?

~~~
throwawaymath
I don't see how you could possibly state that conclusively.

What leads you to believe most Java programmers would prefer Haskell or some
flavor of Lisp? You're saying that people who spend time in both will prefer
the latter, but it seems equally plausible that people _wouldn 't_ spend time
in both _because_ they don't like the latter.

~~~
GorgeRonde
Your point can be generalized to support any local optimum. Come on. "It seems
equally plausible that people wouldn't spend time hearing your argument
because they don't like it".

Still, this is a bit harsh to return your argument like this, because you're
striking a good point: getting to know a language and its "philosophy of use"
takes time. However, i do not see why not having taken the energy to climb out
of your comfort zone to reach what is considered a better optimum by those who
have would give any more weight, by comparison to the alternatives, to your
opinion.

Edit: I have never used Haskell, but if I had to chose a next language to
learn this would probably be it. Simply because people who use it speak of it
as a kind revelation by comparison to the the way they used to program in
their previous language. Also since I have worked for quite some time with the
dynamic alternative in FP (Clojure) I might well try its static variant with
Haskell. However as you pointed out, I'm not learning it because of lack of
time/focus. Still that does not prevent me from listening closely to what
Haskellers have to say, or say people from Common Lisp or even people attached
to the JVM and its language ecosystem. Why ? because their experience is
valuable. It's not just theirs, and it could way have been mine.

~~~
throwawaymath
My point can be generalized, sure. But _you_ haven't substantiated the idea
that most people who try both Java and Haskell/Lisp will prefer Haskell/Lisp.
That's precisely why my very general point is applicable - your claim is
sufficiently unsupported that I can simply reverse the hypothesis and we have
no more or less information than we started with.

If you'd like, I can trade anecdotes instead - I used to work at a company
with a large codebase consisting of nontrivial Java, Clojure, Scala and
Haskell. Nearly every engineer I spoke to preferred Java (and I had to
interact with nearly all the 300 engineers who worked on it).

Now at this point it may seem like I'm being a curmudgeon. But the reason I'm
harping on this is because your implicit claim is that Haskell/Lisp are better
languages for either productive or aesthetic reasons. But I don't think that's
a fair statement - they're different languages, suited to different tasks. You
shouldn't draw the conclusion that people who have e.g. moved on to Haskell
from Java are representative of most Java developers. It's equally plausible
that most Java programmers _don 't want to move on from Java_, and so wouldn't
like Haskell if they've tried it. Or perhaps they have tried it and simply
didn't jive with it.

~~~
willtim
> they're different languages, suited to different tasks.

What tasks exactly do you think Java is better suited to than Haskell? The
"innovation" of Java was to take the runtime of a high-level language and
combine it with the productivity of a low-level one. It is not well
particularly suited to systems programming or high-level programming (e.g. ML
and analytics, parallelism, concurrency).

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

~~~
mwkaufma
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

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

------
jstewartmobile
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.

------
svnpenn
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
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?

