When dealing with new tech it's a lot more likely to be the first person to run into some obscure use case no one has ever experienced before. And in that case you need devs who are not only capable but willing to invest in solving the problem. Sometimes that means, re-architect something in the stack and sometimes it may even require making a PR to the original project. That's a lot of investment that may make your devs happier but probably provides little concrete value to the business.

That said I'm still building on elixir so what do I know.

I have a relative who got really into this mindset. In fact he picked the "HN's Choice" software framework of the day for one of our co-creative projects a couple years ago. Mostly a fun project, but it could have gone somewhere, maybe. He got as far as setting it up so that we had some scaffolding, then basically he flamed out. I don't blame him at all; he'd never even used it before and expected himself to be able to just run with it. And this guy was a _master_ at a certain language starting with the letter P, but he was ashamed to use it. It made me so upset to see him feel all this pressure and then collapse.

Personally I feel that pressure myself sometimes but being aware of it helps a lot. As a hobby side project, I decided to go back and do some 1990s MS-DOS programming and experiencing this FOMO stuff was part of the motivation. I needed to be free to work deep instead of thinking broad, so to speak.

Prolog?

What a shame he couldn't use his best language! It has such nice web frameworks.

https://en.wikipedia.org/wiki/List_of_programming_languages#...

There are plenty of other forums and sites to read about conventional tech. HN is where I find the bleeding edge. 90% of it is just fascinating. But the other 10% offer tantalizing possibilities for making something novel, which is to say: solving an unsolved problem.

“How to Become a Hacker” puts it plainly: no problem should have to be solved twice. Drudgery is evil. And by those axioms, a ‘Hacker’ is just uninterested in old solutions to old problems. We need to live in the future so that we can build the future. Although HN’s content has suffered over the last 5 years with the influx that accompanied a wider awareness of startups, it still is the best place I know of to dip your toes into the various futures we may one day encounter.

Having said that, lately I’ve found that Google Scholar is often more thought-provoking. If only there was a HN for Google Scholar.

The highest paid people in our industry are working on drudgery full-time for FAANG. And that's fine, people have families, I'm not judging anyone. But let's not fool ourselves.

The shat on one is the old Java, verbose, obtrusive style. The newly praised one is Haskell-style, type inferred, expressive...

Now you could say that's not new, BUT what is new is marrying ML style type system to languages whose other concepts devs are largely familiar with and packaging it the right way to get into production, instead of just academia and that being the case even for historically impenetrable low-level programming and such.

https://fsharpforfunandprofit.com/csharp/union-types-in-csha...

Normally my comment would be an unnecessary back-slapping, but since the conversation veered this way, I think it is appropriate to call out your comment as something that represents the spirit that makes HN unique and wonderful.

Hackernews has an _instagram filter_ where everybody brags about how smart they are.

Then there's a bunch of fresh grads who fanboy their favourite tech companies.

Then every so often you get a gem of a comment from knowledge leader in the industry.

But that's quickly overshadowed by 'my Startup, my Startup, mah Startup' and how everybody wants to be rich one day.

But like every larger community in the internet, it eventually derives itself into an echo chamber.

Look on the front page right now and see how many stories are about startups. That didn’t change in the last five years. It’s always been about technology in general.

HN’s front page 10 years ago:

https://news.ycombinator.com/front?day=2009-05-10

HN’s front page 5 years ago

https://news.ycombinator.com/front?day=2014-05-10

Having said that, the most apparent change to me is in the tone and substance of the comments rather than the front page. And it isn’t a huge change. Just noticeable for me.

Im not surprised the leaders of IT, ppl who create those new technologies, push for a narrative to use those new shiny things.

Or engineers who've convinced themselves that they're Tier 1 engineers...

The concrete value doing such things add to our business is happy staff (which you mentioned), which means the best people don't leave, and stat excited and productive for the long term. Also, when hiring, because it helps us get the best people to join us in the first place.

It's not just about "bleeding edge", it's about giving dev teams the freedom to do that if they want to. Some do more than others, but the point is, if they get it wrong, things break and they get called at the weekend or whatever and they soon change track.

1. Half-done projects started by some happy staff who then went on to start the next project in the next shiny new thing and either more-or-less completed by someone who was just about capable of cut-n-pasting without understanding or who decided that some new shiny thing needed to be added to make the rest wonderful.

2. A monstrous stack of projects in 637 different programming languages, frameworks, ideologies, coding styles, and indentation levels, guaranteed to require rewriting for any change. Result: 638 different things.

Of course, letting someone write whatever and then move on and leave it to someone else is a problem, but that's a problem regardless of whether they used bleeding edge tech or not.

For example, I've personally seen more tech-debt sins in more traditional monolithic Java + rdbms applications than I have an any of the Go based micro-services + nosql/etc I've seen over the years. I'm not trying to prove that "bleeding edge" is therefore better because it's not. I'm saying it's irrelevant.

The problem of leaving behind unmaintainable crap isn't about the tech, it's about the management, the team processes, the prioritisation process etc.

(There may be some overlap)

I could use shiny new tech for the startup (which at the time was python on app engine and its nosql datastore, with a backbone.js framework), whereas the other one forced me to use java and deploy the code on the big corp datacenter.

The start up code was built in two months, and maintained by an intern for two years with success. It basically cost nothing to run.

The big corp code was built in a year (note: i did know how to develop in java), people in charge couldn't manage to deploy it (i had to do it myself, despite just discovering their infra on the spot), and i had to maintain the code myself, because despite huge code guidelines and restrictions on the technologies allowed, nobody inside was assigned to maintaining the code.

So, yeah, there's definitely a danger to absolutely wanting to follow the HN hype. But don't feel good if your company relies on 8yo tech and process. It could be loosing a TON of money by not staying up-to-date with the state of the art.

You cannot stay up to date permanently, because that introduces risks all the time. Once you earn money, there are layers to protect the money stream.

You can loose tons of money by not staying modern, that is true. But you can loose everything when you ignore a risk. The trick is to find a balance.

And all of that is not considering investors and their idea how the money should be used.

I suspect corporates don't really want to get stuck with so much legacy, they just don't know how to avoid it.

The problem in enterprise tech like you found is that one is forced to use certain, non-productive old frameworks filled with legacy, over-engineered bloat.

Modern Java micro-services in contrast are really fast to develop. Green field Java projects where one can make personal choices of lean technology and libraries are simply amazing. They also have terrific characteristics under load. The JVM performs well even with bloatware. When you trim out and make your JAR's lean and mean then its utterly amazing.

This attitude is a bit surprising to me. The main point of micro-services is that they address a complexity problem when dealing with large organizations. That is, they allow a large organization to break into small teams that can work (relatively) independently so each team can iterate faster. However, microservices definitely make a host of issues harder:

* cross-service transactions are much harder

* cross-cutting concerns can be more difficult to change.

* can add organizational complexity of a feature you want to add needs corresponding changes it up or downstream services.

Even Martin Fowler has this quote:

Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.

Micro-services allowed us to break this. Micro-services also allowed us a faster turnaround time in feature delivery and reliability. It is also easier to isolate problems.

Generally stuff in the monolith that are already abstracted by large service facades are a good candidate for a separate service with their independent data model. Avoid cross-service transactions completely. If you have a cross-cutting concern, it generally means you need a separate service managing that cross-cutting concern.

Organisational complexity is definitely increased. This can be mitigated by tooling. Our build pipeline shows the full graph dependency chain, what is built, what is getting built, what has been deployed, etc.

We have the concept of a "system" that is basically a versioned set of micro-services running off a build trigger. We developed the capability to namespace systems - ie each system of services uses separate resources (kafka/db/etc) and separate URL's (via custom domains) when deployed on our cloud platform. You can also "plugin" your micro-service into a targeted system for diagnostics. This way dev, testing and product demo teams can work independently. The latter is not micro-service best practice, but in a large, slow-moving organisation, we found it valuable.

We also have a distributed dev team, but decided against using microservices. Instead, we have a monolith with a plugin architecture, so remote teams can just add independent modules to add functionality. Occasionally changes are made to the monolithic application, and these changes are heavily scrutinized. The plugin architecture provides many of the benefits of a microservice, while also allowing for more flexibility on occasion, and eliminates flaky network calls that are inherit to microservices.

I agree with all the issues you've stated, but I'd like to add one more. Microservices arguably make it much easier to build systems with circulate dependencies leading to weird race conditions and deadlocks.

Consider two units of code A and B. If implemented as classes, modules, or libraries, it's relatively easy to spot and prevent A calling into B which in turn calls back to A. Sometimes the compiler and tools can automatically catch that.

With microservices, catching dangerous dependencies like this are much more difficult as each service, outwardly, seems independent of the other and there are few tools to catch these dependencies.

We had a pipeline consisting of microservices and Kafka topics. Simple if/then logic quickly became problematic so I implemented our flow control as a directed acyclic graph, and it helped tremendously.

It's also easy to render your graph out with any number of visualization tools to quickly understand/validate work flows.

I don't see how graph data structure solves this problem. Suppose you've created a photo sharing app. One microservice, A, has the graph database and stores the photos. One service, B, uploads and downloads photos. And a third service, C, applies filters to photos.

It's pretty easy to architect these services such that the download service B uses the filter service C in some situations, and the filter service C uses the download service B in others. This is obviously a bad design, but with microservices it's easier to make these bad design choices because the folks who wrote one service have little information about the other.

A tool to "fix" your example probably doesn't exist, but a graph is an excellent way to represent dependencies, reason about progress in the flow, and enforce constraints in a generic way.

I think people are just spinning up a bunch of unorganized services and calling them micro and then complaining about it.

If you're on a small team that can build a clean monolith, the work to make them microservices is imo pretty trivial.

It's still not comparable with Rails. Let alone some niche bleeding edge technologies which are focused on productivity.

I hear you brother. Google generally puts out the "smartest" stuff, but they don't really care about the day-to-day needs of most of their users. The idea is generally "we've thought about this a lot, and this is the best way, so change your code to handle it." The problem is that every few months, they seem to come out with a new "best way".

Yet, even with this stack, 50% of the spent time was due to internal process. As an example : we called them once to ask for some news, and they told us about doing a kickstart meeting. At this point we already had finished developping everything and wanted to talk about deployment (little did we know we would have to redevelop part of the stack because of guidelines we hadn’t been told about before).

Out of the four modern languages/frameworks that I’m fluent in: C++/TreeFrog (played around with it just because I am a masochist), C#/ASP, Python/Django and JS/Express, I really don’t see any difference in my productivity in any of them.

I think the tech itself has little to do with it. Cash-strapped small startups are hungry for developers, and often ask them to do more than they can. Large companies often have many developers idling or working on fake toy projects that never see the light of day. There are massive inefficiencies in large institutions. Using old tech may be one of them, but it's a drop in the bucket compared to inefficiently utilizing the people you have.

And yet. Despite the danger, that was a billion dollar business. So they were doing something right, weren’t they? ;)

The best & brightest in tech are working with the best tools on the biggest problems, and that's what gets talked about, regardless of what the mass is doing.

I don't think that's true—there is a subset of the best and brightest who work on greenfield projects very decoupled from existing customer bases, and they get to blog / present / post a lot about what they're doing. There are quite a few "best and brightest" people who are in large companies or slow-moving industries. They're often constrained to existing tooling, because moving to fancy new tooling is a huge risk and time sink for limited reward. They might be using cool personal tools—fancy editors and keyboards and window managers—but the stack they work on is generally "legacy".

And usually the problem of "How do we make this work slightly better for millions of end users" ends up being a bigger problem than "How do we do something really cool as a demo."

You can handle a lot of restrictions if the domain/problem is interesting enough and the constraints put on you don't feel too taxing, e.g. because they aren't enforced for your role or team very much. I feel like company size just isn't a good indicator for personal enjoyment/growth/$whatever, lots of research oriented divisions in larger corporations will let you work on interesting topics and hand off the engineering part to teams with people that enjoy that particular aspect of our world, both working for the same company.

Two, they have their pick of workplaces and focus on finding the biggest problem or perhaps the biggest paycheck, not the most freedom in tools. I have perfect freedom in tools hacking on OSS by myself; I don't look for that in a job.

Why do you assume it's impossible to have a fulfilling career writing Java 8 CRUD apps for Windows Server 2000?

I work with Java 8 on a greenfield high-frequency transaction platform for a very large company. It is extremely satisfying to build the "world's largest" of something, and no amount of shiny features in a cute new language would deter me from this work.

Incidentally, it's the same curiosity that has the current article near the top of HN right now. It's not a point that has been articulated so often, or so recently, or so well, so it's fresh. Even if we already know it, it's a fresh reminder. (And also, of course, there's the catnip of the meta dimension.)

https://carcostcanada.com/Canada/Prices/2019-Honda-Civic_Sed...

That doesn't have to mean new and shiny.

By way of analogy: the F-117 stealth fighter--the world's first operational stealth aircraft--was developed by the best and brightest (Lockheed Martin Skunk Works) and solved the biggest problem (visibility to radar). Aside from having a weird polyhedral shape and innovative radar-absorbing material, nothing about the plane was the "best", "latest", or "cutting-edge" at all. Much of it consisted of parts from other aircraft hacked together. If you actually do want to have the best cutting-edge technology all in one plane, you spend 25 years designing the damn thing--that's the F-35.

http://aviationintel.com/yak-141-freestyle-the-f-35b-was-bor...

The F-35 has them. The Yak-141 didn't. Therefore, it absolutely is an exaggeration to say the F-35 was "lifted wholesale" from the Yak-141. Two of the three F-35 variants don't even have the lift fan!

We should be so lucky. Nobody knows who's the best, what the best tools are, or what the biggest problems are. We only know the ones that get written about.

Writers cover what's flashy, who's the best self-promoter, and what makes the most money.

Sites like HN and Reddit are aggregators in the literal sense. They take a large volume of data points and reduce it to a select few that get shown to most users. that aggregation function is "most interesting", not "most representative". Those are direct opposites of each other: interesting is almost by definition unusual.

I always find the subreddits that try to explicitly not target polar extremes the most fascinating from a sociology perspective. For example, this photo of a sink faucet is the most mildly interesting submission of the past year:

https://www.reddit.com/r/mildlyinteresting/comments/9ykoe4/t...

Does that mean all other submissions were less interesting, or less mild?

1x $100 eBay turbocharger

1x $1000 misc expenses

27x $1000 JDM long-block

There's probably less fun ways to spend $30k on a Civic too

Example A - Honda Civic 1.6 i-VTEC

    Registration Fees - S$220
    OMV - S$19,370
    Excise Duty (20 percent of OMV) - S$3,874
    COE (as of 23rd March 2018) - S$38,000
    ARF - S$19,370
    VES - $0

https://www.sgcarmart.com/news/writeup.php?AID=171

[1] https://youtu.be/lQSac0Jpz0Y

It's nice to recognize there exist developers who seem to stand apart from the vocal ones who make these posts, but they're not a single class. Some brag just as much, just in different circles. Some don't brag, but they do lots of good work. Some put out work that's not so good, and they may or may seek to represent their accomplishment regardless. The only factor they clearly share is their underrepresentation and their lack of attained popularity in talking about their work on social media.

As tempting as it may be, it's a big reach to conclude due to their underrepresentation that their tech stacks are conservative, or even dated; it's not a given that their work is solid and they're hard at work solving business problems given numerous constraints and office politics. Efforts to define this population by their rejection of shiny hype just perpetuates a kind of fictitious class divide between "fancy" developers and "plain" developers, when the real class divide is between management that is desperate for results, and IT workers that are desperate for empowered decision-making and resources. Businesses are under tremendous pressure, and silver bullets read about elsewhere carry great appeal. Transplanted organically by enthusiastic developers or by order of management, such solutions rarely work, because changing just a few inputs of a complex process won't deterministically give a better result. And mediocre results of a messy process make for a different genre of writing.

Maybe there's a class divide after all: between developers who are privileged enough to cook up all sorts of clever, custom solutions to challenging problems and can write about it, and those who spend their whole workday surviving the onslaught of nonsensical demands and deliver something mostly working in the end.

At some point in time the original person isn't available anymore and whole setup will have troubles because of upgrades of the basis (e.g. Excel) or just performance problems. They are even consulting companies specialize in optimizing or migrate to new Excel version for such kind of applications.

The corporate IT have to pick up the users early to help them to solve their current problem or help them to be more efficient with IT. If nobody helps they will develop their own solution which the knowledge/tools the have.

I say this not to disparage those apps (though they were often horrifying to us as devs) but to point out that huge portions of your average large business probably run on stuff like that.

Any earlier commenter said Enterprise values process over outcome. It is true at the macro level but at the micro level bosses need to make decisions or your new work will receive no credit from above and will be used against you when it fails.

https://dilbert.com/search_results?terms=information+service...

Java the languages still isn't pretty, but it has been much improved.

OpenJDK is GPL and apart form the trademark ( ? ) with Java ( I didn't read much into the JakartaEE problem, ) everything should be fine. I am just a little uneasy with Oracle lurking around, I just don't know what they are going to do next.

Value types are a major missing piece in the JVM stack right now. It's at least on the roadmap, but it keeps getting pushed back and back and back. I'd also argue runtime generics is another one, and perhaps more depressingly one that is unlikely to ever get fixed.

.NET has both of them and also has the same core strengths JVM does, so given the choice I'd go with .NET over JVM 100% of the time as a result. JVM's GC & JIT seem to be on a never ending improvement cycle, but the actual language & core libraries are incredibly slow to react to anything.

I'll give you value types, but reified generics in .NET were a mistake. It really makes interop and code sharing among languages hard, in exchange for a rather slight added convenience. This means that if you're a language implementor and you're targeting .NET, you'll get much less from the platform than you would if you target Java, which makes .NET not a very appealing common language runtime. And not only is Java a good platform for Kotlin and Clojure, but thanks to Truffle/Graal it's becoming a very attractive, and highly competitive, platform for Ruby, Python and JavaScript. All of that would have been much more difficult with reified generics.

Also, I don't think value types in Java are being "pushed back." The team is investing a lot of work into them as it's a huge project, but AFAIK no timeline has been announced.

> and also has the same core strengths JVM does

I don't think so. Its compilers are not as good, its GCs are not nearly as good, and its production profiling is certainly not as good (have you seen what JFR can do?); and its tooling and ecosystem are not even in the same ballpark.

On the one hand, reified generics means that it's .NET's object model or the highway.

On the other hand, .NET maintains a much higher standard of inter-language interoperability. When I was on .NET, I didn't have to worry much about the folks working in F# accidentally rendering their module unusable from C#. Now that I'm on the JVM, I've accepted that it's just a given that the dependency arrows between the Java and Scala modules should only ever point in one direction.

Suppose you have types A and B, such that A <: B. What is, then, the relationship between List<A> and List<B>? This question is called variance, and different languages have very different answers to this, but once generics are reified, the chosen variance strategy is baked into the runtime.

> Couldn't the language implementations basically pass around ICollection<Object> in .NET somewhat similar to how they do in Java?

They could, but then this adds significant runtime overhead at the interop layer. For example, a popular standard API may take a parameter of type List<int>. How do you then call it from, say, JavaScript, without an O(n) operation (and without changing JS)?

Which, realistically, is probably the only principled way to do things if you want to be doing much with variant generics in a cross-language way.

The Java way, "I pick my variance strategy, you pick yours, and we'll both pass everything around as a List<Object> at runtime and just hope that our varying decisions about what their actual contents are allowed to be never cause us any nasty surprises for each other at run time," is not type-safe and can lead to nasty surprises at run time. It's easier, sure, but easier is not necessarily better.

The general solution is, like you suggested, to avoid using reified generics in the module interface where the interop happens.

What wouldn't work would be to, e.g., create a Python-native list and try to pass it into a function that expects a .NET IList<T>. Which doesn't feel that odd to me - they may have the same name, but otherwise they're very different types that have very different interfaces.

That said, the Iron languages never took off. My personal story there is that all the new dynamic features that C# got with the release of the DLR pretty much killed my desire to interact with C# from a dynamic language. The release that gave me Python on .NET also turned C# itself into an acceptable enough Python for my needs.

See: https://docs.microsoft.com/en-us/dotnet/api/system.valuetype...

https://github.com/google/auto/blob/master/value/userguide/i...

Value types are a generalisation of `int`, `long`, `float` (etc), where values are stored inline, not allocated on the heap. For instance, a `Pair<long, double>` that isn't a pointer, but is instead the exactly the size of a long plus a double, and is the same as writing `long first; double second;` inline.

Yes, yes. I know that Microsoft theoretically open sourced and ported it. However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only.

Otherwise I agree that it is a better Java.

I get why people used to shit on Microsoft, but Microsoft has demonstrated over a number of years that its changed under Satya.

> However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only.

Outside of desktop GUIs, this is simply not true. I'm writing complex, cross-platform systems that work just fine on Windows and Linux (and would on MacOS if I chose to target it).

Hell, even a lot of the tooling is now cross-platform: Visual Studio Code, Azure Data Studio, even Visual Studio and Xamarin run on MacOS!

The .net 5 announcement was very clear that .net core is the future and its been a while since you’ve had needed things that are windows only to build a non-trivial .net core application.

Yes, you can write a non-trivial .NET application on Linux. But if you take a non-trivial .NET application that runs on Windows, the odds are low that it can easily be ported to Linux. And there are almost no non-trivial .NET applications that weren't originally written for Windows.

The result is that if you work with .NET, you're going to be pushed towards Windows.

.NET 5 should supersede both Core and Framework IIRC

In the years since, I've encountered many stories that attempted to make use of that portability. All failed.

I've seen the promise of portability with other software stacks, and know how hard it is. I also know that taking software that was not written to be portable, and then making it portable, is massively harder than writing it to be portable from scratch.

So, based on both the history of .NET and general knowledge, I won't believe that .NET will actually wind up being portable until I hear stories in the wild of people porting non-trivial projects to Linux with success. And I will discount all announcements that suggest the contrary.

Microsoft didn’t have anything to do with Mono until 2016.

If you start from scratch with a greenfield .Net Core project there aren’t really any issues getting it to work cross platform.

While I’ll agree that anything that uses any of the advanced features of Entity Framework and MVC is not trivially ported.

So yes, even in a new project, there will be a pull back to Windows. Because virtually nothing is truly written from scratch.

You’re not going to mistakenly add a non .Net Core Nuget package to a .Net Core project. It won’t even compile.

Of course you can find Windows only nuget packages for Windows only functionality like TopShelf - a package to make creating a Windows Service easy. But even then, I’ve taken the same solution and deployed it to both a Windows server and an AWS Linux based lambda just by configuring the lambda to use a different entry point (lambda handler) than the Windows server.

You can even cross compile a standalone Windows application on Linux and vice versa.

I use a Linux Docker container to build both packages via AWS CodeBuild.

Would you also criticize Python for not being cross platform because there are some Windows only modules?

https://sourceforge.net/projects/pywin32/

async/await being the obvious example. Still no sign of it in the Java language, nor any expectation of it, unless I missed something.

On the plus side, fibers offer almost painless integration of synchronous code, while async/await suffer from the "colored functions" problem[1].

The price you pay for that, is the higher overhead of having to allocate stacks. If you don't support dynamic stacks which can be resized, you basically don't have a much better overhead than native threads. There are two solutions I'm aware of, both of them have been done by Go at different times: segmented stacks and re-aligning and copying the stack on resize. Both carry some memory overhead (unused stacks) and computational overhead (stack resizing).

[1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

The only tradeoffs involved, as far as I'm aware, are effort of implementation. There are no runtime tradeoffs.

> The price you pay for that, is the higher overhead of having to allocate stacks.

You have to allocate memory to store the state of the continuation either way. Some languages can choose not to call the memory required for stackless continuations "stacks" but it's the same amount of memory.

> Both carry some memory overhead (unused stacks) and computational overhead (stack resizing). Their "advantage" is that, because they're inconvenient, people try to keep those stacks shallow.

Stackless continuations have the same issue. They use what amounts to segmented stacks. "Stackless" means that they're organized as separate frames.

1. Is it possible to inspect the state of a 'parking' operation, the way you can in .Net with Task#Status?

2. So fibers run in 'carrier threads'. Is there a pool of carrier threads, or can any thread act as a carrier? I'm thinking of .Net's where this is configurable (ignoring that .Net 'contexts' aren't exactly threads), by means of Task#ContinueWith() and the Scheduler class. I take it from the following snippets that fibers can only run on the thread where they were created:

starting or continuing a continuation mounts it and its stack on the current thread – conceptually concatenating the continuation's stack to the thread's – while yielding a continuation unmounts or dismounts it.

And also:

Parking (blocking) a fiber results in yielding its continuation, and unparking it results in the continuation being resubmitted to the scheduler.

On a non-technical note, how do OpenJDK projects feed back into the Java spec and Oracle Java?

2. Configurable. A fiber is assigned to a scheduler that is, at least currently, and Executor (so you can implement your own).

> I take it from the following snippets that fibers can only run on the thread where they were created

No. A fiber has no special relationship to the thread (or fiber) that created it, although now there can be a supervision hierarchy thanks to structured concurrency: https://wiki.openjdk.java.net/display/loom/Structured+Concur...

> OpenJDK projects feed back into the Java spec and Oracle Java?

OpenJDK is the name of the Java implementation developed by Oracle (Oracle JDK is a build of OpenJDK under a commercial license). Projects are developed in OpenJDK (for the most part by Oracle employees because Oracle funds ~95% of OpenJDK's development, but there are some non-Oracle-led projects from time to time[1]) and are then approved by the JCP as an umbrella "Platform JSR" for a specific release (e.g. this is the one for the current version: https://openjdk.java.net/projects/jdk/12/spec/)

[1]: E.g. the Shenandoah GC (https://wiki.openjdk.java.net/display/shenandoah) is led by Red Hat, TSAN (https://wiki.openjdk.java.net/display/tsan) is led by Google, and the s390 port (http://openjdk.java.net/projects/s390x-port/) is led by SAP.

Does it impact things from the perspective of the JNI programmer?

> OpenJDK is the name of the Java implementation developed by Oracle (Oracle JDK is a build of OpenJDK under a commercial license).

Ah, of course. I'd missed that.

> there are non-Oracle-led projects from time to time[1], and are then approved by the JCP as an umbrella "Platform JSR" for a specific release

How do they handle copyright?

Yes. All existing blocking IO code will become automatically fiber-blocking rather than kernel-thread-blocking, except where there are OS issues (file IO; Go has the same problem). Fibers and threads may end up using the same API, as they're just two implementations of the same abstraction.

> Does it impact things from the perspective of the JNI programmer?

Fibers can freely call native code, either with JNI or with the upcoming Project Panama, which is set to replace it, but a fiber that tries to block inside a native call, i.e., when there is a native frame on the fiber's stack, will be "pinned" and block the underlying kernel thread.

> How do they handle copyright?

Both the contributors and Oracle own the copyright (i.e. both can do whatever they want with the code). This is common in large, company-run open source projects.

Doesn't this boil down to the native function blocking the thread?

How about the C API/ABI of JNI? Will there be additions there for better supporting concurrency (i.e. not simply blocking)? Or can that be handled today, with something akin to callbacks?

Sounds a lot like Erlang BEAM processes.

As someone who runs Windows and Linux about equally, in differing proportions over time, I do find it disappointing that some (b)leading edge JVM and Java features don't support Windows yet.

Seems understandable though. Java is primarily a tool for heavyweight Unix servers, after all. (This is of course an empirical claim, and I have no source, but I'd be surprised if I turn out to be mistaken.)

Makes good sense to go with the strategy of building an industry-strength technology before investing the time to handle Windows.

The hardest part that everyone struggled with was getting a Java environment up and running. Gradle, maven, ant... You almost need and IDE. Its almost like they don't want people using it. I stopped when I didn't have too.

Plus the acronyms. Ones I didn't know from your post:

AOT, GCJ, Excelsior, Graal, OpenJDK, JakartaEE

GCJ and Excelsior are really niche, even people familiar with Java ecosystem might not known them as they are mostly used for AOT ( Ahead of Time ) Compiling Java into a Single redsitrbutuamble binary in the early 2000s. I was writing RSS Web Server application then and was looking into how to do Client Side Desktop Apps.... UI toolkit was a bag of hurt for Java, and I gathered that is still the case today.

I think JakartaEE is really just a rebranded JavaEE.

I know Graal only because I follow TruffleRuby, which is a new JVM written in Java. And it has proved that optimising Ruby, once thought as impossible due to its dynamic nature to be possible.

What do you mean by "lurking"? Oracle is the company developing OpenJDK, and it will continue to do so. All our projects are done in the open, with lots of communication.

You may not remember incidents like why Jenkins was forked from Hudson, but Oracle is run by people driven by what they think they can get away with, and not by what is good for the projects that they have power over.

I have no idea what Oracle may do tomorrow, but Oracle has been in control of Java for a decade, and what it has actually done is 1. significantly increase the investment in the platform and 2. open source the entire JDK. So I don't know about the next ten years, but the past ten years have been really good for Java (well, at least on the server).

> Oracle is run by people driven by what they think they can get away with, and not by what is good for the projects that they have power over.

I don't share your romantic views of multinational corporations. Corporations are not our friends, and while they're made of people, they're not themselves people, despite what some courts may have ruled. But like people, different corporations have different styles, and it would be extremely hard to call any of them "good." I have certainly never heard of one is driven by caring (although what you do when you don't care may differ; some may be aggressive with licensing, some are in the business of mass surveillance, some help subvert democracy, others drive entire industries out of business through centralizations and others still drive kids to conspiracy theories). When you look at what Oracle has actually done so far for Java, I think it has been a better, and more trustworthy steward than Microsoft and Google have been for their own projects (Java's technical leadership at Oracle is made up of the same people who led it at Sun). And people who bet on Java ten years ago are happier now than those who bet on alternatives (well, at least on the server). This despite some decisions that made some people unhappy. You can like the good stuff and be disappointed about the bad stuff without some emotional attraction or rejection to these conglomerate monsters.

My opinion of the company and its products is more consistently negative than any other large company. And while you think that the non-Java world is suffering, I think you have some tunnel vision.

Let's just say that I am personally happy with my decision to stay away from Java. And the brief periods where I had to work with Java were misery. Languages have personalities as well as companies, and there is a reason that the startup world stays away from Java in droves.

You may have your own case of tunnel vision. I mean, sure, there are "droves" of startups that stay away from Java (many only to turn to it later), but there are also "droves" that adopt it from the get-go.

According to the statistics reported by https://www.codingvc.com/which-technologies-do-startups-use-..., Java looks like the fourth most commonly used language in the startup world, and its usage is not particularly well correlated with success.

Both Ruby and Python are more popular than Java, AND are better correlated with how good the company is. Your odds of being in a successful startup are improved if you are in those languages INSTEAD OF Java.

What about from the individual programmer level? Triplebyte did an article about how programming language and hiring statistics correlate. My impression is that their programmers are mostly being hired into relatively good startups, so it is a pretty good view of the startup world. That article is at https://triplebyte.com/blog/technical-interview-performance-....

Long story short, Java was the #2 language that programmers chose. Behind Python. Not so bad. But choosing Java REDUCED your odds by 23% of actually getting to a job interview. And for those got to a job interview, it reduced your odds by 31% of actually getting hired. By contrast Python IMPROVED those same odds by 11% and 18% respectively.

Apparently the startup world doesn't like Java developers either. You'd be far better off with Python.

Now I'm sure that you can trot out every successful Java startup out there. And there will be quite a few. But based on available data, not opinions, I did NOT express tunnel vision when I said that the startup world stays away from Java in droves.

Here is my understanding.

Java was designed to limit the damage that any developer could accidentally do, rather than maximize the potential for productivity. Which is an appropriate tradeoff for a large team.

It is hard to get good statistics on this, but the figures that I've seen in books like Software Estimation suggest that the productivity difference is around a factor of two.

This matters because it turns out that teams of more than 8 people have to be carefully structured based on the requirements of communication overhead. (A point usually attributed to The Mythical Man-Month.) This reduces individual productivity. Smaller teams can ignore this problem. The result is that measured productivity for teams of size 5-8 is about the same as a team of 20. But the throughput of large teams grows almost linearly after that. An army does accomplish more, but far less per person.

Limiting damage matters more for large teams. Which are more likely to be affordable for large enterprises. However being in such an environment guarantees bureaucracy, politics, and everything negative that goes with that.

By contrast startups can't afford to have such large teams. Therefore they are better off maximizing individual productivity so that they can get the most out of a small team. And using a scripting language is one way to do that.

For larger applications with multiple developers working in the same code base, the compile time checking of static languages is a god send. I would at least move over to TypeScript instead of plain JavaScript.

Oracle will likely pursue the most aggressive strategy they can get away with Java.

I don't believe Sun was suing Google, but Oracle did.

The fact that Google is switching to Kotlin is mostly a means to absolve themselves of the 'Oracle risk' - it's a big change surely, a decision not taken lightly.

The future of Java under Oracle is hard to predict but there's legit concerns Oracle will make things hard.

Google adopted it because, as they more or less said in the announcement, it was already being adopted by the community and it hugely improved development experience.

This is a problem when you are looking at hiring new people etc . This fragmentation is going cause issues just because people are hedging against Oracle future decisions.

In a perfect world Google should have bought Sun and the current version of Java would look at lot like Kotlin.

https://news.ycombinator.com/item?id=10951407

I don't think it was money, so much as the established culture at Sun (i.e. James Gosling: "Sun is not so much a company but a debating society). A more aggressive CEO/leadership/culture would have maybe raised the money to take on Google, or to take another tact.

So while you are right - and thanks for the reference - the issue here is what Sun was about, vs. what Oracle is about.

>What do you mean by "lurking"?

Referring to Copywriting API a while ago and the JakartaEE problem which has blown up on my twitter feeds. I understand why Oracle is trying to charge money, and I am perfectly fine with that, I just don't like they are using Copywriting API as the tool. And whatever problem it is with JakartaEE this time around I don't have time to follow.

So, I don't use a language unless it's open with patent grants and has a non-malicious owner. At this point, Wirth's stuff is probably legally the safest.

Rust, with Mozilla backing it, is probably not going to get you sued. Nim has potential given their commercial interests are paid development and support so far. As in, less greedy they are the better. Languages with community-focused foundations, such as Python, controlling them are probably pretty safe. Although it was risky, the D language now has a foundation. Although no foundation or legal protections, the Myrddin and Zig languages are being run by folks that look helpful rather than predatory.

So, there's you a few examples you might consider if avoiding dependencies on companies likely to pull shit in the future. Venture-backed, publicly-traded, growth-at-all-costs, and/or profit-maximizing-at-all-costs are examples of what to avoid if wanting to future-proof against evil managers turning it from good dependency into bad one.

Does it surprise anyone that this case was decided by the Federal Circuit? The rogue court most consistently overturned by the Supreme Court, which also is responsible for most of the disastrous software patent cases out there.

The only bright light is that the Supreme Court has reopened the question. Given how often they overturn the Federal Circuit, we have real hope that we'll return to the previous precedent. Which is that since matching APIs is a functional part of how code works, and things that are functional are by law not copyrightable, APIs are not copyrightable.

I mean, it has been big news, and it has already been nuclear war, with Oracle putting Google in a position to switch android from Dalvik (and successors) to OpenJDK. I agree that it could become a pretty horrible precedent (imagine if Microsoft forbade Sun from implementing Excel functions in StarOffice, or for that matter, if MS were prevented from producing Excel in the first place).

The things you're talking about are already protected by patents, and the copyrightability of APIs have nothing to do with them. At the very least, for something to be copyrightable it must be some specific fixed expression (a piece of text, image, video or audio). So the O v. G ruling applies only to actual (code) APIs; not to protocols (or REST "APIs") and certainly not to stuff that's already protected by patents (the distinction between the two may not always make sense to programmers, but it is what it is; for example, algorithms are patentable but not copyrightable, while programs are copyrightable but not patentable).

[1] https://github.com/java-native-access/jna

> State-of-the-art optimizing compilers.

LLVM provides coverage for many of the new languages that are hyped these days (with the notable and truly unfortunate exception of Go). LLDB provides an excellent debugger infrastructure.

> State-of-the-art GCs.

True, there's some good work there but I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency.

> Low-overhead in-production profiling/monitoring/management.

Correct me if I'm wrong but a lot of that is available in dtrace is it not?

This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages. It allows compiler engineers to focus on bringing what they do better and differently to the stack. It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest. All that time Go wasted developing assemblers for platforms should have been spent focusing on Go and letting LLVM handle it.

Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language.

Think about it, macOS is basically just various front-ends for LLVM. Apple's implementations of OpenCL and OpenGL, the Metal Shading Language and Core Image are all wrappers for LLVM. Swift is a wrapper for LLVM. Clang makes C and C++ fancy wrappers for LLVM. Rust is a wrapper for LLVM. Almost everything your mac does is a fancy front-end for LLVM. Even Safari was (until B3 backend) a fancy front end for LLVM.

> I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency.

That's fine, but it seems like giving up GCs comes with its own non-negligible costs, so much so that the two hardly compete in the same domains.

> Correct me if I'm wrong but a lot of that is available in dtrace is it not?

They have similarities (closer analogs would be https://github.com/btraceio/btrace and http://byteman.jboss.org/ than JFR), yes, but operate at different levels with somewhat different capabilities.

> This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages.

LLVM is popular, extremely useful, and quite cutting edge in its domain, but there isn't much of a "computer science" advancement as there is, e.g., in Graal/Truffle.

> It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest.

It certainly does, but there's a lot that LLVM doesn't give language designers that a JVM does, like GCs and high-level language interop.

> Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language.

I don't know if LLVM wants to operate at Java's level or vice versa. While LLVM may offer some basic GC and Java may offer "safe" LLVM with things like Sulong, I believe their main focus will be their own respective levels.

The language may be fine, but it has been appropriated into the worst sort of terrible programming paradigms one might imagine.

I read an old blog post about Spring's @Required annotation versus plain constructor injection and typed out a small example to get a feel for it – a simple class with one required and one optional dependency – which resulted in

23 lines of plain Java with constructor injection, or

16 lines of Java with Spring @Autowired magic, or

7 lines of Kotlin – no magic needed.

There was a period after 200x where developers managed to throw out a bunch of babies along with the bathwater when they rejected Java, UML, SQL, and everything else that was used in 199x. After all, these are all literally from the last century, so they must be "uncool", amirite? /s

The preference for dynamic or duck typing in the name of productivity has always rubbed me the wrong way. To keep it brief, my defense / elevator pitch for static typing is: "Slow is smooth. Smooth is fast" :-)

Those were the darlings ten years ago (along with CoffeeScript and Clojure). The pendulum has swung back towards types and now the hip ones are Go, Kotlin, Swift, TypeScript, and (to a lesser extent) Haskell, Hack, Reason, and OCaml.

> Java, UML, SQL, and everything else that was used in 199x.

There was the whole no-SQL fad, but lately, even here, I see a lot of people re-discovering and advocating the relational model. Postgres seems to be hotter than MongoDB today.

Much of what is good about Java lives on in Kotlin and Swift. I agree it is unappreciated with today's eyes. Few remember that it was Java that introduced much of the world to garbage collection, memory safety (!), optimizing JIT compilation, runtime reflection, dynamic loading, high quality static analysis IDEs, etc.

UML is garbage. A visual language designed by non-artists with no aesthetic expertise. It deserves to be forgotten.

Java is still continuing to lead on technology. In recent years it has introduced the world to low-latency, concurrent copying garbage collectors (C4, ZGC), partial-evaluation Futamura-projection optimizing compilers (Graal/Truffle), and low-overhead continuous deep profiling in production (JFR). I think that lots of people remember that, and care about those things, because Java is not only leading technologically but also in market share.

Well, if you ignore mypy and consider TypeScript distinct enough from JS to not count, sure, though TS is if anything more of an HN darling than bare JS (Really, none of those languages has been an HN or developer community darling in years, though Python—due to ML and data science—is less horrible uncool than Ruby and JS right now. (And, yeah, Ruby is left out of the “but I have static type checking available” list...till Sorbet is available later this year.)

> Most developers turn to C++, Java, or C#

I'd be surprised if more than half (most) developers using static typing use those languages and not others outside that set.

> I'd be surprised if more than half (most) developers using static typing use those languages and not others outside that set.

Really? I'd be surprised if it was less than 90%. What is the competition? Go, TypeScript, Swift, Scala, Kotlin, Rust (in rough order of my gut sense for how widely used they currently are)? These are all still very small relative to C++, Java, C#.

If you argue that C has static types, then I guess you're probably right. But it isn't really true that C has static types in the contemporary sense (which I think is perhaps better referred to as "strong" type safety).

C (like C++) is both statically and weakly typed; strong and static typing are orthogonal axes (dynamic but strongly typed languages are common.) If you mean strong and static when you say static, you need to take C++ off your list.

It's about C not having any generics or similar things (like C++ templates), so you need to fall back way more often on void*.

So on that axis Go is roughly as statically typed as C, albeit more strongly typed.

On the other hand C++ is more statically typed than C, but is about as strongly typed (afaik).

As it happens, among the statically typed languages, C++, Java, and C# are the top three, with C and TypeScript filling out the top 10 lineup.

That's not saying "more than half", but if you include C onto that list, I would definitely bet against your statement.

And yeah, as other commenters have said, Python is back due to data science / machine learning. (Though I'm hoping there will be a wave of adoption of tools like Julia and Swift for this in the near future; good static analysis will be nice for data science for all the same reasons it is nice for other kinds of software.)

Outside AI, Python is a really good scripting language for both Linux and Windows. My entire industry seems to run off of Python for process automation and analysis. It really is a lingua franca in this space.

Sure for core Java (OpenJDK), but what the future of JEE licensing and development? Even non-"enterprise" apps typically make use of some JEE stuff like servlets and JDBC. Is it really the "safe" choice when, apparently, the trademark agreements have just fallen apart?

https://headcrashing.wordpress.com/2019/05/03/negotiations-f...

Dropwizard and Micronaut are pretty good for getting a smaller and saner footprint. If you need more than REST, say you want a lean MVC-based web-framework, then Blade is also a good choice.

You can also choose not to use a framework and say use code-generation from a swagger/openAPI REST document and implement the remaining bits on your own. If your deployment target is AWS, you can also choose to leverage Netflix's fantastic set of libraries.

Java has tonnes of options, so you usually need to spend some time evaluating what goes into your stack.

Spring folks are actively involved with Graal. I see a lot of excitement internally at Pivotal. Watch this space.

In [this](https://youtu.be/7G_r1iyrn2c?t=3104) session, RedHat developer shows how Quarkus application is being scaled. Comparing to Node, it's both faster to respond to first request and have smaller memory footprint (half the size of node).

Quoting from the site: Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services.

It's a nice microframework which comes with built in health-checks, and metrics and it's also ops friendly because it deploys as a single JAR file.

> mvn archetype:generate -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=[REPLACE WITH A VALID DROPWIZARD VERSION]

Why is it that everytime I read something about Java I have a feeling it was not meant for humans ? Not as bad as C++ projects setup though, I'll give it that.

I have done a lot more Java than Javascript, so I feel the same about npm error messages.

I'm a big fan.

I, for one, am curious to see how Jakarta EE's current approach of what seems to be an internet-based, democratic semi-standard would work out, and if it can be better than both the JCP as well as more common centrally-controlled open-source projects.

Anyway, this is what Eclipse's director said on the matter:

https://twitter.com/mmilinkov/status/1125213654775889921

[1]: That post you linked to reminds me of those who blame Oracle for killing Solaris. Solaris is a terrific operating system, that was sadly killed by Linux long before Oracle acquired Sun. After a few years of trying, I guess Oracle decided they could no longer save it, and there was no point in continuing to throw good money after bad.

Yes exactly, I think that is what makes if feel like not the safest choice for many companies.

If I could just write code and have a simple package manager like NPM or even Go packages and not be hindered by trying to get VScode to work I would never look back. I just waste so much time trying to understand the ecosystem. I know that isn't a great excuse (not wanting to take the time to become an expert on tooling), but people who came into the professional space in the same time frame likely also just see it as an obvious path to just avoid all the cruft.

What I really want is to get a "lite" Java project like this up and running with all of the smart people's opinions in place that I can develop entirely in a lite editor (preferably without XML anywhere). Maybe something like Spring Boot would solve that but I have not investigated that yet.

Anyway, for me Java-the-language is fine. The tooling, at least as it comes with Android (looking at you gradle and all its Android plugins) is what makes me want to pull my hair out.

But again, you have to spend a month or so learning the shortcuts.