Rust Porting Begins For Intel's "e1000" Linux Network Driver

[mdedetrich]

I can guarantee you're mistaken and your believes like the one above don't represent reality.

Considering when on the topic of Rust you spent your entire time constantly negatively criticising it without giving it a benefit of a doubt (like all of the software engineers much smarter and with more knowledge on this topic then you) I can safely say that it represents reality quite well.

[cb88]

Considering when on the topic of Rust you spent your entire time constantly negatively criticising it without giving it a benefit of a doubt (like all of the software engineers much smarter and with more knowledge on this topic then you) I can safely say that it represents reality quite well.

I'd have to say if you get stuck up on syntax you could be the best programmer in the world but you can't speak but one programming language... not many companies will have a use for you. Some of the best paid programmers out there today, are ones that know "crappy" languages well.

Being adaptable and not OCD about things that cant be changed is a huge plus for any manager that is going to hire you.

[mdedetrich]

I'd have to say if you get stuck up on syntax you could be the best programmer in the world but you can't speak but one programming language... not many companies will have a use for you. Some of the best paid programmers out there today, are ones that know "crappy" languages well.

Being adaptable and not OCD about things that cant be changed is a huge plus for any manager that is going to hire you.

You can also argue that if the only criticisms of a language is its syntax then you have run out of other arguments and its bikeshedding at that point.

[Luke_Wolf]

While I understand what you are getting at, defining a functional programming language in such a way is not very useful because you can easily claim that Haskell is not purely functional due to unsafePerformIO or asynchronous exceptions which breaks the mathematical laws of functional programming.

Realistically speaking you have a spectrum, and people have argued that its the languages increasing ability to implement functional programming in an organic/natural way that allows it to be a "functional programming language". In this regard Scala and Haskell are more functional than Rust, since with Rust its difficult to implement functional programming constructs due to it missing certain features (such as HKT's - higher kinded types). Scala for example has a large amount of purely functional programming libraries such as cats/ZIO ecosystems which rival those of Haskell. These kinds of libraries however don't really exist in Java/Rust etc etc, its possible to program in such a way its not ergonomic/idiomatic.

Also notably while a lot of computer scientists/mathematicians, in terms of modern lexicon functional programming is not really the mathematical definition of function but rather the ability to treat functions (or more correctly subroutines) as values hence why lisp and its dialects is regarded as a functional language (as well as languages like javascript). This is why the definition of a purely functional programming language exists which is referring to the mathematical notion of functions and all if its implications (i.e. treating side effects explicitly as well being able to represent functions as values).

I take issue with it for exactly that point, functional programming on a purely philosophical basis is a dead end. At the end of the day things that break the philosophy of functional programming like side effects are a fact of life in any software of particular size. Trying to claim that interior mutability somehow solves the philosophical issues or that for_each(f =>a) is somehow different from for(var foo: container) is little more than mental gymnastics trying to salvage the honor of what was at the end of the day a bad idea.

The truth is you can write code that adhere to the functional programming philosophy in most languages, even C89, but things like tail recursion, first class functions, etc had to be invented to work around the limitations (and indeed tail recursion is basically cheating by turning functional code into imperative code to avoid blowing up the stack). Many of these features happen to be extraordinarily useful outside of the context of functional programming. However what modern "functional programming" does is it rejects the philosophy and adopts the features instead, philosophically adhering to established imperative programming practices, and there's nothing wrong with that... But there's a reason that while Lisp and Haskell are languages that people are very aware of (indeed I would propose that anyone serious about software development has heard of them and the praise thrown their way), very little software is written in either language compared to C or Python which came out slightly latter than the respective functional language. Meanwhile Rust in particular is seeing widespread adoption, and yet despite the features the philosophy of functional programming is rare to be found as you yourself admit to.

Perhaps it should be named something else to differentiate, but I do not feel functional programming is an appropriate moniker for modern "functional programming".

[mdedetrich]

The truth is you can write code that adhere to the functional programming philosophy in most languages, even C89, but things like tail recursion, first class functions, etc had to be invented to work around the limitations (and indeed tail recursion is basically cheating by turning functional code into imperative code to avoid blowing up the stack).

I wouldn't lump tail call recursion and first class functions into the same boat. Tail call recursion is just an implementation detail of the languages compiler, by that I mean if we had abstract machines/interpreters that didn't have a concept of a stack vs the current situation there isn't any actual difference in the code (its just that in one case a compiler/AST transformation is done in the generated format).

On the other hand first class functions directly effects the code being written (and hence what it means). You can compare Java pre 1.8 and Java 1.8 to see what I mean.

Many of these features happen to be extraordinarily useful outside of the context of functional programming. However what modern "functional programming" does is it rejects the philosophy and adopts the features instead, philosophically adhering to established imperative programming practices, and there's nothing wrong with that... But there's a reason that while Lisp and Haskell are languages that people are very aware of (indeed I would propose that anyone serious about software development has heard of them and the praise thrown their way), very little software is written in either language compared to C or Python which came out slightly latter than the respective functional language. Meanwhile Rust in particular is seeing widespread adoption, and yet despite the features the philosophy of functional programming is rare to be found as you yourself admit to.

I would say that you don't actually want a language that is philosophically pure because it ends ups becoming less and less useful. Even though I admire Haskell I personally have a love/hate relationship with it because its absolutely terrible when it comes to expressing some things. You can make an argument that successful programming implement enough of a collection of different paradigms to a degree that you can solve a wide array of problems in a sane way. I also have the same judgement of the various Lisp's although for different reasons (Clojure is an exception here because Rich Hickey made real effort in actually adding features such as defprotocol and STM to actual model problems that other Lisps weren't so good in).

This is why even with all of its warts I think Scala is the "best" (and by best I guess you can say "least bad") high level language. It has this very nice blend of OO/modules (modules in the ML sense, i.e. treating sets of possible undefined functions as values i.e. traits/interfaces)/functional programming that allows you to both elegantly and nicely represent and model most programming problems. To boot its also strongly typed which happens to catch a lot of problems at compile time.

Perhaps it should be named something else to differentiate, but I do not feel functional programming is an appropriate moniker for modern "functional programming".

I don't disagree with this but I think that ship has unfortunately sailed. I used to make a bigger deal out of this before but there isn't any point in arguing about it anymore, at least the "pure" moniker has taken hold so we can differentiate between the two in discussions rather than spending half the time arguing over terminology.

[Weasel]

But auto is one character longer. See how easy it is?

Except auto is only used when the type is not specified. And it means automatic type deduction. You don't type it when you specify the type.

In Rust you have to specify both let and the type of the variable if you don't want an automatic type deduction. Which is just cringe.

Also in JavaScript you can use "var" as well, AFAIK. Which is infinitely better than "let".

[Weasel]

You can also argue that if the only criticisms of a language is its syntax then you have run out of other arguments and its bikeshedding at that point.

Go use Brainfuck then. Clearly no syntax problems. Turing complete.

[mdedetrich]

Go use Brainfuck then. Clearly no syntax problems. Turing complete.

Well that is a reductionist fallacy if I have ever seen one

[bug77]

Except auto is only used when the type is not specified. And it means automatic type deduction. You don't type it when you specify the type.

In Rust you have to specify both let and the type of the variable if you don't want an automatic type deduction. Which is just cringe.

Also in JavaScript you can use "var" as well, AFAIK. Which is infinitely better than "let".

Go has worked hard to do away with any unnecessary cruft. And even in Go, you still have to write var i int. Seriously, it's just a style choice, let it go people...
every language has quirks, if you adapt, you wouldn't be bothered if you had to declare variables using [<###>].

[reba]

Also in JavaScript you can use "var" as well, AFAIK. Which is infinitely better than "let".

Since the introducion of "let" (and "const") you should never use " var" anymore in JavaScript as those are block-aware, which "var" is not and thus is garbage. Pretty docs for more info.

Also using let/var/val is important as it is a variable declaration which should not be mixed/overloaded with a variable definition.
Writing a definition/initialization/assignment "i = 1;" without a specific declaration "dcl int i;" is just bad code and a programming language that allows this is a bad code language. Always use declarations, even bash does this (keyword "local") and IntelliJ complaining to you if you don't do it (rightfully so)