Does anyone know if this is possible to do in Rust? I’ve been searching the last couple of days and I think my biggest problem is not knowing what combination of search terms to use.
In swift you make an interface / protocol that represents your filesystem API and then make an adapter that implements that API to the actual filesystem and swap with a mock when necessary. If the library you are using uses the filesystem directly, then you might need to make a similar interface adapter for the library.
The slide demonstrates a concrete implementation of the interface, showing how it can be used to communicate with the real file system. The mock implementation is left as an exercise for the reader, as you and I would likely have different requirements.
It wasn't all that obvious or popular back in 2012. Many of these patterns have become more popular since then, also in part due to articles like this.
> If the title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
This time I clicked, but, in general, I'd rather have the original title, gratuitous adjectives and all, so that I can have a clue that the link is going to lead to a listicle.
It's a slide tool written by the Go team, mainly used by them to present at conferences. You'll also notice they've stopped using it as much recently. There was no talks in 2018, and only 1 in 2019. Previous years had many more.
Nothing. PDFs still exist; they haven't gone anywhere.
If you're asking why the Go team doesn't use PDFs for presentations, that's probably a question for the Go team themselves or one of the golang-* newsgroups on Google Groups.
GitHub issue: https://github.com/golang/go/issues/27026. Marked as
[help wanted], so if you're a JS/CSS wizard, come send some
CLs/MRs/PRs/what-do-they-call-patches-these-days.
1-7 of these features exist in C#, and in C# you get a real type system. C# isn't even my favorite language that has all these features, just the most mainstream.
8-10 are of dubious usefulness. It seems they break the principle of least astonishment[1], but maybe they're idiomatic in Go.
So yeah, still waiting to see any reason to think Go's popularity is anything more than hype and fanboyism.
Because Go is taking a strong stance that smaller languages are more productive, and I think they’re right.
C# has all these features because C# has every single feature and facility that every programming language has ever had thrown into a single ungodly soup of keywords and syntax.
Don’t get me wrong, this means C# is bloody powerful but once you involve more than one dev you get into the problems of every dev understanding and/or preferring their subset of C#. Every PR is 50% policing style and structure desperately trying to keep the codebase grokable by everyone and politics about everyone’s favorite pet feature and design pattern. C# rewards cleverness with incredibly slick looking but utterly incomprehensible code unless you wrote it two minutes ago.
Not saying Go is the answer or the way but I think it’s scratching a lot of people’s itches for something high level that’s restrictive enough that there’s only one or two “right” ways to accomplish a given task.
> Because Go is taking a strong stance that smaller languages are more productive, and I think they’re right.
As a face-value claim, that's obviously untrue. Forth, by any reasonable metric, is a smaller language than Go, but I think you'd have a hard time claiming it's more productive.
I'll generously assume that you mean that "languages with a carefully selected set of features are more productive", and there I'd agree with you. That's Python's "There should be one-- and preferably only one --obvious way to do it." But then the question becomes, "Which features?"
A very key choice you have to make up-front is the type system, and it's obvious that Go's type-system choices are bad[1]. Weak static types[2] gives them the worst of both worlds: the types don't get out of your way like a dynamic type system and they don't catch errors like a strong/flexible type system. Single-pass compilation for speed is the only attempt at a justification for this choice, but it's a bad justification: 1) this is solved by partial recompilation for all but the largest use cases[1], and 2) if you're using `go generate` to solve the obvious problems with the type system, you're introducing a second pass that saves keystrokes in exchange for giving up even more type safety. So you add a linter: congratulations, now your single-pass compilation is three passes. This isn't a tradeoff, it's just giving away all benefits of types in exchange for a veneer of minimalist aesthetic.
I'm not going to quote what you said on C#--I'll only respond by saying that if you read my post, you'll see I said it's not my favorite language. I'm not espousing it.
> Not saying Go is the answer or the way but I think it’s scratching a lot of people’s itches for something high level that’s restrictive enough that there’s only one or two “right” ways to accomplish a given task.
...which is extremely short-sighted. The "only one right way to do it" only lasts as long as there's no NPM-like ecosystem of libraries. Look at Python: most projects pull in at least a few common dependencies, and there's immense pressure on Python to integrate these back into the language--a pressure to which they have succumbed in many cases (which isn't necessarily a bad thing). Most projects also pull in some section of really, really bad dependencies that should never have been released into the wild and probably never will be updated. There's no way around subsetting: at least if you use the wrong language features, they'll be supported and deprecated responsibly, unlike the average 0.0.2-versioned 5 line function imported from NPM or PyPy[3].
Ideally you have a set of core features and a strong standard library that don't push people to import a bunch of terrible libraries, which is why Python has fared so well despite some really awful limitations (i.e. the GIL). But again, Go isn't that.
[1] They're probably not bad for Google: the people who made Go made it to solve Google's problems, and they're smart guys. But you are not Google (unless you are Google), and if you're operating at Google's scale, you can make your own programming language that solves your problems rather than Google's.
[2] Go fanboys generally don't know that weak/strong and static/dynamic aren't the same thing, and like to claim that Go has a strong type system because it has a static type system. This reinforces my belief that people choose Go because they don't understand type systems.
[3] NIH isn't even enforceable: good luck preventing people on your team from "importing" code from Stack Overflow using their keyboard's copy/paste function.
I get really sick of people arguing personal preference as if it’s irrefutable fact. I have written pretty sophisticated applications in more than a dozen different languages over the last 3 decades and yes, you’re absolutely right that Go does fall short in many respects, but then so does every other language. There isn’t such thing as a perfect language; it’s always about weighing up benefits vs trade offs.
So how about we get off our proverbial soapbox and enjoy the fact that we are lucky enough to work in an industry where we can choose the tools we like.
> I get really sick of people arguing personal preference as if it’s irrefutable fact.
This reads as, "My personal preference is for people not to argue for their personal preference." Before you go on to argue for your personal preference.
> So how about we get off our proverbial soapbox and enjoy the fact that we are lucky enough to work in an industry where we can choose the tools we like.
Sure, we can choose the tools we like provided those tools are popular enough to have an ecosystem of jobs, or we're willing to shoehorn ourselves into a narrow set of jobs.
...which is why I'm sick of languages getting popular based on hype rather than pragmatics. Every Go job is a job that I've either got to reject based on the tool, or use their terrible tool.
> This reads as, "My personal preference is for people not to argue for their personal preference." Before you go on to argue for your personal preference.
I haven’t argued my personal preference though. All I’m saying is that arguing that your personal preference is anyway more “correct” than others is about as sensible as trying to discuss the science behind religion.
> As a face-value claim, that's obviously untrue. Forth, by any reasonable metric, is a smaller language than Go, but I think you'd have a hard time claiming it's more productive.
I used Forth instead of Awk recently. What I wanted to do required to be more proficient than I am in Awk, while I am proficient in Forth. As you probably know, Forth is not exactly a string-oriented language.
There's no language more productive than others. But there are triplets (programmer, language, task) that are more productive than others.
Well, any data on any such triplet will be highly nontransferable, to the point that it's useless. The challenge is finding minimum maps of generalized knowledge.
If C# has two builtin ways to do something, choosing either of them is better than using lower-level pieces to roll your own. Professionals are responsible for learning the entire language (this isn't C++ where we went years without any compiler correctly implementing all of it).
Not criticising, but I find it amusing that 2 things that people seem to point out about go; backed by a big company, and simple, are the same 2 things so many shit on Java for, for years. You didn't, but reading your post made me think of it.
well, reflecting about it now I'm not so sure that the "big company" argument is that positive. when a language is just starting, having resources is extremely helpful, but in the long run it's indeed possible that the company becomes a liability to the community.
about simplicity, while I wouldn't say Java is a complex language, and I might even agree that the language itself is easy, it's also quite verbose, and it doesn't feel as light to use as golang. I would personally mention two things (besides the verbosity of Java):
1) the OOP in Java kinda leads me to start designing around classes, and I feel I need a solid design/plan right from the start, while in golang I feel a bit more like I'm working with a scripting language, but the interfaces and the way the language works makes it quite easy to refactor code and move things as I need it, and in practice I end up with good organization and modular code precisely because it's very easy to move things around. just that frame of mind is a big change (though this is extremely subjective).
2) when I write Java I feel like I need an IDE. yeah, again partly because of the verbosity and boilerplate, but I also feel the environment is more complex. with golang I just write a "package main; func main() { some code }" and then run "go run myprogram.go". that makes the language feel really light and easy to use. I'm not afraid to try to write a demo program and run it even with my eyes closed. with Java I don't feel so much in direct control, and I regularly end up confused about random configurations and things. I don't try to argue that Java is significantly more complex as a language (the typical programming environment is quite different), but it still feels much heavier and complicated than golang.
well, I'll stop here or I'll end up sounding like a fanboy (I wasn't a big fan of many of the golang design choices at the start)
Pretty close to the best performance though. So close that the difference doesn't matter for almost all apps. C and C++ are faster. Rust is maybe sometimes faster. Java is mostly slower. Python/Ruby you get a 20-40x faster performance on 1 goroutine. Much bigger gain if you do many things concurrently.
Is that from a performance benchmark, or is it from any of the ways where Python and Ruby are actually used?
In processing large data sets, Fortran and Python are often used, and if you write similar code in Fortran and Python, you'll get much better performance in Fortran. But if you write Python using PANDAS, you can achieve comparable speeds, with much less developer effort because you're using a much higher-level language with more modern tools for all the glue, while calling out to highly-optimized loops for the heavy lifting.
Similarly, for web scaling: the speed of Python isn't nearly as relevant, because you're running your Python in a WSGI web server that is written in highly-optimized C.
And if your application is so specialized that a C-wrapper doesn't exist that handles the parts that need optimization, you can profile your Python code, and use the very good C integration to optimize the bottlenecks.
Language choice based on performance is a premature optimization.
I'm not espousing Python, either, necessarily: it's just a good example for this case because it's a slow language where its slowness doesn't really matter.
I love working in Python and I've seen this argument over and over.
In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation.
> In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation.
Okay but:
1. How often do you find your performance bottleneck is some part of a Python library? My entire point is that modern Python development almost always delegates hotspots to pre-optimized libraries.
2. If your bottleneck is a use case that's unsolved so that there isn't a pre-existing library for it, it's probably unsolved because it's a difficult enough problem that using the C foreign-function interface is the least of your problems. It's also likely that you need a level of optimization which Go can't give you, so you're going to have to drop down to C/Fortran/assembly/whatever regardless of whether you're using Python or Go.
Does anyone know if this is possible to do in Rust? I’ve been searching the last couple of days and I think my biggest problem is not knowing what combination of search terms to use.