61–70 of 74 posts
Earlier quoted context omitted.
You have to have a metric for 'better'. If its 'utility' then yes something popular is better than something unused.
Thus my motto for PHP: It's better than nothing at all. Usually ... FML.
Earlier quoted context omitted.
Anyone who understands Rust's good points (and there are many) is probably already using Haskell. What compelling advantage does Rust have over Haskell to justify the cost of switching (and, more importantly, the cost of losing higher-kinded types, and of adding macros)? Manual memory management is unlikely to be enough.
There's a ton of people who aren't using Haskell and never will. It is a great language, but it isn't a language that will ever be really popular. Rust bridges the gap between industry C++ programmers with the ideas of Haskell. Sure you might not see a lot of codebases migrated from Haskell to Rust (not that there are a massive amount of anyway), but you will likely see C++ codebases migrated over to it, and Haskell…
Many of the advantages and disadvantages are the same: different syntax, weird sigils, an emphasis on immutability, a much more restrictive compiler, a strong type system, a new way of thinking about your programs. And it will take Rust a long time to reach the maturity and library ecosystem that Haskell currently has.
One might catch a few people who absolutely need manual memory management, I guess, but my experience is that this is often an excuse and those who are seriously interested in using another language find ways around the problem. For OS kernels and the like Rust has an advantage, but again that's a tiny niche. Rust's C FFI might be a bit better, but honestly Haskell's is rather good; I can't see that making the difference. And if you find the safety or the type system compelling, surely you've already moved beyond C++.
I'd like to be wrong - I'd like to see C++ programs moving into better languages. But I think a need for manual memory management is very rarely the real reason people are still using C++ - and if it's not that, what can Rust offer that wasn't already available?
I liked Smalltalk and saw it used well and used badly, but I don't think it is anything about Smalltalk that was the problem. It was the Smalltalk vendors that mostly screwed it up. Thousands of dollars per seat just wasn't worth it. It didn't help that some companies regarded it as "secret weapon" and kept its use hush-hush (I've heard the same thing about APL derivatives, but have no idea if that is just urban lege…
And for both Delphi and now .NET, there is significant market for third party components that look purposefully non-native.
Earlier quoted context omitted.
There's a ton of people who aren't using Haskell and never will. It is a great language, but it isn't a language that will ever be really popular. Rust bridges the gap between industry C++ programmers with the ideas of Haskell. Sure you might not see a lot of codebases migrated from Haskell to Rust (not that there are a massive amount of anyway), but you will likely see C++ codebases migrated over to it, and Haskell…
Let me put it this way then: why would someone using C++ who will be willing to migrate to Rust in the future not be willing to migrate to Haskell now? Many of the advantages and disadvantages are the same: different syntax, weird sigils, an emphasis on immutability, a much more restrictive compiler, a strong type system, a new way of thinking about your programs. And it will take Rust a long time to reach the maturi…
Rust has emphatically never been "Haskell with manual memory management". That conception is entirely incorrect, typeclasses or no. If you must frame Rust in terms of prior languages, consider it to be an ML with an extreme focus on zero-cost abstractions and pervasive, memory-safe concurrency.
I liked Smalltalk and saw it used well and used badly, but I don't think it is anything about Smalltalk that was the problem. It was the Smalltalk vendors that mostly screwed it up. Thousands of dollars per seat just wasn't worth it. It didn't help that some companies regarded it as "secret weapon" and kept its use hush-hush (I've heard the same thing about APL derivatives, but have no idea if that is just urban lege…
I'm not sure whether native look and feel is ever important point. At the moment I cannot think of any enterpise-ish application that does not ignore native platform look and feel. And for both Delphi and now .NET, there is significant market for third party components that look purposefully non-native.
I know a lot of enterprise apps go off into the weeds, but their success is driven by external factors. Successful tools really need to appeal to a broad group of developers.
I really think a native widget version of Smalltalk that included the database access could have done a fine job, but it always seemed with Smalltalk that the NIH syndrome was so high and they could build their own things better. Its like they didn't respect any platform they were running on.
Smalltalk was and is used for many advanced, super complex and difficult to understand requirements based systems. Much as Lisp and Scheme are. It sprang the ideas of full OO onto the programming community, it's guru's brought us Agile development techniques, Refactoring tools, ChangeSets (Git has this now), Everything is an Object and many other ideas and concepts prevalent in today's languages and tools. Many langu…
Earlier quoted context omitted.
Let me put it this way then: why would someone using C++ who will be willing to migrate to Rust in the future not be willing to migrate to Haskell now? Many of the advantages and disadvantages are the same: different syntax, weird sigils, an emphasis on immutability, a much more restrictive compiler, a strong type system, a new way of thinking about your programs. And it will take Rust a long time to reach the maturi…
The people sticking to C++ aren't using it for the sheer joy of manual memory management, they're using it because they either require or enjoy the ability to exert predictable control over programs in terms of both execution speed and memory usage. Haskell, being a lazily-evaluated garbage-collected language, offers little to these people. Rust has emphatically never been "Haskell with manual memory management". Tha…
When will Rust be pushed by an OS vendor?
I liked Smalltalk and saw it used well and used badly, but I don't think it is anything about Smalltalk that was the problem. It was the Smalltalk vendors that mostly screwed it up. Thousands of dollars per seat just wasn't worth it. It didn't help that some companies regarded it as "secret weapon" and kept its use hush-hush (I've heard the same thing about APL derivatives, but have no idea if that is just urban lege…
I'm not sure whether native look and feel is ever important point. At the moment I cannot think of any enterpise-ish application that does not ignore native platform look and feel. And for both Delphi and now .NET, there is significant market for third party components that look purposefully non-native.
Using Squeak as an example, it is very-much a virtual machine. If I want to work on a new project, I might have to create a new VM image or something. It's like an OS and language boiled into one thing, which simply doesn't work.
There are more classical approaches to SmallTalk these days, but most of the literature on the language is oriented toward the Squeak approach; dedicating half the bloody book to working within the OS! Just let me use Vim, I don't want to use your shoddy editor!
I worked on two Smalltalk projects in the early 90's at two different companies. Both efforts were abandoned for C++. Some of the issues we encountered at the time: * Numerical computation was too slow. Numbers used to be objects and all numerical computations followed object messaging. Ouch! This was eventually remediated but not before we'd dropped Smalltalk. * Garbage collection was S-L-O-W. Your workstation would…