Michael Yuan

author
+ Follow
since Mar 07, 2002
Michael likes ...
Python TypeScript Java
Dr. Michael Yuan is the author of 5 books on software engineering. His latest book Building Blockchain Apps was published by Addison-Wesley in Dec 2019. He is also the CEO of Second State, a company that focuses on bringing WebAssembly and Rust technologies to cloud, blockchain, and AI applications. Prior to Second State, Dr. Yuan was a long time open source contributor at Red Hat, JBoss, and Mozilla. Outside of software, Dr. Yuan is a Principal Investigator at the National Institutes of Health, with multiple research awards on cancer and public health research. He holds a PhD in astrophysics from the University of Texas at Austin.
Austin, Texas, USA
Cows and Likes
Cows
Total received
6
In last 30 days
0
Total given
0
Likes
Total received
6
Received in last 30 days
0
Total given
7
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Michael Yuan

There is nothing new in computer science. ;) I remember when Java servlets came along, everyone said "but Perl and C++ already do that!". When Hibernate came along, it is the same reaction "JDBC is faster and more flexible!" ...

The "hype" is that many new developers love it, and as a result, new libraries and frameworks will be written for those "new" languages that have the most mindshare. If you look at AI, blockchain, or even recent cloud computing frameworks (i.e., the serverless stuff), most people use JavaScript and Python. However, they are only using JavaScript and Python as "wrappers" or "glue" for applications -- most of the underlying libraries are written in C/C++. That's what gave rise to Rust and WebAssembly.

paul nisset wrote:After going though  getting the Second State example working  and reading the article "https://www.secondstate.io/articles/is-this-the-next-java-20200713/" ,there is nothing that impresses about this.
It's basically a node app that makes calls to server that runs compiled functions. The article says the "Rust is beloved by developers"  . I would counter the number of developers that it is beloved by is very few .
Maybe if you spend a couple months learning it ,you are forced to feel you love it but there was nothing in  the Rust documentation that made me think "Cool ! I need to know this".

I really don't see what the hype is . There is nothing there, especially if someone has worked with C or C++ before.

Thanks, Tim. For many years, the arguments for Java have been "it is fast enough for my use case (web apps)" and "it has the libraries I need". I do agree with them. And to your point, I do believe the JVM is fastest in many common use cases (billions of $$$ have been spent on JVM optimization).

However, the world is changing. If you look at several frontiers of application development:

* AI: there is hardly any Java here. C++ with Python or JavaScript wrappers are the dominant force here. Why? Performance.

* Serverless computing / Function as a service: Java is supported as an after-thought on those platforms since it has a very large memory footprint and cold-start is very slow. One of the key use cases of FaaS is frequent start / stop.

* IoT: Most platforms do not support the JVM due to large memory footprint and un-predictable GC performance.

* Blockchain: This space is almost exclusively Rust and Go. Why? because when developers create new ecosystems, they need to write all libraries from scratch, and Java is no longer their default or first choice.

So, while I agree with most of what you said, I do not believe Java's reign will last forever. For the new generation of developers, it is no longer the first choice.


Tim Holloway wrote:This smells like the old "Java is slow because it's interpreted" argument that became essentially meaningless many years ago. Probably over a decade past I ran across a benchmark where a JVM with JIT compiler actually out-performed C with the exception of the floating-point benchmarks.

Java is, of course, horrible slow for small apps like "Hello, world!". You have significant overhead in both time and memory to launch a JVM - although Oracle/BEA and IBM have both experifmented with less transistory Java environments. The JIT compiler will take its cut as well.

But the one thing that a truly high-performance JVM can do that no language that compiles to static code can is to dynamically re-compile code based on observed performance, thus ensuring a more optimal execution given the data and environment at hand.

For example, just about all traditional computers had a conditional branch statement that had two different execution times, generally shorter if the branch wasn't taken and longer if the branch was taken. A static compiler would generate code with that branch in a fixed context and that's where it would live forevermore. A smart JIT VM could monitor that code, note that the branch was being taken more often than not and recompile the bytecodes to ensure that branching was the exception rather than the rule. That's a micro-level optimization, but you can build up from there. And of course, with today's pipelined processors and virtual memory, there are more variables, since you want to reduce paging and "bubbles" in the pipes.

Languages like Rust and Go have their places. Some things really need a better environment than what C/C++ provides but are not suitable for execution in any sort of VM. That doesn't make them "killers", though. Just special tools for critical needs.

Stephan van Hulst wrote:Interesting. I might take some time out to try and create an application on SSVM.

I just want to point out to you that the general public seems to be unauthorized to view your Google Form.



Google form is fixed. Thank you!
Back in 2005, I had the honor of being voted as one of the very first Java Champions for evangelizing Java on the server-side. It is hard to believe now, but back then, most people are doubtful that Java could even be used in server-side applications. Isn't Java a niche language invented to run silly games, known as Applets, inside the Netscape web browsers? Isn't Java very slow? Doesn't it consume a huge amount of memory? Well, those doubts were well-founded. However, Java had one thing going for it. It is beloved by developers. The OOP language design, automatic memory safety, and cross-platform runtime (JVM) were revolutionary at the time. Server-side developers were just more productive in Java. The rest is history.

Since Java became the “king of the server-side”, a challenger technology would emerge every a few years to “kill Java”. It was Ruby-on-Rails for a few years, and then Node.js for a few years. Yet, those challengers had the same playbook as Java — they focus on developer productivity. They are fundamentally managed runtimes with different front end languages. They are too similar to Java to kill Java.

However, as we enter the post-Moore era, computer performance must come from more efficient software, where Java and JavaScript often fall short. Rust and WebAssembly provide Java-like memory safety, security, and portability to server-side applications while delivering high performance.

Read this article in full and discuss in this thread to win a Raspberry Pi 4 kit.

Or, better yet, everyone who completes a programming assignment wins a Raspberry Pi Zero kit.
I would say that blockchain is software. It is like a database or application server. You use it as part of the your software services. There are many use cases. Bitcoin and cryptocurrencies are big ones. But in general, it is a decentralized alternative to database and application servers. It is decentralized (no one can shut it down, no one can cheat) at the cost of efficiency.
Yes, the biggest barrier for Dapps (or decentralized apps) is the requirement for users to sign every transaction with a private key. Most users just want to use username / password, and do not wish to do the chores of private key management. That is why most dapps you see today are "money" related -- investment, gambling etc. There are really two ways to mitigate this. We discussed both options at length in the book. https://www.buildingblockchainapps.com/

1. Build key management into your client. That is, to provide a "wallet" in your web app or mobile app and help the user access the key transparently once they login.

2. Automatically generate keys for public apps. This approach is essentially what you see when you create and publish a Dapp from the BUIDL IDE tool:

http://buidl.secondstate.io/

To see a full example of "disposable private keys for public Dapps", check out this tutorial:

https://blog.secondstate.io/post/20191002-book-etc-en/
When we talk about blockchain apps, we talk about web apps that use blockchain as the backend. Blockchain provides an alternative to database and app servers. Why do we do that? That is because any database (e.g., MySQL) or app server (e.g., Node) can be shutdown or changed without notice. You can not change the data or code on blockchains without a record.

* Blockchain itself provides a ledger and can store data -- hence an alternative to databases
* Blockchain smart contracts can execute code logic -- hence an alternative to app servers

To answer your question about Bitcoin, the Bitcoin blockchain is designed to handle coin transactions not arbitrary logic. There is a scripting language for Bitcoin, but few people use it. Ethereum is designed with a Turing complete virtual machine at the center -- so it is much more like a generic "computer".

The new generation of Ethereum uses WebAssembly as its runtime. I believe that is a big step toward a much more mainstream application server environment on blockchains.
Thank you so much Jeanne!
Security is actually a very strong point of Seam. Seam has its own security framework that does much more than most other web app security frameworks. It provides permission-based, and role-based access controls at the object level.

I am not sure how the OS native SSO works -- does the browser pass through some kind of security token to the web app? Can you just make the browser remember the username / password and auto-login?
12 years ago
All the book examples are built with Maven. And I think Seam itself is built with Maven now as well. For Maven based hot deployment, you might have to write a special maven plugin that knows which files to copy to the app server ... You are very welcome to contribute this to the Seam project.
12 years ago
Conversation is like a web wizard. It is a series of web pages inside a http session. It is smaller than a http session. It is especially useful in multiple browser tabs, where all tabs belongs to the same http session.

Process scope lives longer than the http session. It is a business process saved in the database. So, it can survive server reboots. And it can have multiple actors each having its own http session.
12 years ago
What is the spring counterpart are you referring to? Seam-gen is an application generator that generates a skeleton web app that uses Seam ...
12 years ago
I might be wrong -- but I do not think Seam supports DWR. BUT, Seam Remoting is very similar to DWR. So, if you are coming from DWR background, you will find Seam Remoting a natural choice for AJAX.
12 years ago
MDB is "EJB", which a lot of people do not like. ;) Seam's JMS support allows you to hook up JMS into POJOs.
12 years ago