Short of using a different data structure, I'm not sure how you would get out of that one. The claim was that some of these leaks ("leaks"?) could be avoided by using a language with a GC. As far as I know, most modern languages' equivalent of Vec will do exactly the same thing, GC or not.
HN user
mercurial
A mercurial software engineer.
the pattern of allocating a vec as pseudo-RAM, using indices as pseudo-pointers, and never freeing anything till the container itself is unused
Are you talking about hand-rolled arena allocation? I don´t see how a GC language would have a different behaviour as long as you also use arena allocation and you keep a reachable reference.
There's nothing wrong with those techniques per se, but the language tends to paint you into a bit of a corner if you're not very good and very careful, so leaks are a fact of life in basically every major Rust project I've seen not written by somebody like BurntSushi
If I take 3 random major Rust projects like Serde, Hyper, and Tracing, none of which are written by BurntSushi, your claim is that they all suffer from memory leaks?
You need to authenticate once. You will get your vaults locally and you will be able to access them without an internet connection
IMO, rustc_codegen_gcc is much more reasonable in scope. It also stands a chance of actually keeping up with subsequent Rust releases. I would be surprised if gcc-rs ever achieved any traction. Not to say it's not a fun project, but I can't see it replicating rustc.
The culture and ecosystem should definitely be a huge part of selecting a language.
Rust has a small(ish) but high quality stdlib. It does not aim to be Python. Like with any language, you have to know the ecosystem in order to be productive.
That said, sure, having a full-featured stdlib can be convenient. It's a matter of trade-offs. Having more content outside of the stdlib allows the ecosystem to evolve organically (and iterate quicker) and select the best approach to a given problem (which... could definitely have been an advantage for Python).
In french you say "Omelette du fromage".
No you don't, that's literally "Omelet of the cheese". You say "Omelette au fromage", which is "Omelet with cheese".
I do agree with your broader point, though.
Thanks! This is exactly the kind of mistake that annoys me.
Wars are rarely won by single battles. That said, it really depends what period of history you are interested in. If you want to stick to the XXth century, Anthony Beevor regularly produces very readable books on WWII or the period immediately before (mostly concerned with the European theater).
If you are interested in more ancient history, I can warmly recommend Keagan's Peloponnesian War (which mostly draws on Thucydides eponymous masterwork).
Hardly. This is in no way a historical treaty.
I have no sympathy for right-wing extremists, but EU countries still operate within the rule of law. You cannot deport people who are member of a legal organization, and I don't think there is enough evidence to declare it a terrorist organization.
I don't think any of the people they assassinated were even alive at the time of the Armenian genocide, so it's really not comparable.
Caesar's biography by Adrian Goldsworthy is excellent, but quite extensive.
Works fine here (Denmark)
Apparently, the native tribes don't get the right to choose.
Rust is a compiled language. There's a compile step when you make a code change.
That said, it really depends on what you're doing. If you are debugging something, it can be a bit painful but not terrible (typically, you're just changing a few things as you go along). If you're implementing a feature or refactoring, you're better served using "cargo check" (especially in combination with "cargo watch") to only run typechecking but not code generation, which means extremely fast feedback.
The .NET ecosystem is a lot more mature than Rust's, there is no arguing that. As for code cleanliness, though, it's debatable. Rust has ADTs, Option, exhaustive pattern matching, Option and Result. C# doesn't.
Rust is amazing (but also frustrating), but RLS is, frankly, terrible. It is unreliable, slow and unstable.
There is nothing particularly outstanding about C#'s type system. It has reified generics and some basic type constraints, but so what? No option type, no ADTs, no pattern matching... Working with Typescript at the same time, I feel crippled every time I need to do something in C#. Not that Typescript is perfact, but its type system (especially with `strict`) is considerably more sophisticated.
A database provides developers with the convenience of composing queries by concatenating strings. You still need to be really incompetent to do so in 2018.
I don't know what it's worth in terms of security, but it's really convenient. And Danish bureaucracy is the smoothest I've seen yet.
The article forgets to mention a crucial point: one of the Republicans' main reasons for not granting independence to Morocco was to avoid antagonizing the UK and France, who were major colonial powers. Throughout the war they hoped to gain their support. They never obtained it, which means they were pretty much hostages of the Stalin-backed communists, as the USSR was their main provider of arms and ammunition.
The strategy of the Stalin-backed communists was to not alienate the middle class. The anarchists, on the other hand, were not about letting war get in the way if social reform, and had taken over factories and collectivised land. It was also a good opportunity for Stalin to purge communists not allied with the USSR.
In this particular instance, clearly not. However, a rule of "first come first served" does not do anything but validate domain name squatting as a business model. It's like patents, you may have a patent linked to a legitimate business, or you may be in the extortion business. Let's not enable extortionists.
Also known as "enabling domain name squatters".
As for lifetimes, that syntax is from OCaml, though they use it for something else.
I hadn't noticed the similarity but it makes sense. This is the OCaml syntax for generics, eg:
type 'a list_with_generic = 'a list;At-will employment would have changed little about Roy’s situation vs a huge international political bully.
That entirely depends on the country. There is no "huge international bully" clause in employment law.
Not to mention that I'm not sure about "the real bully". If you think that underpaid customer care agents have the responsibility for executing your business strategy in China, maybe you should pay them appropriately. Or maybe you should ensure that someone higher up the food chain takes the fall.
Is an employee allowed to quit? What about the "violence" it does to the company, investors, and fellow employees? Must they stick around to provide continuity? If so, how is this not indenture?
Grotesque. Many industries in various countries have a reasonable notice period (say, 3 months), which should give the company enough time to adapt. Nobody considers this "indenture".
Employment represents a contract between two parties. Basic freedom of association and contract law means both parties can enter and leave under the terms they negotiate and have a rational self interest in acting in good faith.
The difference is that one party, most of the time, can manage without the other. On the other hand, the fired employee still needs to pay rent/feed his family. And depending on the economy/location, finding a different job might take some time (if it's possible at all without retraining).
Works fine in React.
Well, an order of magnitude of difference is a hint that, whatever the quality of the existing crates, there are definitely areas for which you are going to be hard-pressed to find a good solution (say, localization), or a solution at all.
It is not a sign that there is anything wrong with the Rust ecosystem, it has a very active community and things are moving in the right direction, it is not just as full-featured as more mature ecosystems out there.
See for instance https://github.com/ErichDonGubler/not-yet-awesome-rust
There are quite a few use cases not listed here, obviously.