-
Good post. Some problems just a lack of experience in Rust but others good complaints. I think the problem I sympathize the most with is that Rust is so anti array. I work with them a lot in unsafe code and it is a bit concerning that Fortran is still the best language when it comes to n-dimensional array manipulation.
-
use D for numerical computing, its as fast as Fortran, (almost) as easy as python, as flexible as C and as safe as Rust. see e.g. https://github.com/libmir/mir
-
-
there is no support for hybrid certificates yet right?
-
This is my bet: the age of dynamic languages is over.
I wouldn’t take those odds.
-
A year or three back I would have said I need Ruby.
I sometimes need C/C++ for low level / fast tasks… but for getting things done I need Ruby.
Now D is slotting into a lot of places I’d previously have used C/C++ AND/OR Ruby.
And it’s better than the lot of them.
D only makes me specify types when it actually helps, and allows me to specify types “maximally weakly”, but instantiates to strict type checking “as compiled on the day”.
So actually I agree with him. I foresee the day I will write my last program in a dynamically typed language, and it may not be as far away as you think.
-
That may mark the end of dynamic languages for you, but not for the world. I have a hard time seeing dynamic languages going away in the near future.
-
If you get the advantages of both (static and dynamic) languages in a single language without the disadvantages of either… Why, apart from buckets of Legacy code, wouldn’t you shift?
-
If you get the advantages of both (static and dynamic) languages in a single language without the disadvantages of either
What wonder-language are you referring to?
-
D is getting close to that point…
If I look at the reasons I use Ruby…
- Low finger strain from typing fluff that the compiler should be able to figure out anyway.
- Understands strings and regexes and I don’t have to even think about the where I have to store or free them.
- Understands the file system and networking.
- Has a large standard library.
- Compiles / run / debug cycle lightning fast.
- Hugely powerful mixins concepts like Enumerable
Guess what? D has all of that these days.
D’s GC isn’t quite up to Rubies standard (yet?), but on everything else D meets or exceeds Ruby.
And then adds C like “as close as you can get to the metal without burning yourself” fast.
And then adds C/C++ like (and better) type safety (without the typing fluff).
And then adds C++ like, but hugely easier generics.
D has a large addon library “dub” collection, growing but not yet exceeding Rubies gem collection.
Dynamic Languages are nice in that a lot of stuff “just works with anything that quacks”.
In D you write “generic by default”, and it “just works with anything that quacks”.
AND the compiler will tell you at compile time if anything you feed it doesn’t quack!
And then allow you to add a custom “Sqvack!” trait method if you need it for strange sounding duck like things.
D has taken the C++ iterator idea and the Ruby Enumerator idea and run way beyond both with the Range concepts.
Ultimately D’s short comings seem fixable and likely to surpass Ruby on every measure… I’m not sure Rubies shortcomings are fixable, as a number of design choices are too deeply baked into the language.
We’re nearing a tipping point. Not there yet, but getting nearer.
-
Good run-down, I think I’ll be trying out D in the near future. Thanks! :)
-
-
-
-
Show me a statically-typed language that can boast the reliability and maturity of Erlang/OTP and we’ll talk.
-
-
You run dialyzer, and it tells you.
-
-
Well yes, obviously it is a continuum. However, I’m not aware of any self-described static languages that use success typing as their inference strategy. Maybe one exists; if so, cool!
-
-
-
-
-
-
-
-
D is very cool and I’m going to use it for my next personal project, but I simply can’t imagine the dynamic languages are going to go away. I can see their use diminishing as various projects mature (read: migrate to something more solid), but they are still incredibly useful for prototypes and working where the notion of “specs” (and specifically the initial data model) is essentially a joke.
-
That’s the really interesting thing about “Generic All The Time”.
Normally if I write a function in “Concrete/Specific/Strictly Typed all the Time”….
I have to specify a function like…
isExactlyADuck_t myFunc( isExactlyADuck_t duck, isExactlyADog_t dog) { duck->quack(); dog->bark(); return duck; }I first have to find and specify the exact types, and they better have a quack and a bark, and it will only work for that specific duck and dog.
In a dynamic language like Ruby I go…
def myFunc( duck, dog) duck.quack dog.bark duck endand it magically works for all things that quack and bark….. but I’ll only know that it works if I run that… and I will only know that for the particular duck and dog a passed in for that particular run.
In “Generic All The Time” I go ..
duckish myFunc(duckish,dogish)( duckish duck, dogish dog) { duck.quack() dog.bark() return duck }While I’m writing myFunc I needn’t even know what duckish and dogish is now… or in some future.
…but as soon as I invoke…( both in my rapid prototype and in my final production)
auto muck = myFunc( mallard, mutt);the compiler verifies mallards quack and mutts bark and automagically grants “muck” the type mallard.
-
-
-
-
lenovo x1 i got last week, antergOS with kde plasma. Sublime, Konsole, Yakuake. still working on an optimal configuration
-
i was at a similar point but then decided to move to D. never looked back.
-
-
I have wondered about D a few times over the years. When I was most seriously looking into it (admittedly quite a while back) I think it was right around the start of D2, and there was much confusion about D2 as well as the whole phobos vs stdlib thing, few platforms supported, etc. Things in generally just didn’t feel very organized, and it seemed like a bad time to burn cycles learning it. Can I assume, based on the fact that I am starting to see more articles about D pop up in various places lately, that things are much better now?
-
-
stip
edited
3 years ago
|
link
| on:
A Unix-y utility for formatting JSON in a more pipe-friendly way
You may also be interested in the ludicrous jq. There is also jqplay, which lets you try out the jq language online.
Below is the equivalent jq demo for “get all the front page links on Reddit”. The
join("\n")and--raw-outputformat the JSON list into raw lines suitable for xargs.curl -s 'https://www.reddit.com/.json' | jq --raw-output '.data.children | map(.data.url) | join("\n")'-
This was directly inspired by how silly I thought jq was. Ironically enough, the two work well together.
-
-
-
-
-
‘the tools I already use’ (grep, cut, sed, awk) typically work in two modes: “character delimited columns and rows” or “crazy regex parsing.” none of them work well on recursive tree data (which most JSON feeds are). most of the time I want something like “go three levels deep, pull out these two keys, and output them as a dict.” jq ends up being the best solution for this workflow (for me)
-
I’ve worked with largish json datasets, several terabytes. JSON parsing is really expensive. Without json, processing a million messages/s is pretty easy. With json, it’s tough to beat 100k/s (with say an i7). Also the standard unix tools don’t deal well with nested data.
-
-
-
-
-
database tag because its basically a database and i could not find any more suitable tags ;) but i’d love to see a few more tags e.g. cryptography, storage, utils
-
we’ll for me the hardest part of developing for ios/osx is knowing the framework, its patterns and getting along with xcode. its far more complex than just another language with a slightly different syntax.
-
see also: http://opennvm.github.io/ https://github.com/opennvm/nvmkv
after reading the paper it seems that this only works if you have a fusion-io drive, or am i wrong? there is also a standard: http://en.wikipedia.org/wiki/NVM_Express
-
i usually also prefer whole albums
c2c - tetra http://open.spotify.com/album/1e3EQYi3OGvbzW9bpyv7rO
pilotpriest- original-motion-picture-soundtrack (almost free) http://pilotpriest.bandcamp.com/album/original-motion-picture-soundtrack
audiodope - Anthophobia (free) http://audiodope.bandcamp.com/
-
i agree that if you use an ORM you trade in problems for others.
the article generalizes the different orm patterns that exist. not all orm are created equal.
since all data can be “relational in nature” his solution to “Encapsulate your relational queries into a Model layer” will in the end just produce your own ORM or lots of duplicated and hard to maintain code.
we currently use the Ruby Sequel Library. I like it because it provides different levels. You can easily drop to customised SQL and speed up things if necessary.
-
Along these lines, another benefit of the ORM is composability. I find that when working directly with SQL it is much harder to compose queries from smaller, singly focused components. That being said, there are abstractions that operate at a lower level than an active-record-style ORM and map much more closely to SQL (such as Ruby’s Sequel mentioned above or Clojure’s Korma) offering much of the composability benefits that you’d get from an ORM.
-
No one has mentioned another big benefit of ORMs: security.
ORMs are supposed to sanitise all input, and prevent sql injection attacks. In theory, programmers could do this themselves. In practice, the dozens of hacks at big name firms (can’t remember any examples now) show that most programmers, even at reputable firms, weren’t doing basic sanitization of input.
-
-
-
-
The ‘mania’ is a problem, many guess a 4th(?) crash is coming. It is a risky project, perhaps the riskiest. But it’s alive because many of us ‘nerdy’ types believe crypto-currencies will be the currencies of the future; whether that’s BTC or not remains to be seen.
To some degree, others believe the current fiat currencies will eventually collapse. Hence a crypto may well be the last-man-standing. It would be hard to argue its legitimacy then.
TL; Valid points, though explaining everything away as ‘mania’ might be shortsighted.
-
i’m watching it since it was at 30 cents and made a solid amount of money with my bitcoins. none the less i think its doomed. the argument of scarcity that the whole scheme is build upon is just not valid: the cost of creating a currency with the exact same properties is close to zero. on the long run there will be no trust in such a system. the real cryptocurrencies that everybody is waiting for will be smaller marketplaces and “money” will be backed by goods.
-
-
also a good read: http://www.aarongreenspan.com/writing/essay.html?id=97
-
i’d advise against taking 20k. it will most probably be not enough. and if so, i am sure there is a way to even do it with almost 0 and maintain 100% control on the venture.
-
i also think that the benchmarks are useless. imho there are two reasons to choose mongodb: 1) scaling 2) developer friendliness as you are very flexible
i’d be interested to see how benchmarks look when you have a few TBs distributed over 5+ machines with ssds.
-
love it!
long live email ;)
-
creating the prototype of a next generation of television station. i’m cto of rayneer.tv, currently a personalized music television station for different platforms (available in switzerland only due to the licence contracts) mostly ruby and some coffe-script.
-
interesting concept, very nicely done. unfortunately lacks an API
how about thunderbolt 3? could be interesting for small storage arrays.