Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is java dead for startups?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 101 posts

Re: Is java dead for startups?

#91

Post by barrkel »

prodigal_erik wrote: post #64
strlen wrote: post #57

Earlier quoted context omitted.

I think it comes from a too-literal understanding of design patterns. E.g., for the factory pattern the common practice (outside of some well designed APIs e.g., google collections) the common practice is: public class Image { public Image(byte[] data) { // create the image from byte array } } public class ImageFactory { public Image createImage(File file) throws IOException { // read data then create an image } } vs…

At runtime you can provide a different implementation of ImageFactory. For example, a unit test can define MockImageFactory which ignores the filesystem and just returns a canned Image object. If code everywhere calls the static Image.open method, there is no way to redefine it short of editing the source or the bytecode.

To which the counter-argument is YAGNI (the different implementations). There are other ways to do the equivalent of mocking, though the interface / factory approach is popular at the cost of doubling the number of identifiers in play and probably having a geometric effect on complexity.

Re: Is java dead for startups?

#92

Post by strlen »

al_james wrote: post #79
strlen wrote: post #49

Earlier quoted context omitted.

Almost all of the best Java developers that I know (including many who ran Java user groups, podcasts, started well known projects) would choose to use Scala on a new project rather than Java. Given Scala's present state (many performance problems were ironed out in 2.8.0), I simply don't see a single reason not to do so. It's quite puzzling why the author of the parent article lumps it in with Ruby as the two aren't…

But you are forgetting that its much easier to hire experienced Java programmers than experienced Scala programmers, simply because there are not that many of the latter.

If a Java, C#, C++ (or F# or OCaml) programmer isn't able to pick up Scala (or any other typed object oriented language) quickly on the job, they aren't that great of a programmer (even if they are experienced).

Same for knowing any of {Perl, Python, Ruby} and being able to easily pick up the other. Some of the more advanced idioms may take longer to learn, but it's a fact of life that you'll have to learn new languages as you go.

On the other hand, if you need to hire average but experienced programmers (e.g., if you're doing outsourced CRUD app development) then you might have an argument.

Re: Is java dead for startups?

#93

Post by CCs »

alnayyir wrote: post #86
igouy wrote: post #83

Earlier quoted context omitted.

So if that isn't 'real "proof"' what would be 'real "proof"' ?

Implementation + problem specific. Languages aren't fast, code + data + implementation combinations are.

The language and its implementation will limit the efficiency of the end-result (the running code).

The current Google Go compiler implementation produces slow code, but there's a potential to make it as fast as C. The JavaScript implementation can be made better, but it will never be close to C.

Scala running on JVM will produce similar efficiency to Java. On multicore the Scala compiler will likely produce a faster code by default, but that advantage can be matched in Java with extra work.

Scala running on .NET will likely perform similar to C#.

Now it's up to the developer to create efficient source code for the given language. It is possible to write slower code in C than in JavaScript, but the focus should be on "normally".

Normally Scala gives you the same end-result with less work than Java. There are exceptions.

More: http://www.scala-lang.org/node/25 (Look for "Scala Compiler Performance")

An older measurement: http://fupeg.blogspot.com/2008/06/scala-vs-java-performance....

Re: Is java dead for startups?

#94

Post by strlen »

plinkplonk wrote: post #90
vineet wrote: post #88

Earlier quoted context omitted.

As a startup we evaluated using Scala for parts of our development but found the development tooling support to be very limited. Eclipse is a great IDE that has been an awesome productivity booster, but the Scala Eclipse plugin kept throwing Exception. If it worked for me, then I would have tried it out, and then I would have gotten my teams feedback, then we would have considered switching. i.e. I do see non Java la…

"As a startup we evaluated using Scala for parts of our development but found the development tooling support to be very limited." Twitter seems to manage fine with the "limited tooling" for Scala and is the existence proof that Scala works fine in startup/production environments. I suppose they must be using ancient editors like Emacs or Vim and unix command lines? Sure, "tooling" like that existing for Java would b…

> Or even Ruby or Python- all of these have "limited tooling" as compared to Java.

The reason for the IDE argument is again, a continuation of the "Stockholm syndrome" argument. The whole reason the IDEs are considered "required" for Java developers is because the language is verbose. You don't need an IDE to write Scala: type inference means less typing (pun intended), having a REPL means you can evaluate code before compiling.

I haven't seen CDT and PyDev Eclipse plugins (which are reportedly well written, supported by large companies) get very much traction as you simply don't need Eclipse to program in C or Python: the languages are terse, the APIs (Python's standard library, C's stdlib and UNIX network APIs) are easy to keep in your head.

That being said, as Scala is more statically typed than Java (but at the same time supports a REPL) it's theoretically possible to have better IDE support for it then Java. IntelliJ's Scala mode works very well (and is free) and ensime (for Emacs) is simply incredible: http://www.youtube.com/watch?v=A2Lai8IjLoY

On the other hand, the sort of tooling that actually solves difficult problems is just as available to Scala as it to Java: YourKit profiler, JVisualVM (and other JMX consoles), etc... In some cases there tools available (e.g., sbt, ScalaSpec/ScalaTest, Slime for Clojure) that are superior to the ones for Java.

Re: Is java dead for startups?

#95

Post by dstainer »

dstainer wrote: post #26

I agree with a couple of the posters, I think the JVM is the core piece of technology to take away from the Java ecosystem. Especially as more languages can compile byte code to run on it. That being said Java still plays a very big role in backend systems and don't forget that some important backend tools i.e. Hadoop and Cassandra are written in java. So I wouldn't write it off just yet. Derek http://nosqldatabases.…

I'm sorry it was bad form and I apologize, I would remove it but I can't edit the original message anymore. However, my point was still legitimate, even if the link was not.

Re: Is java dead for startups?

#96

Post by igouy »

alnayyir wrote: post #86
igouy wrote: post #83

Earlier quoted context omitted.

So if that isn't 'real "proof"' what would be 'real "proof"' ?

Implementation + problem specific. Languages aren't fast, code + data + implementation combinations are.

You seem to have encrypted your comment - please decrypt so we can understand and evaluate the point you wish to make.

Re: Is java dead for startups?

#97

Post by elblanco »

Zak wrote: post #85
elblanco wrote: post #82

Earlier quoted context omitted.

>* including but not limited to Haskell, Common Lisp, Scheme, Clojure, Scala and several ML variants * Any non-FP languages?

Most languages that I would designate as "expressive" allow FP, but not all require it. Common Lisp isn't very functional; it doesn't even do tail-call elimination by default. It's idiomatic to use a fairly imperative style in CL. Scala allows FP, but also has OO that's fairly similar to Java with less boilerplate. Lua allows FP, but an imperative style is idiomatic (it doesn't even have map/reduce/filter built-in).…

I was not aware that D and Lua had the JVM as targets.

Re: Is java dead for startups?

#98

Post by Zak »

elblanco wrote: post #97
Zak wrote: post #85

Earlier quoted context omitted.

Most languages that I would designate as "expressive" allow FP, but not all require it. Common Lisp isn't very functional; it doesn't even do tail-call elimination by default. It's idiomatic to use a fairly imperative style in CL. Scala allows FP, but also has OO that's fairly similar to Java with less boilerplate. Lua allows FP, but an imperative style is idiomatic (it doesn't even have map/reduce/filter built-in).…

I was not aware that D and Lua had the JVM as targets.

You only asked for non-FP languages, not non-FP languages with the JVM as a target. There's a Lua implementation for the JVM called kahlua. It appears to be in a fairly early stage of development and may not be fast or suitable for production use. As far as I know, there is not a D compiler for the JVM.

Groovy appears to be potentially as fast as Java. It can call Java easily, which means you always have the option to rewrite something that's too slow in Java itself.

Re: Is java dead for startups?

#99

Post by al_james »

strlen wrote: post #92
al_james wrote: post #79

Earlier quoted context omitted.

But you are forgetting that its much easier to hire experienced Java programmers than experienced Scala programmers, simply because there are not that many of the latter.

If a Java, C#, C++ (or F# or OCaml) programmer isn't able to pick up Scala (or any other typed object oriented language) quickly on the job, they aren't that great of a programmer (even if they are experienced). Same for knowing any of {Perl, Python, Ruby} and being able to easily pick up the other. Some of the more advanced idioms may take longer to learn, but it's a fact of life that you'll have to learn new langua…

I dont want to pay people to 'pick things up on the job'. I want people with a proven track record in the language we use.

Re: Is java dead for startups?

#100

Post by elblanco »

Zak wrote: post #98
elblanco wrote: post #97

Earlier quoted context omitted.

I was not aware that D and Lua had the JVM as targets.

You only asked for non-FP languages, not non-FP languages with the JVM as a target. There's a Lua implementation for the JVM called kahlua. It appears to be in a fairly early stage of development and may not be fast or suitable for production use. As far as I know, there is not a D compiler for the JVM. Groovy appears to be potentially as fast as Java. It can call Java easily, which means you always have the option t…

Thanks again. Apologies if my terseness meant a loss in clarity. I thought the JVM was implicit in the thread and that you were listing languages with the JVM as targets (also my mistake as I see that you were not exclusively listing those, guess I should refrain from posting till I've had more sleep).
Post reply on HN