I'm not writing rust yet, but I'm using a couple of tools written in rust, and based on my experience with it, when I need a utility I seek out one that's written in rust.
I'm using https://github.com/BurntSushi/ripgrep which is rg, like ack or ag (TheSilverSearcher). I've been using it for a few months, and I like it just a little bit more than ag, because I find its help and interface a bit easier to use. Like ag, it's incredibly fast.
Just this week I started using https://github.com/watchexec/watchexec to run rsync to sync from my mac to my vagrant box, because I was switching from using neovim on vagrant to using Visual Studio Code. It works great and has a very nice command-line UI.
Another tool that's written in go that I thought maybe was written in rust that's handy is https://github.com/shenwei356/rush which runs multiple commands in parallel, like xargs. I'm using it to transfer images between folders on s3 using aws-cli.
Based on this, and Servo, which is unstoppable with its Doge logo, I think Rust is going to be a very widely used language. https://github.com/servo
Edit: I remember part of why I liked rg more than ag - I got to use cargo rather than go, which is a much more intuitive and less opinionated way of downloading libraries than using the go cli. go is coming around though: https://blog.golang.org/modules2019
How much of it is because there's a reason (of sorts), to do a complete re-think, when you're porting tools over?
C and C++ have been stable for years, and so has all the little UNIX tooling that was built using them. People are excited by Rust, and take it upon themselves to re-build these tools, as they have well defined requirements and characteristics.
The reason these tools might be better is because thought has gone in to modernising and enhancing existing features. That might not be so feasible/ easily doable if you were juggling a decades old codebase to start off with.
I'm not sure what my point is, entirely... But ripgrep is good! I have replaced awk and grep with it, because it just feels more... user friendly?
EDIT: remembered my point. Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in?
> Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in?
I think it's a little bit of both for me.
The Rust tools tend to have a nicer UX (pretty-printing, colouring by default, with smart detection whether output is to a terminal, subcommand-oriented CLI a la git, etc). This is probably a consequence of nice library defaults but also a matter of culture. They also tend to be very fast. Again, Rust is inherently inducive to writing fast tools, but you also have to do things the right way.
I already found it and used it a couple times but forgot about it! It’s pretty neat. Gonna try using it for little things now that I’m using vscode instead of vim.
I was pretty disappointed in the lack of progress, but a few things come to mind:
1. IMO Rust has the closest thing in "imperative" languages to haskell's type system in a recently released "mainstream" language.
2. Rust brings an entirely new value (memory safety), and accordingly an entirely new hurdle called the borrow checker. This feature is so advanced that languages like Haskell are catching up (it's not a competition really) by introducing things like Linear Types[0]. That's really impressive.
3. Rust is targeting system programmers -- they move the slowest (as they should) in the ecosystem and are the most risk averse (as they should be).
4. Compare Rust to relatively recent systems-level languages (I won't name any), it's doing great.
5. Staying at the same place in the rankings is actually moving forward -- it may not seem like it, but it's hard to stay both effective, liked, and relevant in the world of programming languages (see: Dart).
I don't think rust is the kind of language to just shoot up the rankings -- it contains both higher level techniques that aren't quite mainstream yet and is targeted at a smaller community (though they're kind of going after web people with the wasm stuff).
I think rust is the kind of language that shows up to be consistently near the top of the rankings in 10 years (and I've said it numerous times but I think Go will displace Java and Rust will displace C/C++ where possible).
Yes, I will concede to a slight bias in favor of rust :).
Now I'm curious! What are other systems-level languages? I know Go was touted as one at the start, but that's definitely not where it's established a niche!
Julia? Nim? That's about all that comes to mind.
I wish I could read the Haskell documentation, but the code examples are straight up black magic to me. I really need to dig into some proper functional programming at some point!
I was mostly thinking of Dlang or Swift, but even those are actually not quite the same due to the lack of runtime. I think Go doesn't qualify as a "systems language" due to the inclusion of the runtime -- do people call Java/JVM languages "systems languages"?
The term "systems language" is almost certainly not precise enough. What I mean to convey was a language that you could write performance critical low level code in. In my mind though, Rust satisfies both that definition and the vaguer "backend service" (i.e. the thing spinning behind some interface doing the hard work in your architecture) -- it works very well from very low level all the way up to application programming.
If we're taking the second definition (vague backend-service-y) then Rust has lots more good competition -- if you can afford a runtime then the right language can give you some pretty good safety for less than the cost of learning Rust's borrow checker.
BTW I hear you on the haskell docs, how to start with Haskell is one of the hardest things. I personally took this path:
- Watching lots and lots of talks and attempting to read papers to just headbutt certain concepts over and over till I could somewhat begin to understand them.
I've found the secret is just to let the stuff go over your head at least 2-3 times until you start finding it useful.
But I want to stress that you don't have to write 5th order polymorphic dependently-typed whatever to get lots of value from haskell, here is some low hanging fruit:
- Haskell has the type system you thought/wish Java/C# had (i.e. `type AorB = A | B`, `newtype PositiveNumber = N { _posNum :: Int } -- guaranteed through constructor to be >= 0`). The ease with which you can have types express intent is mentally revolutionary.
- Behavior and object structure are separate, like Go's structs + interfaces or Rust's structs + Traits, and constraints (dependencies from one typeclass to another) are really easy to use -- ex. `class Thing a => BigThing a where { ... }` expresses the dependency that for a to be a `BigThing` it needs to first fulfill the requirements of being a `Thing` -- this is how you can force the existence of certain functionality on with polymorphism. Once you get used to this everything else (well, subtyping at the very least) will look primitive.
- Concurrent programming is amazing, both due to STM and the very good threading model (lightweight routines multiplexed to system threads)
- I will say that I think there's lots of low hanging fruit out there though -- Haskell has the type system you thought Java/C# would have. They really have "class" systems rather than type systems.
Maybe "manual memory management" is the better thing to zoom in on -- the large difference (and justification of the cost) between something like C/C++ and Java is the inclusion of the JVM and the weight of the runtime the Java brings with it.
C++ is safer but heavier than C, and Java is safer but heavier than C++. If C/C++ are systems programming languages but Java is not, then I posit that Go is also not a systems programming language. If use in resource constrained environments (where C/C++ can happily go) isn't a huge factor, then lots of things are systems languages that I wasn't considering
Wiki says:
> System programming (or systems programming) is the activity of programming[1] computer system software. The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or both (e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications).[1]
> System programming requires a great degree of hardware awareness. Its goal is to achieve efficient use of available resources, either because the software itself is performance critical or because even small efficiency improvements directly transform into significant monetary savings for the service provider (cloud based word processors).
Last sentence of the first paragraph seems to kind of two cases I kind of mentioned -- providing services to other software, being performance constrained, or both. Assembly/C/C++ are obviously often the only choice for the "performance constrained" use case, but not necessarily the best choice for the simple use case of "providing services to other software".
I would add that systems languages usually need to be consistent and predictable in their resource usage. Often this will mean manual resource allocation. Even if resources aren't constrained, you will still need the ability to write software which manages them with precision, and that's what systems languages are needed for.
> I wish I could read the Haskell documentation, but the code examples are straight up black magic to me. I really need to dig into some proper functional programming at some point!
Haskell definitely has a high early threshold that you need to get over. After that it's pretty much just fun and smooth sailing until you try to do something bigger, at which point there's another threshold.
The learning experience is the most fun I have had programming.
Just get the basics down and write some stuff. For a lot of things, you don't need to know how they work underneath in order to use them. It is helpful to implement functors, applicatives and monads for some of the basic data structures to get a feel for things, but then beyond that, just use what has been provided. Don't try to write your own monad transformers, just use the mtl library. Lenses are really complicated to understand, but really simple to use. The servant web library uses some high end type level stuff in order to work, but it is really easy to use. The compiler has your back.
If something just doesn't work and doesn't make sense, just move on and find a different way. After a while you will understand more and can return to it.
Don't try to understand the academic papers that have been written with Haskell. There is a really tradition of making the Haskell code as incomprehensible as possible. It will just get you down.
That is what I do: I use a subset of the language, don’t dive too deeply into the theoretical stuff, for anything imperative I find an example to follow, and just enjoy writing pure code in a comfortable interactive environment (VSCode or Emacs).
It is possible to just use Haskell ‘lightly’ and enjoy it. The only problem for me is that it can take me a while to understand other people’s Haskell code when I read it.
Yep. I agree reading other peoples Haskell can be a challenge. There is a real culture of making your code as terse as possible, which I think makes it easier to read once you know what you are doing, but makes it harder for beginners.
Luckily Haskells type system means that you can understand a lot about what is going on just by looking at the type definitions. Most code includes these. Although rather frustratingly, however, a lot of documentation doesn't include the type definitions. It is good to see languages such as Idris make it mandatory to include type definitions for all functions.
I don't think servant is "really easy to use" for beginners. Even though you might not need to understand how it's implemented, you have to work with type-level code which is no intuitive for beginners.
I guess it depends on your definition of "really easy". I'm not saying it's the easiest thing in the world, rather it is something that any developer can get if they are willing to bash their head against it for a time (and probably for not as long as they initially fear).
I still don't completely understand what is going on in the route definitions, but I have no problem with setting up a route.
Granted something like this is a gnarly type :
type UserAPI2 = "users" :> "list-all" :> Get '[JSON] [User]
:<|> "list-all" :> "users" :> Get '[JSON] [User]
But really you don't need to think of it as a type, just think of it as setting up a couple of routes. The ':<|>' is the route separator. ':>' represents a '/'. The bit after the final ':>' is what your function needs to return. If you get it wrong the compiler will complain at you.
> If you get it wrong the compiler will complain at you.
With an incomprehensible error message. Beginners will of course get it wrong.
I would rather put beginners on a path that makes them feel like the compiler is helping them, one of the core strengths of Haskell, rather than it just telling them No.
I get your point. I never found Servant a huge problem - it was the framework I started learning Haskell with and I found it was a really good fit. But - I can see others may not get it at first. It is quite different from other frameworks. Also, there are other areas where Servant gets complicated, getting and setting header values, cookies, returning redirects etc..
My original point was don't get bogged down in complicated stuff. If someone just doesn't get Servant, there is always Scotty, which is much more straightforward. Servant is not a reason to feel intimidated by Haskell.
Java certainly isn't perfect today and it certainly wasn't perfect when it gained the mindshare it has now. I think it's pretty impressive that Golang has achieved anywhere-near-JVM speed with easier concurrency primitives and ease-of-use in the time it has. What standard are we holding Go to that Java would have fit at the time?
If you meant Ecosystem-wise there are very few ecosystems that can compare to Java, since it's been around so long and has been the workhorse of (I think) the majority people being paid to write code for so long. If this was the way we picked languages, no new languages would ever emerge.
People are being productive in Go, and they're using it to write lots and lots of software. It's a good tool and is already production worthy, at the very least based on the fact that it's already running in production in many places and hasn't spectacularly failed anyone yet.
somewhat related rant
Also, I think Go changed it's official logo (from the gopher) in an attempt to fit this kind of language, and I think it's stupid. Who cares if their logo is of a worm -- if it's a good piece of software, then the right people (who value good software and craftsmanship over some appearance/facade of professionalism) will use it. People pay us to write good performant software, most of the time they wouldn't care if you wrote it in Brainfuck as long as it worked and worked well (of course, there's also the fact that someone has to maintain it, but let's pretend that doesn't exist).
Those functions aren't generic, so no bumping here, it stays at Java 1.4.
GUI libraries are just one of the easiest examples to come up with.
I can list many more missing features in Go land that we have been enjoying for the last 20 years in Java land to drop them just because of Google's cool factor.
Could you elaborate on some? Things that come to mind include generics, annotations, best in class IDEs, high performance concurrency structures, selectable GCs, heap analyzers, profilers, hot swapping, more expressive language, and a large library ecosystem.
rust could be targeting more then "systems" but its hard to write multithreaded networking services. thought maybe that changes soon?
it could also compete with go and python for command line tools but I think the mental overhead of the syntax makes it hard. i would rather write rust then go or python though.
Rust also feel like a very work in progress language, especially with useful features only in nightly often.
Hey I'm not a member of the rust team so take my comment with a huge chunk of salt, but this is changing very soon.
The rust community seems to be slowly but steadily working through a bunch of bigger use cases (all in the open as well, so you can see exactly what they're doing and why). For networking use cases, see projects like tokio[0] and hyper[1] to see how the community is moving (here's an awesome talk on it[2]). To me, it looks like the rust community is actually trying really hard to build things modularly and slowly from the start, taking tons of time to "measure twice cut once".
All that said, building networked systems in Rust is definitely extremely usable right now (and in many cases without nightly, I don't turn it on for any of my projects) -- maybe you won't find a gopher-server crate (rust's packaging mechanism) but for regular HTTP/HTTP2 you're going to find a lot of production-ready software (rocket[3], actix-web[4], tower-web[5]). I'd love to be pointed to some recent post where someone spelled out their issues writing some basic HTTP/HTTPS REST-ish backend servers (which I think is what the majority of people are writing/maintaining in their day jobs).
Side note (I'd love for someone to correct me), but generally when people want "performant" multithreaded network services, I take that to mean they want the combination of all system cores utilized and IO treated asynchronously -- in my mind this is basically all it takes, everything else is application/solution-space level optimization (parse your JSON a little quicker, maybe use a better data structure, do more things concurrently, etc). Rust has both of these things (system threads, libraries with async support) -- for example async/await syntax is landing soon, and from what I know the state of the art has progressed in this manner: callbacks->deferred/promises/futures->async/await -- rust is already 2/3 and async/await support is landing soon. And on top of all this -- rust is going to make parallelism & concurrency safer -- this is huge because while it might have been easy to `#include <pthread>` in C/C++, it sure isn't/wasn't easy to write correct concurrent/parallel code without the support of a runtime.
> I take that to mean they want the combination of all system cores utilized and IO treated asynchronously -- in my mind this is basically all it takes, everything else is application/solution-space level optimization
How are Rust SQL drivers for distributed computing with Oracle, DB2, SQL Server?
Uhhh I'm mega out of my depth on that subject -- I don't know. If the systems you're discussing can kick off the distributed computing by just receiving SQL, then there are definitely crates to do that in rust -- that's just a matter of sending SQL on the wire in the right format, right?
I can talk about some SQL drivers though -- I've used `postgres` (postgres), `rusqlite` (sqlite), `r2d2` (connection pooling) and others to great success building some relatively small codebases. For a more pre-baked approach `diesel` is the ORM that everyone is generally on if that's your speed.
Just in case I misinterpreted the question -- were you meaning to say that distributed computing using Oracle/DB2/SQL Server are examples of contradictions to my statement of "everything else" being "application/solution-space level optimization"?
Ahh OK -- so the first thing is basically whether there's a good oracle driver for rust that supports that feature... I don't know/don't think so? I searched "oracle" (https://crates.io/search?q=oracle) and found a bunch of drivers, but I'm not sure which of them support distributed transactions explicitly.
rust-oracle is listed on the shared programming interface page though (https://oracle.github.io/odpi), so maybe it's close if not already possible.
I doubt the second one more though -- how many languages even have an oracle driver with integration that tight to begin with? I struggle to find drivers that map PL/SQL user defined types to in-language types (even with something simple like enums)...
I'm definitely on super thin ice with C -- C++ is the surer bet. To be fair, there are also people who have been working tirelessly to improve C++ so they're not getting left behind either.
I do think eventually it could replace C though -- because rust with `unsafe` blocks still has the possibility of being safer than C. This could be a boon to security critical software, as long as the performance margin isn't too hard. Shops that have found ways to write safe C will likely never move (they don't need to), but new ones might pick rust where they might have picked C otherwise.
There is no chance of Rust "replacing" C++. There is no chance of it even cannibalizing many seats from C++. The net benefit is just not there.
But Rust is so overwhelmingly better than C, Go, Java, and C# for things people use those for, it may have a bright future replacing them, once its libraries and tooling mature enough. It will be competing with C++ on that, but there's room for both.
> With how much I hear about Rust on here, a little surprising to see it behind the likes of Haskell and and Perl!
Perl? Please, Perl was SO huge that I'm surprised it's as low as it is (which makes me suspect the methodology, actually ...).
In addition, if I remember from the TIOBE index there is the "Top Ten" and "everything else" where 10-20 is basically 1%+some noise and 20-50 is like .3%+noise.
> Kotlin is doing really well for its age especially, I'm guessing mostly used by Android devs (so far).
I wish the Android ecosystem would finally pick something and just stick with it. Having tooling, samples, and documentation that don't go out of date every 6 months outweighs any mythical "advantage" that switching language, build system, etc. actually gains.
> Having tooling, samples, and documentation that don't go out of date every 6 months
This is exactly why I didn't stick with Android for too long. Everything's too... in flux, but in a weird way.
"YAY, Google released this feature I've been dying for! Can't wait to use it in 4 years, when enough phones actually support it :)". It's either that or have API level dependent code.
Maybe Dart will fix some of these pains, by abandoning all they have built up? It is Google, so I'd say it's unlikely, but still.
Hell, I was trying to build an analog clock widget as a tribute to a certain sports team, and Google had deprecated the AnalogClock class. Its successor was, well, nothing. So a few community efforts took its place, and the fragmentation only got worse. Thanks, but no thanks!
Dart? All the cool kids use Kotlin, now, dontchaknow.
The only good part about Kotlin getting entrenched is that JetBrains is MASSIVELY invested in not letting Google switch to something else--so we may finally get some stability for a change.
> In addition, if I remember from the TIOBE index there is the "Top Ten" and "everything else" where 10-20 is basically 1%+some noise and 20-50 is like .3%+noise.
I think that's what we're seeing here but the graph isn't really making that clear. I doubt Pascal is used nearly 50% as much as java (unfortunately) for instance, it's a logarithmic scale.
Here’s a random question on Kotlin, hopefully not too controversial...
I now use Kotlin on Android, and it’s mostly a tidied-up Java that’s slightly better in every way. The one big difference is checked exceptions -- Kotlin doesn’t have them.
My question is, do Kotlin users prefer unchecked exceptions, or do you find yourself avoiding exceptions entirely now? Or even dropping back to Java when you need exceptions and you want compile-time checks?
I find myself mostly trying to avoid exceptions entirely in Kotlin -- maybe not such a bad thing!
If I want an exception, then I don't want it checked otherwise I have to handle it at every layer in which case I may as return a nullable object and handle that.
I generally find that I avoid exceptions, but where they are necessary I try and catch at the right level to handle them.
I don't think checked exceptions have many defenders left... even among their original proponents. And no language (at least no significant one) really copied Java in this regard, as far as I'm aware.
I can't speak for Kotlin users en masse, but personally I don't miss checked exceptions one bit, same as I didn't miss them in C#. And I've never encountered the practice of "dropping back to Java" for checked exceptions of all the reasons.
A compelling way of emulating the presumed benefits - without the bad parts - in Kotlin would be to go sort of functional and use a Try return type from Arrow-Kt: https://arrow-kt.io/docs/arrow/core/try/
I'm against using exceptions for flow control (that's nothing else but "goto" in disguise), and against handling exceptions far from where they occur.
I would deliberately throw exceptions as a "fail fast" safety switch, when I actually want the thing to burn down in flames. That's typically about violating some sort of a contract which indicates an implementation error - like an illegal argument. In such case to have them unhandled is sort of the point.
I found that following these principles by itself leads to a very limited role of exceptions in code.
I have to question how valuable it is to include stack overflow in equation. It implies that all languages suffer the same rate of problems for which people need to seek out help.
IMO, it's extremely reckless for this type of ranking. Most people who only seek 'coding' as a means to an end end up in JS, which would lead to an explosion in that section from folks still learning. Most ASM and to a lesser extent C programmers see it as a last resort...at least I do.
The graph shows SO vs GH rank, and if I'm reading it correctly it seems like C is slightly more popular on SO relative to GH while JS falls pretty much on the line.
Wouldn't that imply that C programmers resort to SO more often than they publish code on GH compared to JS?
Sure, I was a bit surprised by that. But, there are things to consider. JS is by nature(well, until Node) open source and has a generally younger base, both which would pad its GitHub numbers.
C has two big areas I think - Linux/open source software, and embedded work. A lot of open source projects in Linux land are for whatever reason not in Github. Heck I still see sourceforge a lot. Embedded work is likely done for a company and of course wouldn't be in Github.
While not 100% reliable, more questions in stackoverflow does indicate higher probability of the language being more popular, if you think in Bayesian network terms. And they call out all such caveats very clearly. Any "ranking" of programming languages is going to be flawed in some way or the other. Using only the github data might skew it towards more recreational languages and hide the enterprise languages, for example.
Not to forget that many students will use stackoverflow to ask questions. Which means that languages being taught at uni have a higher ranking (Java, Python and JS come to mind).
both GH and SO are probably not representative of the industry.
But for things like Rails, most of the questioned were answered already and likely wont grow in any place. I wonder if PageView for questions ( How many people were checking in for each PL ) and a mix of number of questions would be a better indicator for popularity of languages.
Just because something is tagged with $lang doesn't mean it's an issue with $lang, it can be a library specific library in $lang or "how to do X in $lang" for someone new to it.
I'm building internal apps with Javascript (Vue + vanilla) and Go. Both Vue and Go have good documentation. As a result, I'm not using Stack Overflow nearly as much as I once did.
With Go especially, my default move when I have a question, is to go to golang.org/pkg and find find the package I'm having issues with. Assuming it's a standard package problem, of course. The built in editor for examples is really great. I can run a little test quickly, and move on.
Good catch. Really makes you question the validity of their methodology. Although I suppose you could argue there isn't a single dialect of SQL in the top 20.
Are people producing SQL as an independent language in a separate repository or even a separate file? Since this ranking is largely based upon Github there would have to be SQL language files to make the cut.
Yes. We have thousands of lines of code in MS SQL procedures (each in its own file in our repository) because that's the only server-side language supported for customization in our CRM system.
I’ve never seen a community put so much effort into building an ecosystem as Rust. They have working groups for everything, they’ve slowly won over some extremely high profile programmers, and they’re taking on the areas of computing that are the hardest to solve as a manually memory managed systems language. Hats off the team, and I’m excited for all the game changers that are still in the pipe like the faster debug compiler.
After a lot of languages that are just rehashes of what we’ve already seen, or just a different subset of features, Rust is a languages that actually feels like it’s from the future that's finally going to start moving us forward after a lot of stagnation in industry while PL theory has continued to move forward.
If you haven’t given Rust a shot yet now is the time. You can get rust up into the top ten. :}
I wonder how this would look like taking into account language-specific user forums. I do not know about other languages but the Rust users forum is very active. The popularity on StackOverflow is probably dragged down by this, although I do not know to which degree.
Me neither, but that effort's not visible in their rankings, because it's not even in the top 20, nevermind top 10.
At the end the day it's platforms that move languages, not posting on HN and reddit.
They quite brutally damned Rust with faint praise in the article: "It’s also worth noting that even if Rust never gets much beyond where it is today, it’s still ranking higher than well known languages such as the aforementioned Clojure and Groovy, as well as CoffeeScript, Dart or Visual Basic. Not bad for a systems language."
VB6 is still going strong. As answers to most vb6 questions are available on the web since forever, people rarely ask vb questions on stackoverflow.
If you look at vbforums.com you can still have 500+ people at any time viewing the "vb6 and earlier" forum. And that's just one of many vb forums.
MS basically killed it, in 200x when the VB.NET snafu happened. I assume 100% of the VB work is legacy at this point and since solid architecture or design principles were never this language's strong points, it can't be particularly exciting legacy work either.
It's basically a career and technological dead-end.
You could say the same about COBOL. Just because it's "dead" doesn't mean that businesses don't have tens to hundreds of thousands to even millions of lines of code hanging around in these "dead" languages.
While it may not be exciting work, not every programmer is looking to do the latest and greatest thing that will appear at the top of HN. They make good money because the business knows paying someone well to maintain it is better that paying a team to rewrite it. That's why one of the issues with COBAL programmers is retiring and passing on, not leaving to go to a NodeJS shop.
These ranking aren’t something to take very seriously. They are ballpark estimated at best, and a better measure is growth of the community and adoption in larger open source projects that people actually use.
I can only assume you're joking. VB was never respected, it had a reputation back in the day of being the tool of choice for shoddy drag & drop Windows GUI apps.
On Windows C++ was the tool of choice and Delphi was kind of a secret weapon for GUI development. Then C# happened, and MS unceremoniously flushed VB down the drain. The VB community was outraged about VB.NET...
I use Rust almost exclusively for my side-projects now, and it has given me (as a guy who spends 2 days to find the Right Way to do a thing because this one hand-waved line in a tutorial just gives a bad smell) much joy and taught me a lot, but as professional, slow adoption in the industry makes me nervous. I have decent experience and background in my current tech stack to easily find a well-paying job, but if something happens to it, or to particular industry it's relevant to, I want something to fall back on; I've seen too many developers drift into a comfortable numbness of stagnation (ActionScript, anyone?). And yet, Rust jobs are extremely rare, and each one attracts a lot of VERY motivated and skilled candidates eager to start writing Rust full-time; and quite frankly, while I think that I'm a decent developer, I don't consider myself among this 1%.
So, I'm curious: how does HN see this situation going forward? Where will Rust find widespread industry adoption, and what can Rust community do to bring this forward?
The thing about getting comfortable is rust is that even if the entire ecosystem burns up in ashes, you can still get a decent job switching to C++. Learning and using rust makes you a good systems programmer in general, not just at Rust.
Having said that, I don't think the rust ecosystem is going to go up in flames anytime soon, but lack of professional application at the moment doesn't bother me too much.
I'm not so sure that it will find widespread industry adoption. I've been eyeing job boards for 1-2 years now, looking at what kind of Rust jobs are available: there's few of them, mostly start-ups.
Furthermore, as you mentioned, there are many very motivated candidates competing for those jobs.
Some bigger companies are supposedly using Rust (Amazon, Google, MS) on some projects, but these companies have so many things going that they are likely to use most languages in some kind of project. I've also heard that there are several "invisible" Rust jobs, only available through connections - but these are irrelevant IMO.
And then there are the jobs where one is obviously not using Rust, but they mention it to score points or dangle it as a possibility.
Until I see a strong market for Rust skills, or my own employer offers interesting Rust projects, it doesn't make sense for me to invest beyond learning the basics. Funnily enough I'm looking into Go now - its job market is one-sided and quite anaemic, but it offers some nice technical benefits and is a piece of cake to learn.
Also some of the companies adopting Rust, like Microsoft and Google, are also the companies with a couple of key people seating at ISO C++, and pushing for adopting Rust ideas into C++.
The lifetime profile is basically nothing more than a few lints. There are systematic reasons why C++ can never get the memory safety features of Rust without breaking compatibility so much that it won't be C++ anymore.
Really, I do like Rust, but you should adopt another strategy to win the hearts of C++ devs than throwing such jabs.
Show them to create a secure COM component to integrate in .NET can be easier than writing it in C++/WinRT | C++/CLI, using the same VS/debugger integration while being safer, for example.
C++/WinRT and C++/CLI are not memory safe. Rust is. I don't see how Visual Studio, debugger integration, COM, and .NET are relevant: one is safe and the other is not.
As stated, "you should adopt another strategy to win the hearts of C++ devs".
Repeating ad infinitum in every HN thread about C++ improvements regarding safety, that the only path to enlightenment is rewriting the world from scratch, without any regard for the loss of productivity, tooling and libraries in doing so, always hand waving them as minor inconveniences, is trying to catch flies with vinegar, but I guess I am wasting my Latin as we say back home.
I'm simply saying that modern C++ is not safe (and it will probably never be). If you write C++ at scale, you need to accept that you're going to ship memory safety bugs.
I've said many times there is a legitimate reason to write C++. If you understand you will be shipping memory safety issues, but the advantages of C++ outweigh the memory safety issues that you will ship to production, then I can't argue with that. I've seen game developers argue as much, and that's legitimate! Maybe, for your use case, memory safety problems really don't matter (or don't matter enough to outweigh C++'s other features). But it doesn't do anyone any good to sugarcoat the fact that C++ at scale virtually always ends up with memory safety problems, and while there have been many mitigations there has been no effective solution so far.
Agreed, but until Rust actually provides good coverage for many C++ uses cases, like COM/UWP on Windows for .NET apps with Visual Studio mixed debugging and GUI designers, sounding the safety trumpet without anything else to offer won't do it.
Maybe it will change after the HoloLens/FF project, however today is not appealing to many Windows teams.
The challenge for Rust is that most of the people that are proficient at systems programming are already proficient in modern C++. For those developers, any advantages of Rust do not outweigh its disadvantages in practice, so there is little incentive to invest in changing languages.
Rust can best grow its developer base by growing the number of new systems programmers, as they would have less to lose by using Rust and would be less likely to notice its limitations. The challenge here is that becoming a competent systems programmer is much more difficult than learning a new programming language, and there is a chronic shortage of developers interested in systems programming.
If we were still using classic C++ (i.e. C++03 and earlier) then I think Rust would have a real chance. The rapid evolution and adoption of modern C++ has fixed many (most?) of its major weaknesses.
Personally, I use Rust for things that are very far from systems programming - web apps, game development and small utilities for now (although I'm eager to at least try app development on it, when it gains at least minimum amount of support). That's the beauty of Rust for me: perfomance and correctness of a system programming language that is actually usable for product development.
I don't know where you'd get the idea that everyone who knows modern C++ prefers Rust. I'm not the only one who knows how to use modern C++ and usually goes with Rust instead. In my opinion, modern C++ is less safe than classic C++, because it adds more ways to get use after free (e.g. lambdas).
Modern C++ is not memory safe, and there is no way for it to achieve memory safety without either significant runtime overhead or breaking compatibility so much it won't be C++ anymore. The features in modern C++ are nice, but they don't solve my problems.
The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code. Are they now of mainly theoretical importance? I can't answer that definitively, but I can say it has been many years since I had a bug in C++ code that using Rust, instead, would have prevented. My bugs are specification bugs. Memory bugs just are not on the radar. But coding Rust takes me enough longer than C++ that I can't justify it.
Perhaps the driving force demanding memory safety isn't for one's own use, but rather the hope that the code one depends upon, written by other people, will get better. I.e., I write good code, and you write good code, but God forbid we have to rely on Microsoft, Google, Mozilla, and Red Hat monkeys to write good code! That's a legitimate desire, but it doesn't drive much personal adoption. Meanwhile, the PITA factor -- borrow checker not happy! "&" required! "&" forbidden! -- interferes with personal adoption of Rust.
And C++ keeps adding features. Not to fall increasingly behind, Rust needs to multiply its adoption rate. I don't see how that could happen. C++ is already good enough, so Rust can't cannibalize significantly from C++ coders. Rust is enough better than Go, Java, and C# to be worth a significant effort to switch, if users of those languages could perceive it. The greatest benefit to the world derives from driving people off C -- to Rust or modern C++, it matters little which.
> The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code.
That's easy to answer. They do. Any look at a CVE list for a browser will confirm this. These browser engines are, by and large, written in a modern style.
Why would someone use Rust over Java/Kotlin/Scala/C#/F#? Macros would be a small improvement, but at the price of reflection (JVM has Clojure for this). If I was using one of those languages, I don't really think the performance gain from moving to Rust would outweigh the added mental overhead, cost of learning new libraries, or developer scarcity.
I would use Rust in place of C++ or C in a heartbeat (and I would probably pick it over Go until they have generics), but I wouldn't use it in place of those other languages for the same reason I wouldn't use C++ in place of them. They're already managed, and I wouldn't have used them in the first place if I needed Rust's performance.
I have many years of experience with large-scale C++ projects at multiple companies, and have written >100kLoC of modern C++ personally. I've seen thousands of bugs come and go. Memory safety bugs are vanishingly rare in the code bases I've worked on, and in all those years the handful that I recall were created by people new to C++ (usually cross-trained Java programmers). It is difficult to create memory safety bugs in idiomatic modern C++, and achieving this has no meaningful overhead. Memory safety is important but Rust proponents have constructed a bit of a straw man with respect to modern C++. Use that argument against C or classic C++, where it has more relevance.
At the same time, modern C++ also has advanced and valuable safety features that Rust does not have e.g. the enormous amount of compile-time verification and complex type construction that is possible. I find these to be far more valuable because the kind of bugs these catch are more common in practice. None of this is automatic but it is trivially enforceable as coding style, and many companies do.
The idea that C++ code bases are necessarily littered with memory safety bugs is nonsense. For people that have been writing this kind of code for a long time, avoiding those bugs is largely automatic and effortless. And you don't have to do violence to your data structures to achieve it. I can see an argument for someone coming into C++ from a language like Java but for experienced C++ programmers the value is dubious in practice.
There may be compelling technical reasons to use Rust over modern C++ but you'll have to do better than automatic memory safety, particularly given the safety and capabilities that would be sacrificed.
I also have many years of experience with large-scale C++, and my experience is very different from yours. The difference, I suspect, is that browsers are actively attacked, via fuzzers and so forth. When you have contests like Pwn2Own targeting you, it's very eye-opening how many memory safety bugs you are shipping, even in fancy modern C++.
(I also disagree that modern C++ is safer than classic C++. Modern C++ adds more invisible ways to get use-after-free, which is pernicious.)
is there a chronic shortage of developers interested in systems programming? I believe most programmers prefer to do systems programming instead of business apps.
Developers may have the interest but they don't have the necessary skills nor invest the time to obtain them. Systems programming requires a deep understanding of how real-world hardware works and interacts with code. This seems to be rare expertise these days, even among nominal systems programmers.
So for "Popularity Rank on Stack Overflow" axis, I would replace the word popularity with attention. In addition to general engagement and use, a language getting more traffic/tagging there may indicate less quality documentation, more niche use (and less answers/tutorials from other sources as a result) or maybe tend to draw in (for many potential reasons) less experienced developers who are looking for active guidance or maybe the language generally has weird or non-intuitive patterns more likely to generate _wtf?_ type feelings that route you directly to stack overflow and onward to conspiracy sites from there.
The "Popularity Rank on GitHub" is probably more accurately measuring popularity in the popular sense of the word. That's especially true because the GitHub archive used for the data only offers info on public repositories and even then I'm curious to know how it reports for multi-lingual repos (does LOC win out, do repos get associated with multiple languages?).
Personally 90% of my commits over the past year have been to private repos for work. My public commits are in languages I look forward to using and learning outside my 9 to 5 because they interest and they offer a nice change up (ie PureScript and Rust lately).
I'm super stoked to see FORTRAN is riding solidly at 60% for both metrics, regardless of what those metrics truly measure. ~40 public commits in the last 24 hours! Check it out:
Off Topic PostThought:
Seeing JavaScript at that top corner and the amazing
surge over the past couple years of Rust has got me
thinking that when it comes to the art of programming
languages, Brendan Eich is a (if not the) seminal
artist of this time period.
Learning JavaScript is when what Dostoevsky,
Kierkegaard, Sartre and Camus were all trying to
communicate really hit home for me. Meanwhile a recent
foray into Rust is reminding me of the first time I
read books like Tolstoy's Anna Karenina, Borge's
Labyrinths and Steinbeck's East of Eden.
To me it's pretty amazing that the same person has
played pivotal roles in two languages that are both a
joy to write and reason with and for completely
different reasons.
The official docs are good but not comprehensive, and hard to navigate. Once you start googling around you get a random mix of third-party docs for various versions. It’s not at all obvious what’s outdated and what isn’t.
As an example, I had to write a little code to connect some Swift and Obj-C code the other day. (I don’t use either one regularly.) It was very hard to find good up-to-date docs on how Swift/Obj-C bridging works.
While my experience doesn’t match up with that, if it were true the fact that these “overlays” are both required and fragile is most definitely an issue with the design of Swift.
I tried to create a simple tool to retrieve a JSON reply from an API and display the results. Piece of cake, right?
Took me a day of debugging and hitting my head on several objects before I figured out that none of the half dozen tutorials I found were made for Swift 4.x.
I think the most of the problems comes from the fact that some of us are trying to learn Swift now after it has gained some popularity.
Searching Stackoverflow keeps coming up with answers that are now obsolete and while it is usually not very hard to port old StackOverflow answer code to new Swift, it's still annoying to keep running into that problem again and again.
Easy, Flutter is the last hope to make Dart relevant outside Googleplex, being dragged into Google's internal politics of Fuchsia, Android, ChromeOS.
Less mature than every cross-platform mobile UI framework that are around since iOS and Android have won the mobile market.
At the same time Fuchsia how has a UI composition engine, where Flutter is just one option among many (Scenic) and they are toying with a Rust based one (Fuchsia-ui).
Being burned by Dart 1.0, I will only take it seriously when it officially gets adopted by the Android team.
Dart was rejected by the community it was aimed at, Javascripts devs (and for pretty dumb reasons, I don't have much respect for either Javascript or its devs).
Google understandably took the opportunity to reboot it.
None of this is the same as dropping it, which for sure would merit "being burned".
It's now a modernised and slick version of Javascript (minus the functional, which no one uses anyway) with a full Android and IOS framework and extensive and properly documented libraries. And it's opensource.
At this point it's not possible for it to be 'dropped'.
I haven’t seen this argument about about open source projects in a long time, so i’d like to respond :
Beeing open source only means an organisation, or a group of developers, with the capacity to handle a project the size of flutter + dart, could do so if they wanted to.
Which means basically noone, except maybe in China, because nobody could have the firepower to deal with something this big ( maintain and even harder have it evolve) for free.
That argument applies to something like Linux. Here we are talking about a language and wrappers and an essentially completed framework (granted new ideas mean no framework is every completed).
And unlike a google service, which requires continued resource usage and high cost, flutter+dart has low needs. It may get outdated, but it can't be disappeared like other dropped google projects.
In any case, Unless Dart+flutter becomes an undesirable competitor to another google offering, there is no reason for Google to drop it unless it fails to get sufficient adoption. But I think that's unlikely.
Javascript devs are widening their horizons these days (as opposed to their rejection of Dart 1.0), and Dart only needs a few of those javascript devs to take an interest. The framework is an easy crossover for many of them, with an almost instant access to app development and little commitment needed to spin up.
Dart still has a long way to go as a language to catch up on the recent trends of statically typed PL (rust and swift come to mind), flutter needs constant update for every release of both iOS and Android to make sure their native theme are up to date and that they offer a decent equivalent to any new GUI component those platform release.
Just look at how long it took to get a correct map on flutter (and i don't think they've catched up yet).
I think they took a very good direction from a technical point of view, to recode everything from the lowest level possible, but that kind of approach requires a tremendous level of commitment.
Languages don't need to keep up with trends to stay used. But updating languages is the fun stuff; there won't be a problem with volunteers for that especially at universities. All the hard work has been done, unless an update would require a complete rewrite of the compilers which, sure, isn't likely.
Flutter needs an update once a year at most, and is mostly cosmetic and a bit of wrapping. Again, the heavy lifting has been done.
Coding from the bottom up....has been done.
I think you may be overstating the 'commitment'.
What we need to keep in mind here, is the context, that dart/flutter is easy access - it's no Angular or Cocoa - and that no sane, mature dev programs in only one language and one platform unless it's legacy.
We're not talking about a massive commitment from a dev, so talk of 'being burned' by Dart 1.0 is already a bit of a headscratcher when google didn't drop it, rather changed up and arguably improved Dart. How can that be called 'being burned'. For instance, dropping the need for 'new'. So, sure, it makes the code slightly less readable, but it also opens Dart to neat code and even maybe DSLs. Then they added Flutter.
Dart was rescued from being completely dropped by AdWords team, while key designers like Gilad abandoned the project not happy with how things were going.
For what it’s worth: According to google trends [1] the number of queries for (and the interest for) Python has surpassed JavaScript and is on a par with Java. And looking at the Alexa rank of the websites for Python [2] and Java [3]: Python‘s website has much more traffic.
Google queries is a terrible metric though. If a language has good documentation and great support in popular IDEs you would expect more people to use it and the number of searches to drop.
I think it's a bit of a stretch to call java.com "the website for Java". I end up on python.org (or at least docs.python.org) often enough. I never go to java.com. If I end up anywhere on the "official" Java websites, it'd rather be docs.oracle.com/javase/...some-doc...
I roughly interpret the graph as anything being below the line leaning towards the "getting things done" camp and anything above leaning towards "academics".
This is a bit distorted because FLOSS projects are favored (there's lots of "getting stuff done" code that is not on Github) and some languages have great communities outside Stackoverflow (Rust).
Prolog seems like a good example. It is used in AI classes and "different enough" to leave students with lots of questions for assignments (imo). At the same time it's not used in many industry projects and if it is companies tend to use proprietary Prologs (like Sicstus) and the code is unlikely to be on Github.
I suppose one could also argue that good setup/tooling and documentation helps to push a language below the line. I'd say Elixir is a good example of this.
So by and large I'd lean towards languages below the line when trying something new. Am I wrong?
Alas the next language I want to play around with (F#) is above the line. But the domain modeling with F# talk/website is very intriguing.
“I can’t find COBOL” I said to my wife. She replied “Well COBOL programmers don’t have any problems. No need to ask on SO where that comma should be placed. And they are so happy in their job they have no need to promote themselves on Github.”
Somehow I just fail to unterstand how a technology like 'Java' can still be popular in 2019. At least to me it seems that there are much better alternatives for almost any use case I can think of.
There's just an enormous supply of Java developers and consultants around, which makes it an easy business decision when deciding the technology to base your projects on. I would not be surprised if a very significant majority of Java code being written today is boring business logic and dime-a-dozen web services.
For new OSS or hobby/pet projects I can also not come up with a single reason to use Java, except "I don't know anything else and don't want to invest time learning"
I hate Java. It wasn't the first language I learned, but it wasn't the 2nd or 3rd either, so I don't think it's just inexperience. It feels like everything takes 3 times as long in C# as Javascript (though I understand AND appreciate why). It feels like Java takes 10x the time, and I DONT understand why. Everything seems overly convoluted. Even recent features like streams.
Java is just a C based language for all intents and purposes. The ecosystem is why Java is popular. For a very long time Sun maintained a stronghold on the way things were done and all the libraries and frameworks followed suit. What this means in practice is that most of the libraries follow strongly opinionated conventions.
Any time you are trying to solve a problem in a domain you are unfamiliar with, you have two problems. One is understanding the problem, two is understanding the framework's bizarre way of solving it. Java mitigates this in that most of the libraries and frameworks seem "familiar" and do things in a similar way.
I do see a lot of programmers that seem to eschew the ecosystems available to them and prefer to write all the code themselves. In that case, maybe Java is not compelling.
I love Kotlin. I use every day for backend development, and I got surprised to see a birthday cake on Kotlin official Twitter account celebrating the just 3 years of the language. Kotlin v1.0 was released on February 15, 2016.
Can someone please rank languages by economic value added? Sample job openings and salary info from glass door and job search websites, then add some data points from LinkedIn. Finally try to guesstimate the value add as a percentage of companies market caps?
160 comments
[ 3.4 ms ] story [ 275 ms ] threadKotlin is doing really well for its age especially, I'm guessing mostly used by Android devs (so far).
I'm using https://github.com/BurntSushi/ripgrep which is rg, like ack or ag (TheSilverSearcher). I've been using it for a few months, and I like it just a little bit more than ag, because I find its help and interface a bit easier to use. Like ag, it's incredibly fast.
Just this week I started using https://github.com/watchexec/watchexec to run rsync to sync from my mac to my vagrant box, because I was switching from using neovim on vagrant to using Visual Studio Code. It works great and has a very nice command-line UI.
Another tool that's written in go that I thought maybe was written in rust that's handy is https://github.com/shenwei356/rush which runs multiple commands in parallel, like xargs. I'm using it to transfer images between folders on s3 using aws-cli.
Based on this, and Servo, which is unstoppable with its Doge logo, I think Rust is going to be a very widely used language. https://github.com/servo
Edit: I remember part of why I liked rg more than ag - I got to use cargo rather than go, which is a much more intuitive and less opinionated way of downloading libraries than using the go cli. go is coming around though: https://blog.golang.org/modules2019
C and C++ have been stable for years, and so has all the little UNIX tooling that was built using them. People are excited by Rust, and take it upon themselves to re-build these tools, as they have well defined requirements and characteristics.
The reason these tools might be better is because thought has gone in to modernising and enhancing existing features. That might not be so feasible/ easily doable if you were juggling a decades old codebase to start off with.
I'm not sure what my point is, entirely... But ripgrep is good! I have replaced awk and grep with it, because it just feels more... user friendly?
EDIT: remembered my point. Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in?
I think it's a little bit of both for me.
The Rust tools tend to have a nicer UX (pretty-printing, colouring by default, with smart detection whether output is to a terminal, subcommand-oriented CLI a la git, etc). This is probably a consequence of nice library defaults but also a matter of culture. They also tend to be very fast. Again, Rust is inherently inducive to writing fast tools, but you also have to do things the right way.
1. IMO Rust has the closest thing in "imperative" languages to haskell's type system in a recently released "mainstream" language.
2. Rust brings an entirely new value (memory safety), and accordingly an entirely new hurdle called the borrow checker. This feature is so advanced that languages like Haskell are catching up (it's not a competition really) by introducing things like Linear Types[0]. That's really impressive.
3. Rust is targeting system programmers -- they move the slowest (as they should) in the ecosystem and are the most risk averse (as they should be).
4. Compare Rust to relatively recent systems-level languages (I won't name any), it's doing great.
5. Staying at the same place in the rankings is actually moving forward -- it may not seem like it, but it's hard to stay both effective, liked, and relevant in the world of programming languages (see: Dart).
I don't think rust is the kind of language to just shoot up the rankings -- it contains both higher level techniques that aren't quite mainstream yet and is targeted at a smaller community (though they're kind of going after web people with the wasm stuff).
I think rust is the kind of language that shows up to be consistently near the top of the rankings in 10 years (and I've said it numerous times but I think Go will displace Java and Rust will displace C/C++ where possible).
Yes, I will concede to a slight bias in favor of rust :).
[0]: https://gitlab.haskell.org/ghc/ghc/wikis/linear-types
Julia? Nim? That's about all that comes to mind.
I wish I could read the Haskell documentation, but the code examples are straight up black magic to me. I really need to dig into some proper functional programming at some point!
The term "systems language" is almost certainly not precise enough. What I mean to convey was a language that you could write performance critical low level code in. In my mind though, Rust satisfies both that definition and the vaguer "backend service" (i.e. the thing spinning behind some interface doing the hard work in your architecture) -- it works very well from very low level all the way up to application programming.
If we're taking the second definition (vague backend-service-y) then Rust has lots more good competition -- if you can afford a runtime then the right language can give you some pretty good safety for less than the cost of learning Rust's borrow checker.
BTW I hear you on the haskell docs, how to start with Haskell is one of the hardest things. I personally took this path:
- http://learnyouahaskell.com (a fun read, introduction to basics, good prose)
- Writing some euler solutions (quickly stopping, they become just a mathematics fest after a while)
- http://book.realworldhaskell.org/ (excellent examples for real-world code)
- http://adit.io/posts/2013-04-17-functors,_applicatives,_and_... (when you feel like you really want to understand the big M)
- Writing the backend for a project in haskell
- Watching lots and lots of talks and attempting to read papers to just headbutt certain concepts over and over till I could somewhat begin to understand them.
I've found the secret is just to let the stuff go over your head at least 2-3 times until you start finding it useful.
But I want to stress that you don't have to write 5th order polymorphic dependently-typed whatever to get lots of value from haskell, here is some low hanging fruit:
- Haskell has the type system you thought/wish Java/C# had (i.e. `type AorB = A | B`, `newtype PositiveNumber = N { _posNum :: Int } -- guaranteed through constructor to be >= 0`). The ease with which you can have types express intent is mentally revolutionary.
- Behavior and object structure are separate, like Go's structs + interfaces or Rust's structs + Traits, and constraints (dependencies from one typeclass to another) are really easy to use -- ex. `class Thing a => BigThing a where { ... }` expresses the dependency that for a to be a `BigThing` it needs to first fulfill the requirements of being a `Thing` -- this is how you can force the existence of certain functionality on with polymorphism. Once you get used to this everything else (well, subtyping at the very least) will look primitive.
- Concurrent programming is amazing, both due to STM and the very good threading model (lightweight routines multiplexed to system threads)
- I will say that I think there's lots of low hanging fruit out there though -- Haskell has the type system you thought Java/C# would have. They really have "class" systems rather than type systems.
C++ is safer but heavier than C, and Java is safer but heavier than C++. If C/C++ are systems programming languages but Java is not, then I posit that Go is also not a systems programming language. If use in resource constrained environments (where C/C++ can happily go) isn't a huge factor, then lots of things are systems languages that I wasn't considering
Wiki says:
> System programming (or systems programming) is the activity of programming[1] computer system software. The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or both (e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications).[1]
> System programming requires a great degree of hardware awareness. Its goal is to achieve efficient use of available resources, either because the software itself is performance critical or because even small efficiency improvements directly transform into significant monetary savings for the service provider (cloud based word processors).
Last sentence of the first paragraph seems to kind of two cases I kind of mentioned -- providing services to other software, being performance constrained, or both. Assembly/C/C++ are obviously often the only choice for the "performance constrained" use case, but not necessarily the best choice for the simple use case of "providing services to other software".
https://www.aicas.com/cms/en/JamaicaVM
https://www.ptc.com/en/products/developer-tools/perc
And a tracing GC isn't a deciding factor for being a systems programming language or not.
Besides the examples shown above,
http://www.astrobe.com/default.htm
And the now long gone Lisp Machines, Mesa/Cedar, SpinOS, Singularity, Midori,...
"Resource constrained" doesn't even mean the same thing anymore either...
Haskell definitely has a high early threshold that you need to get over. After that it's pretty much just fun and smooth sailing until you try to do something bigger, at which point there's another threshold.
The learning experience is the most fun I have had programming.
As absolutely suitable for self study I would recommend:
https://www.amazon.com/Elements-ML-Programming-ML97-2nd/dp/0...
Just get the basics down and write some stuff. For a lot of things, you don't need to know how they work underneath in order to use them. It is helpful to implement functors, applicatives and monads for some of the basic data structures to get a feel for things, but then beyond that, just use what has been provided. Don't try to write your own monad transformers, just use the mtl library. Lenses are really complicated to understand, but really simple to use. The servant web library uses some high end type level stuff in order to work, but it is really easy to use. The compiler has your back.
If something just doesn't work and doesn't make sense, just move on and find a different way. After a while you will understand more and can return to it.
Don't try to understand the academic papers that have been written with Haskell. There is a really tradition of making the Haskell code as incomprehensible as possible. It will just get you down.
That is what I do: I use a subset of the language, don’t dive too deeply into the theoretical stuff, for anything imperative I find an example to follow, and just enjoy writing pure code in a comfortable interactive environment (VSCode or Emacs).
It is possible to just use Haskell ‘lightly’ and enjoy it. The only problem for me is that it can take me a while to understand other people’s Haskell code when I read it.
Luckily Haskells type system means that you can understand a lot about what is going on just by looking at the type definitions. Most code includes these. Although rather frustratingly, however, a lot of documentation doesn't include the type definitions. It is good to see languages such as Idris make it mandatory to include type definitions for all functions.
I still don't completely understand what is going on in the route definitions, but I have no problem with setting up a route.
Granted something like this is a gnarly type :
But really you don't need to think of it as a type, just think of it as setting up a couple of routes. The ':<|>' is the route separator. ':>' represents a '/'. The bit after the final ':>' is what your function needs to return. If you get it wrong the compiler will complain at you.With an incomprehensible error message. Beginners will of course get it wrong.
I would rather put beginners on a path that makes them feel like the compiler is helping them, one of the core strengths of Haskell, rather than it just telling them No.
My original point was don't get bogged down in complicated stuff. If someone just doesn't get Servant, there is always Scotty, which is much more straightforward. Servant is not a reason to feel intimidated by Haskell.
Java certainly isn't perfect today and it certainly wasn't perfect when it gained the mindshare it has now. I think it's pretty impressive that Golang has achieved anywhere-near-JVM speed with easier concurrency primitives and ease-of-use in the time it has. What standard are we holding Go to that Java would have fit at the time?
If you meant Ecosystem-wise there are very few ecosystems that can compare to Java, since it's been around so long and has been the workhorse of (I think) the majority people being paid to write code for so long. If this was the way we picked languages, no new languages would ever emerge.
People are being productive in Go, and they're using it to write lots and lots of software. It's a good tool and is already production worthy, at the very least based on the fact that it's already running in production in many places and hasn't spectacularly failed anyone yet.
somewhat related rant
Also, I think Go changed it's official logo (from the gopher) in an attempt to fit this kind of language, and I think it's stupid. Who cares if their logo is of a worm -- if it's a good piece of software, then the right people (who value good software and craftsmanship over some appearance/facade of professionalism) will use it. People pay us to write good performant software, most of the time they wouldn't care if you wrote it in Brainfuck as long as it worked and worked well (of course, there's also the fact that someone has to maintain it, but let's pretend that doesn't exist).
end rant
It needs to catch up a lot with Java 12.
Also I'm not sure missing a GUI toolkit is an indictment of a growing language these -- systems programming very often does not involve a GUI.
GUI libraries are just one of the easiest examples to come up with.
I can list many more missing features in Go land that we have been enjoying for the last 20 years in Java land to drop them just because of Google's cool factor.
it could also compete with go and python for command line tools but I think the mental overhead of the syntax makes it hard. i would rather write rust then go or python though.
Rust also feel like a very work in progress language, especially with useful features only in nightly often.
The rust community seems to be slowly but steadily working through a bunch of bigger use cases (all in the open as well, so you can see exactly what they're doing and why). For networking use cases, see projects like tokio[0] and hyper[1] to see how the community is moving (here's an awesome talk on it[2]). To me, it looks like the rust community is actually trying really hard to build things modularly and slowly from the start, taking tons of time to "measure twice cut once".
All that said, building networked systems in Rust is definitely extremely usable right now (and in many cases without nightly, I don't turn it on for any of my projects) -- maybe you won't find a gopher-server crate (rust's packaging mechanism) but for regular HTTP/HTTP2 you're going to find a lot of production-ready software (rocket[3], actix-web[4], tower-web[5]). I'd love to be pointed to some recent post where someone spelled out their issues writing some basic HTTP/HTTPS REST-ish backend servers (which I think is what the majority of people are writing/maintaining in their day jobs).
Side note (I'd love for someone to correct me), but generally when people want "performant" multithreaded network services, I take that to mean they want the combination of all system cores utilized and IO treated asynchronously -- in my mind this is basically all it takes, everything else is application/solution-space level optimization (parse your JSON a little quicker, maybe use a better data structure, do more things concurrently, etc). Rust has both of these things (system threads, libraries with async support) -- for example async/await syntax is landing soon, and from what I know the state of the art has progressed in this manner: callbacks->deferred/promises/futures->async/await -- rust is already 2/3 and async/await support is landing soon. And on top of all this -- rust is going to make parallelism & concurrency safer -- this is huge because while it might have been easy to `#include <pthread>` in C/C++, it sure isn't/wasn't easy to write correct concurrent/parallel code without the support of a runtime.
[0]: https://tokio.rs/
[1]: https://hyper.rs/
[2]: https://www.youtube.com/watch?v=4QZ0-vIIFug
[3]: https://rocket.rs/
[4]: https://actix.rs/
[5]: https://github.com/carllerche/tower-web
How are Rust SQL drivers for distributed computing with Oracle, DB2, SQL Server?
I can talk about some SQL drivers though -- I've used `postgres` (postgres), `rusqlite` (sqlite), `r2d2` (connection pooling) and others to great success building some relatively small codebases. For a more pre-baked approach `diesel` is the ORM that everyone is generally on if that's your speed.
Just in case I misinterpreted the question -- were you meaning to say that distributed computing using Oracle/DB2/SQL Server are examples of contradictions to my statement of "everything else" being "application/solution-space level optimization"?
- calling PL/SQL on an Oracle RAC cluster using distributed transactions at driver level.
- define data structures where the driver does the mapping into PL/SQL User Defined Types.
rust-oracle is listed on the shared programming interface page though (https://oracle.github.io/odpi), so maybe it's close if not already possible.
I doubt the second one more though -- how many languages even have an oracle driver with integration that tight to begin with? I struggle to find drivers that map PL/SQL user defined types to in-language types (even with something simple like enums)...
I do think eventually it could replace C though -- because rust with `unsafe` blocks still has the possibility of being safer than C. This could be a boon to security critical software, as long as the performance margin isn't too hard. Shops that have found ways to write safe C will likely never move (they don't need to), but new ones might pick rust where they might have picked C otherwise.
BTW, the embedded support in rust is really impressive for such a young language: https://github.com/rust-embedded/awesome-embedded-rust
But Rust is so overwhelmingly better than C, Go, Java, and C# for things people use those for, it may have a bright future replacing them, once its libraries and tooling mature enough. It will be competing with C++ on that, but there's room for both.
Perl? Please, Perl was SO huge that I'm surprised it's as low as it is (which makes me suspect the methodology, actually ...).
In addition, if I remember from the TIOBE index there is the "Top Ten" and "everything else" where 10-20 is basically 1%+some noise and 20-50 is like .3%+noise.
> Kotlin is doing really well for its age especially, I'm guessing mostly used by Android devs (so far).
I wish the Android ecosystem would finally pick something and just stick with it. Having tooling, samples, and documentation that don't go out of date every 6 months outweighs any mythical "advantage" that switching language, build system, etc. actually gains.
This is exactly why I didn't stick with Android for too long. Everything's too... in flux, but in a weird way.
"YAY, Google released this feature I've been dying for! Can't wait to use it in 4 years, when enough phones actually support it :)". It's either that or have API level dependent code.
Maybe Dart will fix some of these pains, by abandoning all they have built up? It is Google, so I'd say it's unlikely, but still.
Hell, I was trying to build an analog clock widget as a tribute to a certain sports team, and Google had deprecated the AnalogClock class. Its successor was, well, nothing. So a few community efforts took its place, and the fragmentation only got worse. Thanks, but no thanks!
The only good part about Kotlin getting entrenched is that JetBrains is MASSIVELY invested in not letting Google switch to something else--so we may finally get some stability for a change.
I think that's what we're seeing here but the graph isn't really making that clear. I doubt Pascal is used nearly 50% as much as java (unfortunately) for instance, it's a logarithmic scale.
https://github.com/SergioBenitez/Rocket/issues/19
For Kotlin that is Android. I am more interested to see what will happen to it if Google has one of their usual project reboots with Android.
Rust still fails short in several domains, but now with Google and Microsoft's additional love we might see some improvements there.
I now use Kotlin on Android, and it’s mostly a tidied-up Java that’s slightly better in every way. The one big difference is checked exceptions -- Kotlin doesn’t have them.
My question is, do Kotlin users prefer unchecked exceptions, or do you find yourself avoiding exceptions entirely now? Or even dropping back to Java when you need exceptions and you want compile-time checks?
I find myself mostly trying to avoid exceptions entirely in Kotlin -- maybe not such a bad thing!
I generally find that I avoid exceptions, but where they are necessary I try and catch at the right level to handle them.
I can't speak for Kotlin users en masse, but personally I don't miss checked exceptions one bit, same as I didn't miss them in C#. And I've never encountered the practice of "dropping back to Java" for checked exceptions of all the reasons.
A compelling way of emulating the presumed benefits - without the bad parts - in Kotlin would be to go sort of functional and use a Try return type from Arrow-Kt: https://arrow-kt.io/docs/arrow/core/try/
I was trying to figure out if people are happily using unchecked exceptions, or not using them at all.
I would deliberately throw exceptions as a "fail fast" safety switch, when I actually want the thing to burn down in flames. That's typically about violating some sort of a contract which indicates an implementation error - like an illegal argument. In such case to have them unhandled is sort of the point.
I found that following these principles by itself leads to a very limited role of exceptions in code.
Wouldn't that imply that C programmers resort to SO more often than they publish code on GH compared to JS?
C has two big areas I think - Linux/open source software, and embedded work. A lot of open source projects in Linux land are for whatever reason not in Github. Heck I still see sourceforge a lot. Embedded work is likely done for a company and of course wouldn't be in Github.
both GH and SO are probably not representative of the industry.
With Go especially, my default move when I have a question, is to go to golang.org/pkg and find find the package I'm having issues with. Assuming it's a standard package problem, of course. The built in editor for examples is really great. I can run a little test quickly, and move on.
Neither are programming languages.
You could make the case for SCSS and things like that, but it just says CSS.
Meh.
After a lot of languages that are just rehashes of what we’ve already seen, or just a different subset of features, Rust is a languages that actually feels like it’s from the future that's finally going to start moving us forward after a lot of stagnation in industry while PL theory has continued to move forward.
If you haven’t given Rust a shot yet now is the time. You can get rust up into the top ten. :}
At the end the day it's platforms that move languages, not posting on HN and reddit.
They quite brutally damned Rust with faint praise in the article: "It’s also worth noting that even if Rust never gets much beyond where it is today, it’s still ranking higher than well known languages such as the aforementioned Clojure and Groovy, as well as CoffeeScript, Dart or Visual Basic. Not bad for a systems language."
Ranking higher than VB...
MS basically killed it, in 200x when the VB.NET snafu happened. I assume 100% of the VB work is legacy at this point and since solid architecture or design principles were never this language's strong points, it can't be particularly exciting legacy work either.
It's basically a career and technological dead-end.
While it may not be exciting work, not every programmer is looking to do the latest and greatest thing that will appear at the top of HN. They make good money because the business knows paying someone well to maintain it is better that paying a team to rewrite it. That's why one of the issues with COBAL programmers is retiring and passing on, not leaving to go to a NodeJS shop.
On Windows C++ was the tool of choice and Delphi was kind of a secret weapon for GUI development. Then C# happened, and MS unceremoniously flushed VB down the drain. The VB community was outraged about VB.NET...
Still not ready to listen to a bunch of judgmental people over trivial improvements who only throw shade on everyone else at EVERY opportunity.
So, I'm curious: how does HN see this situation going forward? Where will Rust find widespread industry adoption, and what can Rust community do to bring this forward?
Having said that, I don't think the rust ecosystem is going to go up in flames anytime soon, but lack of professional application at the moment doesn't bother me too much.
Some bigger companies are supposedly using Rust (Amazon, Google, MS) on some projects, but these companies have so many things going that they are likely to use most languages in some kind of project. I've also heard that there are several "invisible" Rust jobs, only available through connections - but these are irrelevant IMO. And then there are the jobs where one is obviously not using Rust, but they mention it to score points or dangle it as a possibility.
Until I see a strong market for Rust skills, or my own employer offers interesting Rust projects, it doesn't make sense for me to invest beyond learning the basics. Funnily enough I'm looking into Go now - its job market is one-sided and quite anaemic, but it offers some nice technical benefits and is a piece of cake to learn.
Show them to create a secure COM component to integrate in .NET can be easier than writing it in C++/WinRT | C++/CLI, using the same VS/debugger integration while being safer, for example.
Repeating ad infinitum in every HN thread about C++ improvements regarding safety, that the only path to enlightenment is rewriting the world from scratch, without any regard for the loss of productivity, tooling and libraries in doing so, always hand waving them as minor inconveniences, is trying to catch flies with vinegar, but I guess I am wasting my Latin as we say back home.
I've said many times there is a legitimate reason to write C++. If you understand you will be shipping memory safety issues, but the advantages of C++ outweigh the memory safety issues that you will ship to production, then I can't argue with that. I've seen game developers argue as much, and that's legitimate! Maybe, for your use case, memory safety problems really don't matter (or don't matter enough to outweigh C++'s other features). But it doesn't do anyone any good to sugarcoat the fact that C++ at scale virtually always ends up with memory safety problems, and while there have been many mitigations there has been no effective solution so far.
Maybe it will change after the HoloLens/FF project, however today is not appealing to many Windows teams.
Rust can best grow its developer base by growing the number of new systems programmers, as they would have less to lose by using Rust and would be less likely to notice its limitations. The challenge here is that becoming a competent systems programmer is much more difficult than learning a new programming language, and there is a chronic shortage of developers interested in systems programming.
If we were still using classic C++ (i.e. C++03 and earlier) then I think Rust would have a real chance. The rapid evolution and adoption of modern C++ has fixed many (most?) of its major weaknesses.
Majority goes to Rust for what it is developed for: system programming.
Just like I won't use Go for web app dev (ugh.. what a PITA)
Modern C++ is not memory safe, and there is no way for it to achieve memory safety without either significant runtime overhead or breaking compatibility so much it won't be C++ anymore. The features in modern C++ are nice, but they don't solve my problems.
Perhaps the driving force demanding memory safety isn't for one's own use, but rather the hope that the code one depends upon, written by other people, will get better. I.e., I write good code, and you write good code, but God forbid we have to rely on Microsoft, Google, Mozilla, and Red Hat monkeys to write good code! That's a legitimate desire, but it doesn't drive much personal adoption. Meanwhile, the PITA factor -- borrow checker not happy! "&" required! "&" forbidden! -- interferes with personal adoption of Rust.
And C++ keeps adding features. Not to fall increasingly behind, Rust needs to multiply its adoption rate. I don't see how that could happen. C++ is already good enough, so Rust can't cannibalize significantly from C++ coders. Rust is enough better than Go, Java, and C# to be worth a significant effort to switch, if users of those languages could perceive it. The greatest benefit to the world derives from driving people off C -- to Rust or modern C++, it matters little which.
That's easy to answer. They do. Any look at a CVE list for a browser will confirm this. These browser engines are, by and large, written in a modern style.
> Are they now of mainly theoretical importance?
No.
I would use Rust in place of C++ or C in a heartbeat (and I would probably pick it over Go until they have generics), but I wouldn't use it in place of those other languages for the same reason I wouldn't use C++ in place of them. They're already managed, and I wouldn't have used them in the first place if I needed Rust's performance.
At the same time, modern C++ also has advanced and valuable safety features that Rust does not have e.g. the enormous amount of compile-time verification and complex type construction that is possible. I find these to be far more valuable because the kind of bugs these catch are more common in practice. None of this is automatic but it is trivially enforceable as coding style, and many companies do.
The idea that C++ code bases are necessarily littered with memory safety bugs is nonsense. For people that have been writing this kind of code for a long time, avoiding those bugs is largely automatic and effortless. And you don't have to do violence to your data structures to achieve it. I can see an argument for someone coming into C++ from a language like Java but for experienced C++ programmers the value is dubious in practice.
There may be compelling technical reasons to use Rust over modern C++ but you'll have to do better than automatic memory safety, particularly given the safety and capabilities that would be sacrificed.
(I also disagree that modern C++ is safer than classic C++. Modern C++ adds more invisible ways to get use-after-free, which is pernicious.)
Most mainstream languages being used today took around 20+ years to get here, Rust will need as much for long term survival.
It did? Can you link me to the new stuff?
The "Popularity Rank on GitHub" is probably more accurately measuring popularity in the popular sense of the word. That's especially true because the GitHub archive used for the data only offers info on public repositories and even then I'm curious to know how it reports for multi-lingual repos (does LOC win out, do repos get associated with multiple languages?).
Personally 90% of my commits over the past year have been to private repos for work. My public commits are in languages I look forward to using and learning outside my 9 to 5 because they interest and they offer a nice change up (ie PureScript and Rust lately).
I'm super stoked to see FORTRAN is riding solidly at 60% for both metrics, regardless of what those metrics truly measure. ~40 public commits in the last 24 hours! Check it out:
https://github.com/search?o=desc&p=4&q=fortran&s=updated&typ...
I'm learning Swift at the moment and I'm running out of eyebrows, due to the sheer quantity of unforced facepalms I give myself.
I’ve got about 30 iOS examples on Github:
https://github.com/melling/ios_topics
As an example, I had to write a little code to connect some Swift and Obj-C code the other day. (I don’t use either one regularly.) It was very hard to find good up-to-date docs on how Swift/Obj-C bridging works.
I tried to create a simple tool to retrieve a JSON reply from an API and display the results. Piece of cake, right?
Took me a day of debugging and hitting my head on several objects before I figured out that none of the half dozen tutorials I found were made for Swift 4.x.
Even Fucshia is now adding support for other UI frameworks via Scenic.
Do you have any criticism about flutter you’d like to share ?
Less mature than every cross-platform mobile UI framework that are around since iOS and Android have won the mobile market.
At the same time Fuchsia how has a UI composition engine, where Flutter is just one option among many (Scenic) and they are toying with a Rust based one (Fuchsia-ui).
Being burned by Dart 1.0, I will only take it seriously when it officially gets adopted by the Android team.
Dart was rejected by the community it was aimed at, Javascripts devs (and for pretty dumb reasons, I don't have much respect for either Javascript or its devs).
Google understandably took the opportunity to reboot it.
None of this is the same as dropping it, which for sure would merit "being burned".
It's now a modernised and slick version of Javascript (minus the functional, which no one uses anyway) with a full Android and IOS framework and extensive and properly documented libraries. And it's opensource.
At this point it's not possible for it to be 'dropped'.
Beeing open source only means an organisation, or a group of developers, with the capacity to handle a project the size of flutter + dart, could do so if they wanted to.
Which means basically noone, except maybe in China, because nobody could have the firepower to deal with something this big ( maintain and even harder have it evolve) for free.
And unlike a google service, which requires continued resource usage and high cost, flutter+dart has low needs. It may get outdated, but it can't be disappeared like other dropped google projects.
In any case, Unless Dart+flutter becomes an undesirable competitor to another google offering, there is no reason for Google to drop it unless it fails to get sufficient adoption. But I think that's unlikely.
Javascript devs are widening their horizons these days (as opposed to their rejection of Dart 1.0), and Dart only needs a few of those javascript devs to take an interest. The framework is an easy crossover for many of them, with an almost instant access to app development and little commitment needed to spin up.
Just look at how long it took to get a correct map on flutter (and i don't think they've catched up yet).
I think they took a very good direction from a technical point of view, to recode everything from the lowest level possible, but that kind of approach requires a tremendous level of commitment.
Flutter needs an update once a year at most, and is mostly cosmetic and a bit of wrapping. Again, the heavy lifting has been done.
Coding from the bottom up....has been done.
I think you may be overstating the 'commitment'.
What we need to keep in mind here, is the context, that dart/flutter is easy access - it's no Angular or Cocoa - and that no sane, mature dev programs in only one language and one platform unless it's legacy.
We're not talking about a massive commitment from a dev, so talk of 'being burned' by Dart 1.0 is already a bit of a headscratcher when google didn't drop it, rather changed up and arguably improved Dart. How can that be called 'being burned'. For instance, dropping the need for 'new'. So, sure, it makes the code slightly less readable, but it also opens Dart to neat code and even maybe DSLs. Then they added Flutter.
I can understand this POV. Has there been any rumors that the Android team might adopted flutter ?
Check their latest AMA on Reddit.
https://old.reddit.com/r/androiddev/comments/av3lhx/were_on_...
And here is the relevant comment, I think:
https://old.reddit.com/r/androiddev/comments/av3lhx/were_on_...
Could have been the interaction with the framework and the fact that it lagged behind on Angular/TS at that time.
[1] https://trends.google.com/trends/explore?date=today%205-y&q=...
[2] https://www.alexa.com/siteinfo/python.org
[3] https://www.alexa.com/siteinfo/java.com
Right.
I think it's a bit of a stretch to call java.com "the website for Java". I end up on python.org (or at least docs.python.org) often enough. I never go to java.com. If I end up anywhere on the "official" Java websites, it'd rather be docs.oracle.com/javase/...some-doc...
Prolog seems like a good example. It is used in AI classes and "different enough" to leave students with lots of questions for assignments (imo). At the same time it's not used in many industry projects and if it is companies tend to use proprietary Prologs (like Sicstus) and the code is unlikely to be on Github.
I suppose one could also argue that good setup/tooling and documentation helps to push a language below the line. I'd say Elixir is a good example of this.
So by and large I'd lean towards languages below the line when trying something new. Am I wrong? Alas the next language I want to play around with (F#) is above the line. But the domain modeling with F# talk/website is very intriguing.
For new OSS or hobby/pet projects I can also not come up with a single reason to use Java, except "I don't know anything else and don't want to invest time learning"
Any time you are trying to solve a problem in a domain you are unfamiliar with, you have two problems. One is understanding the problem, two is understanding the framework's bizarre way of solving it. Java mitigates this in that most of the libraries and frameworks seem "familiar" and do things in a similar way.
I do see a lot of programmers that seem to eschew the ecosystems available to them and prefer to write all the code themselves. In that case, maybe Java is not compelling.
I was pleasantly surprised at the popularity of Haskell.
I’m curious to see just how much of it is due to client side, as it probably skewed the ranking due to the fact all websites use JavaScript.
I want to just see how node competes with other backend languages like php ruby and python
But programming languages are different: programming languages are not just technology, but what programmers think in.
They're half technology and half religion.”
— Paul Graham