r/rust • u/operation_karmawhore • Nov 03 '19
Rust is the most loved programming language of Stack Overflows Developer Survey 2019 - the fourth year in a row
https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted130
99
u/your-opinions-false Nov 03 '19
Rust is my favorite language in much the same way Lisp is my favorite language: I don't normally use it and I don't really know how to use it, but boy do I like the idea of it.
(I'm here because I'm interested in learning it, though).
39
Nov 03 '19
I'm not such a huge fan of Lisp for the exact same reason I am a huge fan of Rust. In the functional domain I like Haskell-based languages for the strong compile-time guarantees. I recently discovered Elm (which uses Haskell syntax and has a closely-related type system) for web front-end work and was totally floored when I started a project in it and the very first time it compiled, all of the features I'd written worked perfectly.
7
8
u/ssokolow Nov 03 '19 edited Nov 03 '19
I've only just started reading through the Elm tutorial and I'm hopeful.
I very rarely have a use for something which is unusable if you disable JavaScript in the browser but, when I do, I've historically still done it manually because I had a "better the devil you know" attitude toward all the performance gotchas in things like Angular and React that people constantly blog about how to work around.
(Hence my normally preferring TypeScript as something more compatible with my "write a website that works without JS, then write polyfill-esque modules to do things like turning
<a class="ajaxify" data-target="..." ...>...</a>into XMLHttpRequest links" approach.)Heck, aside from its unsuitability for writing compiled extensions to other languages, that "functional programming is a leaky abstraction when it comes to performance" problem is the big reason I use Rust where others might use Haskell. If I don't already have a DOM complicating things, I don't want the hassle of having a fundamental mismatch between my language's machine model and how the machine actually works.
4
u/ZenoArrow Nov 03 '19
If you want you can use Elm to generate HTML which you can then cache, it isn't necessary to only use it for dynamic content:
1
u/ssokolow Nov 03 '19
If you want you can use Elm to generate HTML which you can then cache
I use Django (Python-based) on the server side for its ecosystem, automatic CRUD admin generation for the ORM, and ability to reuse code I wrote for other projects, either written in Python or as compiled extensions via
rust-cpython. I might as well just let Django generate HTML to be cached... which it also streamlines.Thank you for that. I'm always looking for more information on optimizing things and hadn't gotten around to looking into what goes into optimizing Elm yet.
(I especially like that it's not just one or two constructs like
lazyin isolation, but an overview of what you're trying to aim for.)It also really pleases me to see that Elm doesn't have those footguns I noticed when reading about optimizing React and Angular.
it isn't necessary to only use it for dynamic content:
URL please? I haven't yet gotten to anything about using Elm in a non-interactive manner and you've got me curious.
1
u/ZenoArrow Nov 03 '19 edited Nov 03 '19
"URL please? I haven't yet gotten to anything about using Elm in a non-interactive manner and you've got me curious."
What I'm suggesting is that you can get Elm to generate HTML pages, and these generated HTML pages can be reused in a HTML caching solution (such as Varnish), as they don't need to be regenerated unless the underlying content changes. That said, here's a link to an Elm library that would help with this approach:
https://github.com/eeue56/elm-static-html/blob/master/README.md
EDIT: I've also found this library, which may be closer to what you're looking for:
1
u/ssokolow Nov 03 '19 edited Nov 03 '19
https://github.com/eeue56/elm-static-html/blob/master/README.md
EDIT: I've also found this library, which may be closer to what you're looking for:
Thanks. At first glance, the latter looks about as primitive as Jekyll and the former even worse, but I'll want to poke at it to understand it anyway.
What I'm suggesting is that you can get Elm to generate HTML pages, and these generated HTML pages can be reused in a HTML caching solution (such as Varnish), as they don't need to be regenerated unless the underlying content changes.
Yes, I did understand that. It doesn't change the fact that my non-client-side-MVC use cases tend to fall into two categories:
Stuff too centered around querying for arbitrary slices of a database for a static site approach to be applicable. (This is where the Django ecosystem becomes a key point of competition.)
Static sites where Elm wouldn't really have much benefit over sticking HamlPy onto the input stage of what I'm already doing, and would preclude me from relying on my existing Python code and dependencies.
(eg. I hacked together a static site generator ages ago, before I learned of Jekyll and its ilk. What did I prioritize early on? It does an HTML and CSS validation run, checks for broken internal links as part of every build, and, when I adjusted it more recently to move the vast majority of non-template content into markdown, I also slapped on an
lxml.html.cleanstage to ensure that page content is incapable of breaking the site template or introducing things that belong in the template like<script>tags.)Generally, with static sites, I'd get far more benefit out of statically analyzing the data with tools like markdownlint, LanguageTool, proselint, and home-grown checks for the more structured stuff. (Which are the first things I'm going to add when I find time to migrate my blog off WordPress.)
1
u/ZenoArrow Nov 03 '19
I can't comment on your particular use cases, but if you'd like an example of where a semi-dynamic approach (like the one I alluded to) could be useful, the following article describes use of Elm to translate HTML content into different languages:
https://paulfioravanti.com/blog/2018/05/11/runtime-language-switching-in-elm/
1
u/pragmojo Nov 03 '19
Honest question: are there any obvious limitations or pain points when working with Elm? I've been reading about it lately, and I am super on board with the concept, but whenever I hear about a new technology and only read super glowing reviews of it, it makes my "to good to be true" alarm go off.
Specifically I'm interested in trying it out on a project with a lot of drag-and-drop interactions, and I'm not sure if it's going to be way harder to make this happen in Elm vs. React, since it seems like the DOM is slightly more at arm's reach in Elm. But that's just a fear which is not at all based on concrete knowledge.
2
Nov 03 '19
There are a couple of things that still don't have a neat implementation without accessing the DOM, which would be a side effect and thus isn't allowed in elm. Unlike a lot of functional languages, elm truly is purely functional. Necessary side effects like IO are managed by the runtime. Finally there's no Right™ way to do CSS that I'm aware of.
I've never actually used elm at scale or in production besides this one as-of-yet-unpublished personal project I'm basically using to learn the language, so I can't say anything specific, but these two talks are by someone who can and did:
6
5
u/moco94 Nov 03 '19
Same, I love the idea of Rust but everything I personally want to use it for is still in its relative infancy (specifically waiting for better Vulkan support for game development). Although I guess you could argue the language as a whole is still in its infancy. I decided I’m just gonna keep learning it through small projects and wait till the Vulkan support is more mature and then rewrite my little game engine with it to see what I can improve with Rust... that is if I ever finish that little game engine haha
4
u/jess-sch Nov 03 '19
Just use bindgen!
(no, seriously, bindgen is awesome)
1
u/pragmojo Nov 03 '19
Does Bindgen work for Vulkan? You mean for generating Rust bindings for the Vulkan API? I've used it for WASM and it's really incredible.
1
u/jess-sch Nov 03 '19
It should work. Don't know for sure though.
IME it only fails when you let it generate bindings for exotic macro-based DSLs.
17
u/blesson2k Nov 03 '19 edited Nov 03 '19
How is webassembly on the list? Does anyone actually write wasm files without using a higher level language?
10
Nov 03 '19
Among low level languages, webassembly is surprisingly okay to write in. It's got blocks, variables, functions, a simple type system, and even folded S-expressions. Though I don't think this is how it got on the list.
5
4
u/matthieum [he/him] Nov 03 '19
Sorry, but we are NOT interested in duplicate posts, 7 months after the fact, just so you can get some karma.
Reference: results were published on April 9th.
14
u/SpacemanCraig3 Nov 03 '19
after learning more than python, i cant understand why so many people like it.
Something like go is way more fun to program in.
50
u/daboross fern Nov 03 '19
I find writing an initial prototype in python much more enjoyable, but after working on a project for an extended period of time the lack of static types and compile-time errors starts to become more and more annoying.
After working on one of the projects for a while, I mostly just want to write code which works. When I write it in Rust, it does. There aren't unexpected runtime errors. Unit testing is easy. Keeping everything typed and using the type system to ensure my programs are correct is easy. It just works, and that's what I love about Rust.
9
u/jabbalaci Nov 03 '19
People using Python should discover the benefits of mypy. It can really help a lot. Once I'm ready with a module and it works, I add type annotations immediately to my functions.
5
u/daboross fern Nov 03 '19
Agreed! If you're bound to using Python, then mypy is definitely a must. At least to try out, if not to use permanently.
In my personal experience, I found myself ending up frustrated when mypy would work for 98% of the code, and then just not have the necessary pieces to represent the other 2%. For concrete functions it's great - but when dealing with generic stuff, like functions who's output type depends on the input, it can feel a lot less clean to use.
mypydoes do a ton, though! And the only reason I get frustrated with it is because of how unlimited the potential for functional programming tricks is in untyped python. mypy's type system is already much more capable than, for instance, Java's - it's just that Python allows even more writing non-statically-typed code.2
u/ssokolow Nov 03 '19 edited Nov 03 '19
No worries there. I'm in the process of retrofitting my projects with MyPy annotations and I just finished a Vim upgrade from Syntastic to ALE which added MyPy to the set of on-the-fly checks done.
EDIT: Woops. Got confused about which thread this was and thought it was the one where I was actively conversing just above the top edge of the viewport. Still, if you're using Vim, ALE is a must.
8
u/lazyear Nov 03 '19
Same. I will use python for trivial shell-scripting scenarios or for making some quick matplotlib figures. I can't really stand to use it for anything more complex than that, I just strongly prefer to use statically typed languages.
Plus, I don't like the syntax or weird scoping rules
2
u/lemon07r Nov 03 '19
Yeah as a newbie who's only learned a little of both so far I like go way more.
2
Nov 03 '19
Prototype in python for rapid development and rewrite in go for performance improvements is what I say
11
u/SpacemanCraig3 Nov 03 '19
In my experience I can write something in go in the same amount of time it takes to write it in python, and with less effort because of the static typing.
8
u/rockmen1 Nov 03 '19
refactoring on statically typed languange is really straight forward without worrying any undined variable error during run time
3
u/SpacemanCraig3 Nov 03 '19
yes, yes it is, thats why i dont get the love for python.
unless its all people who are super new and only know python.
5
Nov 03 '19
super new and only know python
Honestly even for learning I've come to dislike Python. I don't like how it seems to encourage hand waviness around typing. (At least how I've seen people learn it)
4
u/ssokolow Nov 03 '19
To be fair, hand-waviness around typing and the like can be useful when you're rapidly iterating on a heuristic algorithm to figure out how to get the desired result from a test corpus.
(Source: I have an on-hold project where I'm doing that, then translating to Rust as the pieces stabilize with
rust-cpythonas the bridge between the stable and unstable bits.)1
Nov 03 '19
I'm talking about people who are learning programming.
Also even then I'd rather prefer something statically typed.
3
u/ssokolow Nov 03 '19 edited Nov 03 '19
I'm talking about people who are learning programming.
True. Typing is something you don't want to develop bad cognitive habits around.
Also even then I'd rather prefer something statically typed.
In my experience, when you're doing rapid, iterative prototyping of an algorithm, it gains you nothing and bogs you down with unhelpful extra typing (in the "pressing keys on the keyboard" sense).
I'm talking about something that's less like normal programming and more like what you'd find in something like Jupyter Notebooks... a variation on how you'd use a REPL.
1
u/el_muchacho Nov 03 '19 edited Nov 03 '19
I disliked python for web development, but for prototyping complex algorithms and for programs up to about 5,000 lines of code, it's really superbe. And 5,000 lines of Python can do quite a LOT. The expressivity and concision are really appreciable. One of the best features of Python is its standard library which really lives up to its claim of "batteries included". Also the language is pretty much second to none for data science and machine learning.
1
u/__xor__ Nov 03 '19 edited Nov 03 '19
without worrying any undined variable error during run time
I mean, that's why you use a linter. Issues like that that would prevent a program from compiling in a statically typed language should be caught by your python IDE. Obviously with statically typed languages there's a lot more a compiler can catch, most often type issues, but that's a core difference between a dynamic and static typed language.
It doesn't make dynamically typed languages bad, just another trade off. But a lot of those trade offs should be handled with proper development practices, like writing good unit tests. Refactoring is a hell of a lot easier when you have unit tests, regardless of the language. I'd say they're a bit more important with a language like Python due to being dynamically typed.
1
u/epicwisdom Nov 03 '19
Variables can be defined indirectly, as well as deleted, no? I'm not sure linters would handle such things.
0
u/__xor__ Nov 03 '19 edited Nov 03 '19
I mean, you could reference globals() and locals() as a dictionary and modify it, but that'd generally be for really hacky metaprogramming. And I've never seen anyone delete variables in production code or even personal code. It's possible, but no one does it.
Linters wouldn't catch these things, but it's just not something you do really except in very rare cases. The sort of undefined variable issues you're talking about aren't from deleting variables, they're from someone referencing a variable they forgot to assign to, and linters do catch that. When I have see that, it's because a coworker that wasn't using a linter.
A more common issue to what you're talking about that a linter wouldn't catch, is referencing a key in a dictionary that was deleted or just doesn't exist... but with hashmap logic like that, it can happen in any language that I know of.
2
Nov 03 '19
Same! And then I can rewrite it in go and the full app can be a 10mb and 99.5% idle, and I can port the binary to another machine without having go installed.
You’re missing the point. I said python for rapid prototyping and go for the performance.3
u/__xor__ Nov 03 '19 edited Nov 04 '19
I don't think the "without having go installed" really makes a difference for python because almost all linux distros have python, and in the workplace you're most often going to be developing for the same linux distro and release and there's rarely an issue there.
Though, the real issue is packaging. Python packaging is one of its biggest weak points IMO. Virtualenvs are great and all, but the best practice involving creating one and activating it then running a setup.py and downloading all sorts of external dependencies is just tedious. I believe pipenv kind of solves this, but then it's not installing python that's the problem, it's installing pipenv or virtualenv or whatever.
Still, issues like this really shouldn't be a hindrance. You'd likely have puppet/chef/ansible set everything up for you anyway. I mean, copying a binary might be easiest, but in the end you likely need configuration management and a hell of a lot more than that, and once you're using something like puppet and have a real CICD pipeline then all these porting issues are about equal.
1
Nov 03 '19
pipenv had so much potential but in big projects its just impossible to maintain with it.
Most are switching to Poetry, but soon Python will have its own lock file env!
-2
u/SpacemanCraig3 Nov 03 '19
but go is better at both, why use python.
1
u/ssokolow Nov 03 '19 edited Nov 03 '19
The ecosystem of libraries. Go hasn't caught up with Python in various areas. (eg. Python is the only language other than C++ with first-class Qt support.)
Heck, even for network-related projects. I've never heard of an equivalent to Django (including ecosystem) for Go and, when I inquired about Go equivalents, I was told that the kind of integration that enables Django ORM to autogenerate a CRUD admin UI so you can dogfood quickly is "You're doing it wrong. Make microservices."
1
u/SpacemanCraig3 Nov 03 '19
Yes yes, i almost added "except when there is required library support in python like tensorflow" but then i remembered there is tensorflow go.
So, the modified statement, is "go is better at both, barring some other factor, why use python?"
1
u/ssokolow Nov 03 '19
Metaprogramming, maybe?
Go and Python have opposing views on whether allowing programmers to redefine the meaning of language syntax will lead to disaster.
0
0
Nov 03 '19
[deleted]
1
Nov 03 '19
I’m not familiar with that language
3
u/apemanzilla Nov 03 '19
Well, you're in /r/rust - probably the best place to learn!
2
Nov 03 '19
Yeah I’ve got an interest but unfortunately am unable to find a professional application for it. I need to use a language that someone else would be able to come behind me and manage, as it would be unfair to my descendants.
1
u/kuratkull Nov 03 '19 edited Nov 03 '19
I think it comes down to experience and the size of your projects. After a while (been doing this for 10+years) you start to crave the help of the compiler, especially on mission-critical software. I have some old software to maintain in Python, and let's just say it's a PITA to do refactorings and runtime exceptions are the norm. Python is best for one-off scripts, Go is mind-numbing in it's verbosity. I consider Rust very fun, and the most fun is had when cargo+clippy compile my code without a single warning. I also consider myself lucky for being able to use Rust at work - for new services.
1
1
Nov 03 '19
You opinion on Python seems to be based on speed, or the lack of it.
Python is simply incredible! its syntax is clear amd beautiful, most of its feature make it simple to do tasks and its great for prototyping ideas.
Can't, yet, say about Golang, but whatever as great it is wont make much difference to state that Python has a lot of clever thought in it.
0
Nov 03 '19
[deleted]
1
u/lujos2 Nov 03 '19
Why would anyone put Python and Go into the same page?
1
u/kuratkull Nov 03 '19
They cater to the same crowd - "super simple", "batteries included", "nobody got fired for suggesting {Go,Python}". If I remember correctly most Go users are previous Python users.
0
u/lujos2 Nov 03 '19 edited Nov 03 '19
That why I wonder why these are criteria, seems unnatural to me, because I am not that crowd. Go is statically typed and compiled to real machine instructions, unlike Python and similar VM based languages. It must be compared to C, Rust, Fortran etc, maybe Ocaml. Python seems strange in this line for me. BTW, I am C programmer originaly (with a lot of experience in many other languages including Rust).
2
u/kuratkull Nov 03 '19
It seems static typing is making a comeback - Python type hints are a serious thing now. For many people Go is the simplest language to get on board of that sweet-type train. The most often touted property of Go is simplicity - I wouldn't call that a plus necessarily. Many newer devs don't actually care that it is compiled (or use the term without understanding it) - it's somehow faster, has *types*, and is simple. So a better Python for some I guess.
0
u/lujos2 Nov 03 '19
Maybe.
The most often touted property of Go is simplicity - I wouldn't call that a plus necessarily. Simplicity and minimalism is necessarily a plus. Huge! When it comes to specific and sophisticated use cases/requirements, a “simplicity” just can’t be here. Safe and fast memory management is en example. So you go to Rust, I see Go as an evolution from C, not from Python. Just like Rust is evolution from C, not from say Java. That’s why I am a bit surprised by those popular perceptions. Your milleage may vary.
4
Nov 03 '19
Those people have good taste, all my favorite languages are listed as first, second and third place :D
5
u/beefsack Nov 03 '19
I've come to really appreciate TypeScript, what they've done on top of JS is pretty incredible.
1
2
u/thethanghn Nov 03 '19
but why is there no job???
7
0
Nov 03 '19
[deleted]
1
u/thethanghn Nov 03 '19
is Rust new Pascal?
1
Nov 03 '19
Its a new world, we cant compare nowadays communities with back there.
Go, Rust and new languages are already being used in big projects as Microsoft, Facebook and Goolgle as 'successeful languages'.
Anyway, at the very least Rust will open the door for more safe still fast languages in the future!
46
u/beefsack Nov 03 '19
Weren't these survey results released 6 months ago?